GraphQL is now available on Supabase(supabase.com) |
GraphQL is now available on Supabase(supabase.com) |
Our GraphQL implementation is built on top of pg_graphql[0], a PostgreSQL extension we open-sourced a few months ago. The implementation works with a lot of native PG functionality (like Row Level Security). You can also do a some neat things with PG GRANTS, enabling/disabling access to different tables/columns to effectively serve a different GraphQL API depending who is "logged in".
On Supabase, the extension is served via PostgREST[1] using the public PostgreSQL function exposed by pg_graphql. PostgREST exposes PG functions as RPC routes (in our case we also map /rest/v1/rpc/graphql => /graphql/v1)
I'll ping the main dev (@oliverrice) and make sure he is here to answer any technical questions. This is just one of the exciting features we're launching this week. Stay tuned for one of our most-requested features later this week.
[0] pg_graphql: https://github.com/supabase/pg_graphql
[1] PostgREST: https://postgrest.org/
Also congrats for their own launch today - GraphQL Yoga 2.0: https://www.the-guild.dev/blog/announcing-graphql-yoga-2
[0] The Guild: https://www.the-guild.dev/
pg_graphql filters out any tables/columns that aren't accessible to the user making the request. It also respects your row level security policies.
If you can't see something in the introspection schema, you'll get a friendly error if you try to access it. pg_graphql does not used any privileged access so the queries are being executed in a context that is identical to supabase REST
Off-Topic: How did you create your blog? It's seems like you developed it yourself? I'm currently contemplating on how to create the blog for my product, since I want to have it integrated into the main website as well (as subdirectory). It's not really possible when using third party providers. You always have to use subdomains there.
Inside that repo you'll see two key folders:
- web: our Docs (built with Docusaurus)
- www: our website + blog (built with Next.js)
Both of these are deployed to Vercel as separate "sites" using their mult-zone setup [1]. This setup is so that the docs are deployed on a sub-path (supabase.com/docs), rather than a subdomain (docs.supabase.com)
[0] https://github.com/supabase/supabase
[1] Vercel multi-zones: https://nextjs.org/docs/advanced-features/multi-zones
One is to run a reverse proxy on the root domain to pull in separate routes for various services.
https://github.com/http-party/node-http-proxy
You can do rewrites at the server level for the root domain
Or if the app on the root domain can do the routing for you (have done this before with a Rails app)
While it also builds on top of Postgres, EdgeDB replaces the entire relational database front-end. EdgeDB features a SQL replacement language called EdgeQL (analytical capabilities of SQL married with deep-fetching in GraphQL), a higher-level data model (tables -> object types), integrated migrations engine, a custom protocol with great performance & great client APIs, and many other things. Read more here [2].
(disclaimer: I'm EdgeDB co-founder)
philosophically (I think) EdgeDB tries to do a more complete job of abstracting over Postgres. It has a custom query language (and GraphQL support via a plugin), and a migration system. Its runs separately from the DB.
In contrast, pg_graphql is more narrowly scoped. It enables you to query your existing Postgres database without caring how your data is structured or having any interactions with migrations. It also runs directly inside the database, so theres no separate process/server to manage.
The EdgeDB folks have a great comparison of GraphQL vs EdgeDB syntax on their site https://www.edgedb.com/docs/graphql/mutations
The Gui for adding roles and tying them to postgres access is very slick with hasura. Is this done manually via SQL commands with supabase?
My litmus test will be if I can run the entire solution from docker or if I'll need to assemble the pieces. Hasura is so easy to boot up with a few environment variables, run locally or inside dokku, and that makes it so simple to set up and start building.
We PR'd this into our docker-compose today [0]. We're always a bit slammed during Launch Week, so if you spot any problems let use know and we'll patch it up asap.
The extension is also deployed directly into our PG bundle [1] which is available in docker [2]
> The Gui for adding roles and tying them to postgres access is very slick with hasura. Is this done manually via SQL commands with supabase?
pg_graphql works with Postgres Row Level Security - we provide a GUI for this in our Dashboard, but they are also just native PG Policies, so you can write them in raw SQL. (I haven't tried Hasura so I don't know if this is a direct comparison.)
[0] https://github.com/supabase/supabase/pull/6138/files#diff-41...
I've used it for small projects where permissions are done in an hour of work and big projects with complex permissions were also totally doable, albeit a bit convoluted but that's just complex permissions being convoluted themselves
So why not just copy it and write the "policy" behind the scenes (optionally)?
Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?
Thanks!
PostGraphile is very close to pg_graphql in goals. It was a big help during development to be able to reference their implementation.
> Did you think about integrating Postgraphile with the Supabase ecosystem..?
For sure! We wrote a blog post about why we chose to implement the reflection engine as a Postgres extension here https://supabase.com/blog/2021/12/03/pg-graphql w/ a direct comparison against Postgraphile and Hasura.
The summary is that we tried out Graphile and Hasura and found that they were both very workable options. We had a few other requirements that led us to the extension instead:
- An extremely minimal memory footprint
- Performance scales with the DB
- 100% security and visibility interop with PostgREST (powers Supabase REST API)
The blog post's "motivation" has some more specifics if you're interested!
I'm impressed by the pace that you are releasing new products... keep it up team!
I'm the dev lead on pg_graphql. Happy to answer any questions!
Postgraphile uses a naming convention for postgres functions to extend the GraphQL schema [1].
Do you have any plans to support a similar mechanism in pg_graphql?
Yes, we currently support extending table types via functions using a naming convention. The docs for that feature are available here https://supabase.github.io/pg_graphql/computed_fields/#exten...
It's also on the near-term roadmap to implement custom mutations from user defined functions, similar to postgraphile
Have you considered any other implementation strategies (C native extension, any other pl/* or maybe running an out of PostgreSQL process which does GraphQL to SQL compilation)?
We haven't decided to go that route yet but its been incredibly easy to work with & I'm psyched about what options it could open up like:
- Stateless requests (no schema cache)
- Subscriptions (via a background worker)
I see a lot of mentions of Hasura in the comments.
If you'd like what Supabase is building but prefer using Hasura you might want to check out what we're building at Nhost (http://nhost.io/). We use Hasura's GraphQL Engine for the API layer while also providing Postgres, Auth, Storage and Serverless Functions.
(CEO of Nhost)
Thinking of buying a dedicated server from Hetzner to run Supabase on it instead but worried about latency. awful that we have to move away from AWS for this but with four/five dedicated servers in EU, US-West, US-East, Singapore and Tokyo, we could have a fixed monthly storage/database cost with some globalized latency (client would connect to whichever dedicated server is available).
we realize that we are at complete mercy of AWS as was expected but the database storage cost was a curveball, so much so that we are thinking of self-hosting database ourselves but seems like a daunting task of its own.
tldr: unpredictability and variability of storage size on Dynamodb is forcing us to explore a more reliable fixed cost solution via self-hosting and hardening our dedicated servers running Supabase.
You're right - it will be a daunting task, but one that only becomes more daunting the longer you wait. If you make the migration to Hertzner + self-hosting (even just to pure Postgres), I'm certain you will see huge savings. It's hard to give exact numbers without knowing your workload, but feel free to reach out if you want to step through the numbers. We're not one-eyed about Supabase, but we feel that Postgres is a solid choice for your core-OLTP workloads. We love seeing more businesses adopt it. It's good for the ecosystem, and good for open source in general
At this point I might even move off AWS Lambda somehow, its quite ironic, we do consulting to help businesses get on AWS but we are moving off it due to rising costs!
I'll pass that onto the team. We've been planning to re-write the Policy editor for a while now - this feedback is a good justification to prioritize the work.
And just for the record I'm not affiliated with Supabase, I just use it on a side project and quite like it.