[HN Gopher] GraphQL is now available on Supabase
___________________________________________________________________
GraphQL is now available on Supabase
Author : yurisagalov
Score : 109 points
Date : 2022-03-29 17:48 UTC (5 hours ago)
(HTM) web link (supabase.com)
(TXT) w3m dump (supabase.com)
| sk55 wrote:
| Does this support Graphql subscriptions as well?
| oliverrice wrote:
| heyo, thanks for the ping
|
| I'm the dev lead on pg_graphql. Happy to answer any questions!
| [deleted]
| kiwicopple wrote:
| 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/
| davidkuennen wrote:
| 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.
| kiwicopple wrote:
| 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
| davidkuennen wrote:
| Wow, thanks. Much appreciated.
| alx__ wrote:
| 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)
| Dowwie wrote:
| How would you contrast this library with what EdgeDB is doing
| on top of Postgres?
| oliverrice wrote:
| 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
| 1st1 wrote:
| 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
| andrew_ wrote:
| 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
| oliverrice wrote:
| 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
| andrew_ wrote:
| that's great, but what if I want to add a role to my user
| to do something like send an email with an extended schema
| (when that lands). What if I'm not familiar with "row level
| permissions" and I have a SaSS app where different users
| can access different rows based on column content?
| Scenarios like those are where the docs fall short. PLEASE
| think like new users and _not_ like seasoned engineers with
| prior experience with the feature set.
| n1ru4l wrote:
| 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...
| kiwicopple wrote:
| 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 wrote:
| You should call it pg_pg
| xrd wrote:
| 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.
| kiwicopple wrote:
| > 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 wrote:
| 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)?
| kiwicopple wrote:
| Thanks for the feedback - sounds like we need to check out
| the Hasura implementation.
|
| 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.
| syrusakbary wrote:
| 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 wrote:
| The Friday announcement is looking like they will announce
| functions/lambdas.
| tomatowurst wrote:
| 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.
| kiwicopple wrote:
| 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
| alexkreidler wrote:
| 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!
___________________________________________________________________
(page generated 2022-03-29 23:00 UTC)