Our great sponsors
-
-
protobuf-rules-gen
This is an experimental protoc plugin that generates Firebase Rules for Cloud Firestore based on Google's Protocol Buffer format. This allows you to easily validate your data in a platform independent manner.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
crystal
🔮 Graphile's Crystal Monorepo; home to Grafast, PostGraphile, pg-introspection, pg-sql2 and much more! (by graphile)
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
That can be solved with RLS. The JWT usually contains the application user id(Customer) and assuming Document has an ownerId column, the SELECT policy for Document would contain the `ownerId = auth.uid()`[1] condition - this would ensure customers can't access documents that they don't own.
This looks more fit to be discussed in. https://github.com/supabase/supabase/discussions. I'd recommend opening a discussion there.
[1]: `auth.uid()` is just a wrapper over the `current_setting('request.jwt.claims', true)` mentioned in https://postgrest.org/en/stable/api.html#accessing-request-h...
A long time ago, I was the PM on Firestore security rules, which was intended to solve both of those issues.
https://github.com/FirebaseExtended/protobuf-rules-gen was the closest we got: declaring types as protobufs (because Google, of course) and then generating both security rules to guarantee validity as well as client types that would match. I wanted to add proto annotations to do additional validity (e.g. add a regex to validate the phone number string was correct, do length checks on strings, etc.).
The short answer is that backend rules engines, either in their own DSL or bolted on to e.g. SQL, are pretty tough to get right, and have a super steep learning curve. IMO, AWS API Gateway with Lambda Authorizers get this most correct.
I've personally found Postgraphile to be fantastic. Nicer to use than Hasura and fully OSS: https://github.com/graphile/postgraphile/
Using thin-backend has been one of the most delightful experiences I've had making an SPA with a simple backend. The developer experience with the generated TypeScript types is particularly great, the DB migrations remind me of Prisma, and knowing I have a standard Postgres db under the hood is comforting. It isn't a large or complex app, but Marc has been super responsive to bugs and feature suggestions so it has been fun to iterate on. You can find the code at https://github.com/ianobermiller/colorcal.
And there are still some sites that host it for you for free (limited), but you can always self host it yourself...
https://parseplatform.org
With regards to authorization – have y'all looked any at Open Policy Agent[1]? I think it could potentially be a good fit for the Supabase stack to implement policies not just in the database but also the gateway and potentially other components as well.
It'd be super cool to be able to implement custom policies in rego code that could be re-used in several parts of the stack, and tested/verified/evolved independently from the stack.
[1]: https://www.openpolicyagent.org/
Related posts
- How to add Passkey Login to Next.js using NextAuth and Hanko
- Sneakiest development trap: making easy easier...
- Is it just me or is the Supabase GraphQL API really bad?
- Drizzle is just as unready for prime-time as Prisma, what else is there?
- PostgresJs: The Fastest full featured PostgreSQL client for Node.js and Deno