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

You should call it pg_pg

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/

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

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

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.

Supabase's row level security is just postgres row level security, it's not proprietary to Supabase. Postgres documentation, blog posts etc on RLS will apply to Supabase too.

I get this, and I've been using postgres for a long time, so I should get this. My point is that the barrier for entry is very high. Most folks that have experience with GraphQL and not intimate knowledge of Postgres security/access are going to struggle with this. It's much different than say, Postgraphile or Asura - both of which have a much lower barrier for entry. Folks are naturally going to compare. I've been following their GraphQL extension since its development announcement and I think this will end up being the better GraphQL product in the long term. I want Supabase to be a world-class product because I'm a fan, and that means world-class documentation.

You're definitely not wrong. I think Supabase will get there ultimately. But being a startup and presumably a small team, I think it's ok for them to lean on "Supabase is basically postgres as a service so postgres docs can fill the void for now".

And just for the record I'm not affiliated with Supabase, I just use it on a side project and quite like it.

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.

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

Wow, thanks. Much appreciated.

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)

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

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

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

Are there any plans to provide a Java client for EdgeDB?

Eventually yes, but we aren't working on it right now.

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