Comment by stopachka
2 years ago
Our permission system [1] can work like middleware.
> Let's say I want moderation
I am not 100% sure what you mean by moderation. There could be two ideas:
Moderation 1: 'some people can see all posts, or delete other people's posts'
You can write a rule that allows 'moderators' full access to chat, while, 'users' can only see the channels they blog too, and crud their own messages
Moderation 2: 'I want to validate that some field passes a test -- like 'messages must be under 140 chars''.
You could write a permission rule like `size(data.message) < 140`, which ensures this. We're inspired by ActiveRecord's validations [2], and aim to make validations a lot more ergonomic in the future.
> rate limiting
We don't have built in support for rate limiting, but CEL [2] could handle it. If you have a specific need, let us know and we'd be happy to prioritize it: founders@instantdb.com
[1] https://www.instantdb.com/docs/permissions [2] https://guides.rubyonrails.org/active_record_validations.htm...
Thank you for your response. While permissions sound like they can cover a lot of cases let's say I want to moderate with a list of banned words that are defined in a JSON or fetched from a service.
Ideally I would like exactly what you provide but be able to insert arbitrary server-side code that is run before the change is committed to the database.
I remember having the same "problem" with Firebase back in the day and ended up having to use a Cloud Function that listened on changes and updated records, but it was not a nice experience.
That's a great point Kiro. Down the road, we could look into introducing a more turing complete language, which you could use before a transaction runs. We decided to go with CEL for the sandboxing benefits.