GraphQL is now available on Supabase

https://supabase.com/blog/2022/03/29/graphql-now-available

by yurisagalov • 4 years ago

222 47 4 years ago

kiwicopple6• 4 years ago

hey HN, supabase ceo here. I'm really excited about this release.

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/

andrew_3• 4 years ago

big fan of what you all are doing with this. the one massive need we still have are great user stories and recipes around auth, and some common kinds of things people do with auth, and how it affects mutations, queries, etc. It's all very vague at the moment and the docs don't go into much depth. cheers

oliverrice8• 4 years ago

If you're an existing supabase customer you don't need to change any of your existing permissions.

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

n1ru4l• 4 years ago

Had a lot of fun collaborating with you on the supabase pg_graphql example, which of course is a HackerNews clone! https://github.com/supabase-community/supabase-graphql-examp...

kiwicopple6• 4 years ago

agreed :) if you want to see the demo that The Guild [0] built using pg_graphql, see here: https://supabase-graphql-example.vercel.app/

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/

nyellin• 4 years ago

You should call it pg_pg

davidkuennen2• 4 years ago

Hey, thanks for creating this! It's nice to see more products in that space.

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.

kiwicopple6• 4 years ago

Yes we developed it ourselves. It's all open source [0] so feel free to fork and modify for yourself.

Inside that repo you'll see two key folders:

    - web: our Docs (built with Docusaurus)
    - www: our website + blog (built with Next.js)

The naming convention could be better.

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

alx__• 4 years ago

There's several ways to have a blog path contain a separate setup from the marketing/product routes.

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)

methyl• 4 years ago

Hey, I’m about to launch a product that will make it much easier to host third party website as a subdomain, ping me at lucjansuski (at) gmail if you are interested

Dowwie• 4 years ago

How would you contrast this library with what EdgeDB is doing on top of Postgres?

oliverrice8• 4 years ago

pg_graphql and EdgeDB both provide a graph-like query language on top of Postgres. EdgeDB

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

1st12• 4 years ago

EdgeDB [1] has indeed a rich GraphQL layer, but it's a very different project.

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)

[1] https://github.com/edgedb/edgedb

[2] https://www.edgedb.com/blog/edgedb-1-0

oliverrice8• 4 years ago

heyo, thanks for the ping

I'm the dev lead on pg_graphql. Happy to answer any questions!

andrewmunsell• 4 years ago

Any plans to expose RPC functions inside of GraphQL?

oliverrice8• 4 years ago

Yes, its on the roadmap to implement custom mutations reflected from user defined functions

aslakhellesoy2• 4 years ago

Excellent work!

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?

[1] https://www.graphile.org/postgraphile/functions/

oliverrice8• 4 years ago

Thanks!

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

andreypopp• 4 years ago

It's impressive that the entire thing is in pl/pgsql (apart from parsing).

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)?

oliverrice8• 4 years ago

Yes! We've been exploring https://github.com/tcdi/pgx internally so we'd be able to re-work the hotspots in rust.

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)

xrd• 4 years ago

I've been using hasura for a long time and this offering from supabase is the first time I've ever thought I could move away from hasura. Looks simply amazing.

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.

kiwicopple6• 4 years ago

entire solution from docker

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...

[1] https://github.com/supabase/postgres

[2] https://hub.docker.com/r/supabase/postgres

5Qn8mNbc2FNCiVV• 4 years ago

The GUI leaves a lot to be desired though. I'm wondering why there is no work being done on just copying what Hasura did with its RLS interface?

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)?

syrusakbary• 4 years ago

Nice! I was already pretty excited about you guys, and this only fuels up more excitement since I always been a GraphQL lover.

I'm impressed by the pace that you are releasing new products... keep it up team!

zinclozenge• 4 years ago

The Friday announcement is looking like they will announce functions/lambdas.

privatemonkey• 4 years ago

I have to second that. Supabase rocks!

tomatowurst3• 4 years ago

been curious as to what sort of savings you've been able to get with supabase because we are approaching a few thousand dollars to store a couple terabytes on DynamoDB

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.

kiwicopple6• 4 years ago

One thing to mention is that DynamoDb and Postgres are vastly different databases, so the migration won't be a simple "dump and restore".

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

tomatowurst3• 4 years ago

Appreciate it, really think AWS dynamodb is not an option for those running a bootstrapped business and dealing with large amount of data anymore, guess I'm going to have to bite the bullet and just do more research on hardening dedicated servers ourselves. Really the security and peace of mind from relying on AWS was what we were paying for but the cost is too much as our data storage needs are exploding.

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!

DenseComet• 4 years ago

Take a look at ScyllaDB Alternator [1], which is API compatible with DynamoDB. Scylla also supports multiregion clusters, which should help with latency. I've not used alternator, but I've had a good experience with Scylla, and it might be worth looking into as a lower effort way to move off DynamoDB.

[1] https://www.scylladb.com/alternator/

tomatowurst3• 4 years ago

wow! didn't know this existed, so does this mean I can self-host and still keep my dynamodb api code?

alexkreidler• 4 years ago

Hi all, this sounds very cool. How does pg_graphql compare to Postgraphile? https://github.com/graphile/postgraphile (besides I guess running in the DB with PLpgSQL instead of as a NodeJS server)

Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?

Thanks!

oliverrice8• 4 years ago

How does pg_graphql compare to Postgraphile?

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!

sk55• 4 years ago

Does this support Graphql subscriptions as well?

realPubkey• 4 years ago

From the example generated schema in the docs, it does not look like they have subscriptions.

oliverrice8• 4 years ago

Not yet, but we're evaluating options for how we'll be able to support this in the future

gsvclass• 4 years ago

Also checkout GraphJin an automatic GraphQL to SQL service in Go. It's packed with features including support for GraphQL subscriptions, etc and can be used as a standalone service or a library. Also it's a pure OSS project not a startup. https://github.com/dosco/graphjin

elitan• 4 years ago

Congratulations on the GraphQL launch. I think it is a step in the right direction :)

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)

GraphQL is now available on Supabase

Related Stories