> Are we supposed to expose all entities and relationships and rely on row level security?
Yes. This may feel foreign, but we think it's one the best ways to do permissions. We were originally inspired by Facebook's EntPrivacy. When you have permissions at the object layer, you can be more confident that _any_ query you write would be allowed.
If by backend you mean functions, you are right, we don't support this just yet! We give you an Admin SDK, which you can run in frameworks like NextJS, or inside systems like CF workers. We are definitely thinking about bringing this as a first-class citizen.
We are similar to supabase in the sense that we support a relational database. We're different in that with us, you get real-time queries, offline mode, and optimistic updates out of the box.
We both offer a real-time queries out of the box. I am not 100% sure, I but think Convex also set up a multi-tenant database; so they can offer a good number of free projects well.
The way I would differentiate Instant:
With Convex you write your queries as Javascript functions. This means you have to do joins for example imperatively. With Instant, you can write queries declaratively.
As of today Convex doesn't work offline, and you have to write optimistic updates manually. Instant can run offline and comes with optimistic updates out of the box.
Both Convex and Instant support files out of the box. But with Instant you can write CASCADE delete rules, and you also get other services, like presence and streams.
Congratulations on your launch! 4 years of work is certainly remarkable perseverance.
The sync engine feature looks very interesting to me. There have been quite a few products available on the market today, but none has achieved a dominant share yet. So if this is your main strength, I'd like to see more demos built local first.
Curious if you considered shipping the engine itself as a standalone infra piece.
> Is React the only first class citizen in this stack?
Each system gets the same functionality. We centralize the critical logic for the client SDK in "@instantdb/core". React, Svelte, Tanstack, React Native et al are wrappers around that core library.
The one place where it's lacking a bit is the docs. We have specific docs for each library, but a lot of other examples assume React.
We are improving this as we speak. For now, the assumption on React is quite light in the docs, so it's relatively straightforward to figure out what needs to happen for the library of your choice.
1. Unlimited projects: when you spin up traditional backends, you usually use VMs. It's expensive to start many of them. With Instant, you create unlimited projects
2. User experience: traditional CRUD apps work, but they don't feel delightful. I you want to support features like multiplayer, offline mode, or optimistic updates, you'll have to write a lot more custom infra. Instant gives you these out of the box, and the agents find it easier to write than CRUD code
3. Richer features: sometimes you'll want to add more than just a backend. For example, maybe you want to store files, or share cursors, or stream tokens across machines. These often need more bespoke systems (S3, Redis, etc). Instant already comes with these out of the box, and the agents know how to use them.
There are a few demo sections in the post that show this off. For example, you can click button and you'll get a backend, without needing to sign up. And in about 25 lines of code, you'll make a real-time todo app.
How does it compare to photon networking? I've been using photon and webrtc mostly. I haven't had any issues, but I'm always interested in finding better solutions!
Photon looks interesting! I am not too familiar with it, but from what I understand Photon and WebRTC are for communicating messages between clients. Those messages can be very fast, because they aren't blocked by writes to disk. Instant has two similar services, Presence & Streams. The primary sync engine is more for storing relational data.
If someone else's account is compromised, you would not be, because apps are logically separated. There would be no way for the compromised or uncompromised account to ever see your data.
If Instant is compromised, then that's a lot more dangerous. We minimize this risk following security best practices: keeping data encrypted at rest, keeping secrets hashed at creation time, etc.
"logically separated" as opposed to "physically separated" (pretty rare in the Cloud world)
If you want more details, read their open source codebase or ask them specifically what documentation would boost your confidence, instead of leaving snarky comments.
reply