91–100 of 130 posts
If you're looking for something like superbase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ It takes a bit more of a higher level approach to database operations than superbase, which allows us to do things like optimistic updates that are hard to do in other tools.
How does thin realtime work in the backend and behind the scenes?
For people who have some experience in this, what's the best less-code backends? Hasura? Supabase? Prisma? Thin?
However, while I've played around with most of the others you mention, I haven't build anything serious with them. But hasura has a decent authentication story and reactive graphql queries are just a really nice dev experience
How exactly does the scaling work. Anyone remember Meteor? I wasted months of my life struggling with it, it scaled horribly.
The realtime stuff can generate a fuckton of writes depending on how you have it set up and what your use is, that's probably the most likely scaling footgun.
Earlier quoted context omitted.
I work at Supabase on database security so I can speak to some of these. > - As others have said, default security is way too permissive. They should lock everything down by default. At some point, this is going to cause major problems for some company that decides to build off Supabase. We agree and are internally actively discussing this very subject. > - Although they have row-level security, RBAC is completely mi…
Thanks for the reply! I've never worked at Zope. Must be my doppelganger. > We don't "have" row level security per se, that is a native feature of Postgres we expose, and the customer is free to use or not. RBAC is a very broad term, and broadly speaking Postgres has roles and privileges that do access control. Did you have something more specific in mind? I was referring to the ability to assign a user to one or mor…
Same last name and first initial as your handle so I took a guess. :)
> I was referring to the ability to assign a user to one or more groups and then set, at the group level, access to a row or column. When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB.
This can be done with Postgres' built-in role system. You can assign a "group role" to as many roles as you want (which in turn, can also be groups, or not) into a hierarchy of roles which can be used in any GRANT statement or RLS policy. Postgres used to have `CREATE USER ...` and `CREATE GROUP ...` but they are now completely subsumed by the "new" role system. Both statements still work and map to equivalent `CREATE ROLE ...` statements.
Let's say I have Customer 1 who owns Document 2, 3. Document will have a foreign key pointing to Customer. How do I ensure that Customer 1 can't access Document 1?
Earlier quoted context omitted.
thin.dev Realtime Bandwidth - $2 per GB yes please, sign me up !!! /s
Thanks for your feedback :) You have to send quite a few json messages to fill up 1GB. We think overall thin provides a lot of value and saves a lot of developer time (atleast for businesses), so we price it as that.
Earlier quoted context omitted.
Thanks for the reply! I've never worked at Zope. Must be my doppelganger. > We don't "have" row level security per se, that is a native feature of Postgres we expose, and the customer is free to use or not. RBAC is a very broad term, and broadly speaking Postgres has roles and privileges that do access control. Did you have something more specific in mind? I was referring to the ability to assign a user to one or mor…
> I've never worked at Zope. Must be my doppelganger. Same last name and first initial as your handle so I took a guess. :) > I was referring to the ability to assign a user to one or more groups and then set, at the group level, access to a row or column. When I implemented this, I avoided using PG roles b/c I was unsure how this play safely with future changes to the hosted DB. This can be done with Postgres' built…
1) Auth tokens currently use symmetric signatures, which makes them less useful for zero-latency verification in runtimes like Cloudflare Workers, and also less interchangeable with other auth systems (although it is possible to interchange still by implementing a token minting endpoint ourselves, but that's extra effort and latency). This would also be really useful for integrations with Firebase Auth, which is ironically needed for interoperability with other Firebase products not yet in Supabase :-) It would be great if you switched to standard RS256 + .well-known OIDC endpoints..
2) Recently added built-in database-driven GraphQL module is ingenious, but would benefit greatly from Realtime capability (and I know that's hard!)
3) It's a bit unclear what the multi-zonal or multi-regional (!) story is for Postgres. This would be very useful not just for HA, but for globally-distributed (reduced latency!) scenarios, like the ones addressed by Fly.io Postgres, for example. I know, global ACID is hard and expensive, but if we could get closer to that (for example, similarly to Fly.io), that would be amazing! Right now, it's not clear what the latency story is for users accessing Supabase from half-across the world. If you could document that at least a bit (incl. which region(s) Supabase is deployed in so we could place our backends closer to those), that would be awesome!
Thanks so much, this is such an amazing and unique (!) product that really fills the void left over by Firebase, particularly due to the lack of major progress on Firestore in recent years.
I think the sentiment has been shared here by others, but I think authentication and authorization are going to be your biggest hurdles, yet biggest revenue drivers in the future (e,g., enterprises, startups, etc).
I’d honestly love to see you guys come up with a novel OIDC solution, maybe even using Keycloak as the model/goal (which also follows the trend of Supabase innovating on existing tech).
Excited to see where you all go from here and the sky is the limit!