31–40 of 308 posts
These ideas are cool but I wonder how security works. Do you do like rate limiting and stuff like that?
You can learn more about the rules language in the permission docs: https://www.instantdb.com/docs/permissions
Congrats team!
As a potential dev user this looks really intriguing, hitting all of the main points I was looking for. I build apps in this space, and the open source alternatives I've evaluated are lacking specifically in "live queries" or don't use Postgres. The docs look great too. In the docs[1]: > Instant uses a declarative syntax for querying. It's like GraphQL without the configuration. Would you be interested in elaborating…
> Would you be interested in elaborating more about this decision/design? Our initial intuition was to expose a language like SQL in the frontend. We decided against this approach for 3 reasons: 1. Adding SQL would mean we would have to bundle SQLite, which would add a few hundred kilobytes to a bundle 2. SQL itself has a large spec, and would be difficult to make reactive 3. What's worst: most of the time on the fro…
It reminds me of the data half of Meteor, but it looks better thought-out and, obv., not based on Mongo. Nice work.
How is it better than firebase or Superbase ?
> Currently we have SDKs for Javascript, React, and React Native.
Seems comparable to https://pocketbase.io/
What isn’t modern about Firebase and what makes this modern in comparison?
With Instant, you get a relational Firebase.
What's the short summary of how the authorization system works for this? One of the things I find quite nice about firebase is the quite powerful separation between the logic of data retrieval / update and the enforcement of access policy -- if you understand it you can build the prototype on a happy path with barely any authorization enforcement and then add it later and have quite complete confidence that you aren'…
We built a permission system on top of Google's CEL [1]. Every object returned in a query is filtered by a 'view' rule. Similarly, every modification of an object goes through a 'create/update/delete' rule.
The docs: https://www.instantdb.com/docs/permissions
The experience is similar to Firebase in three ways:
1. Both languages are based on CEL 2. There's a distinct separation between data retrieval and access policy 3. You can start on a happy path when developing, and lock down later.
AFAIK, Firebase Realtime can be more efficient, as it can tell if a permission check has passed statically. I am not sure if Firestore works this way. We wanted to be more dynamic, to support more nuanced rules down the road (stuff like 'check this http endpoint if an object has permissions'). We took inspiration Facebook's 'EntPrivacy' rules in this respect.