Replies: 4 comments 7 replies
-
|
These improvements to Appwrite sound amazing and should definitely help with the existing limitations. My biggest concerns are around the DX of newcomers to Appwrite:
Flexibility and scalability are major factors that should be addressed, but we also need to make sure it's not at the expense of making Appwrite accessible to developers of all skill levels. |
Beta Was this translation helpful? Give feedback.
-
I think this is something we could work on adding to the overview of each product. |
Beta Was this translation helpful? Give feedback.
-
|
I think best approach could be something like Cloudflare is doing: rate limit rules. This way you get a huge flexibility and you're able to block exactly what you want to. In other words, you can set a rule to block an user per IP address if it hits 100 requests per second in the login endpoint, but you can define the rule to block instead per IP address per account/email. You can also set conditions based on the user agent, IP address, etc. This is pretty good for applications like when you're having a network from a company. That way you can whitelist the company network IP address or set up a custom rate limit for such specific IP address. You can also setup the cooldown for example. Example: I think It's important to highlight in database adding custom limits to the amount of documents you can retrieve with one single request, since it's not the same doing 10 requests to get 10 document with each request than doing 10 requests to get 200000 documents with each request, so basically setting a limit for the Query.limit() query server-sided |
Beta Was this translation helpful? Give feedback.
-
|
I really like how this flow is laid out in an easy to read format. Plain English end result that makes it easy to understand exactly what will happen and when. Just need that pink design |
Beta Was this translation helpful? Give feedback.
-
|
Yes, also to comment, it would be great to have some kind of logs or stats like a graph on rate limits so you can have more insights to see if they're effective or if they're blocking traffic that should not been blocked |
Beta Was this translation helpful? Give feedback.
-
|
Also, regarding configuring through appwrite.json, etc, I think it's a bit unnecessary, but it's more of a personal preference 😅 Maybe it's useful for someone 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
This is similar to the direction we're thinking, we might start with something much simpler than this first time around, but this is really good suggestion to have. |
Beta Was this translation helpful? Give feedback.
-
This is really good feedback, will take into account! |
Beta Was this translation helpful? Give feedback.
-
|
Great idea, good to see. The main issue I ran into so far was the email limits with cloud AW which impacted testing when you're iterating on some registration/signup flows or other login initialisation testing requirements.
Yes, please. Like Stripe has a test mode for their API. I ended up installed local docker AW and turning off the rate limit for Auth for testing. As for resource, doing more testing now on those aspects so will keep this in mind while testing for any feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Taking these ideas and moving them forward with the team. An RFC will be written later and added to our road map. Thanks all for your input! |
Beta Was this translation helpful? Give feedback.
-
👋 Hi friends,
Having configurable rate limits has been a long-standing issue for Appwrite. See: #2953
As Appwrite matures, this issue has bubbled to the top of our concerns, and we've come up with a plan to address this problem.
As always, we're looking to discuss our ideas thoroughly with the community to make sure the solution fits everyone's unique development needs. We'll actively monitor this discussion until Feb. 4th. Everyone's comments will be combined and turned into an RFC and implemented in a later release.
Here's the current proposal from the team as a basis for discussion.
Custom abuse limit
The ability to customize abuse limits has become an important issue for Appwrite Cloud users. Everyone's apps have different needs and definitions for what constitutes as "abusive". Some apps might expect users to delete or create hundreds or thousands of documents at a time. Other apps might expect hundreds of users to share the same IP through an VPN. Appwrite should be flexible enough to let developers decide what is "abusive".
Auth abuse limits
Authentication rate limits are used for security.
Resource abuse limits
Resource abuse limits are less for security and more to prevent abusive behavior like spamming endpoints to make them slow, writing or deleting large amounts of data to make projects run out of resources, etc.
Limits are applied to Client SDKs, Server SDKs with API keys are not limited.
For each resource, you can configure the following for a rate limit.
Below are the different configurable parts of a resource limit.
Per resource
You can define abuse limit behavior for these top-level resources. This means you configure abuse behavior for the entire collection or bucket, instead of configuring per endpoint for the sake of simplicity.
Per action (multiple answers)
Define limits on all of the following actions (or have multiple).
Abuse keys
Abuse limits are applied to each unique abuse key. Abuse keys are created with an AND operator between them, multiple rules allowed for or functionality.
You can create abuse keys with the following:
Example
So, for example, you can have the following abuse key:
This limits you to 100 file uploads per hour, for each user ID or for each unique IP
Ways to configure
Let us know what you like and what you'd like to change. We'll try to engage in the discussions to get to the bottom of your unique needs.
Beta Was this translation helpful? Give feedback.
All reactions