Live data from Hacker News

Pg_GraphQL: A GraphQL Extension for PostgreSQL

supabase.com

51–60 of 102 posts

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#51
post #46

supabase look like so helpful tool. which has anyone use in production? does it have a hasura like event trigger mechanism?

Yes, event triggers are built right into Postgres so they're supported out-of-the-box

Event triggers are the mechanism pg_graphql uses to keep the GraphQL schema up-to-date with the SQL schema

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#52

This is awesome! Really creative approach to the problem. Does this also support custom datatypes that can be marshalled to json? For example, PostGIS geometries?

Currently, any datatypes that are not in the allow list https://supabase.github.io/pg_graphql/reflection/#type-conve... are cast as strings, but prioritizing a JSON conversion if one is available is a great idea that we'll look into

Personally I like the idea of allowing the user to create a cast:

https://www.postgresql.org/docs/current/sql-createcast.html

There are some weird permissions issues to work out IIRC, but this allows the user to specify how the json should be marshalled, and then can be implicitly or explicitly used by any sql statements. This is how PostgREST solves this problem, and I currently have a few custom casts created for range and multirange datatypes through my PostgREST server.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#54

This is awesome! Really creative approach to the problem. Does this also support custom datatypes that can be marshalled to json? For example, PostGIS geometries?

Currently, any datatypes that are not in the allow list https://supabase.github.io/pg_graphql/reflection/#type-conve... are cast as strings, but prioritizing a JSON conversion if one is available is a great idea that we'll look into

Don't know how your JSON generation works but when using `row_to_json()`, all PostGIS geometries are automatically casted to GeoJSON objects by default which is very convenient.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#55
post #2

Curious how it compares to https://www.graphile.org/postgraphile/

I had to make sure someone had plugged postgraphile here. It's a great system. What impresses me most about it is how it grows with the complexity of your application. There are so many thoughtful points of extensibility built in, I always have confidence that I can go into the docs and find a way to do what I need to.

That reminds me, I need to figure out how to get my employer to sponsor the project...

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#56

As co-founder of another database company in the PostgreSQL ecosystem, I have to say that I'm really impressed with the quality and velocity of launches from the Supabase team. Nothing else to add, except please keep up the great work!

What's your company?

Timescale. Another Postgres adjacent startup that's doing amazing work.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#57
post #16
post #5

That’s interesting. How does it deal with authentication and authorization? It it handles those well, it could be a real “serverless” solution for most CRUD apps.

As the sibling comments point out, it uses Postgres Row Level Security (RLS). For an approachable introduction to how Supabase's auth works: https://supabase.com/docs/guides/auth > 1. A user signs up. Supabase creates a new user in the auth.users table. > 2. Supabase returns a new JWT, which contains the user's UUID. > 3. Every request to your database also sends the JWT. > 4. Postgres inspects the JWT to determine t…

Is there integrated way to achieve claim based approach where access to a given resource is governed by both uid (lets say org uid, and all users belong to particular org) and set of claims (lets say there are at least CRUD claims for all tables and I can set for any user any combination of them, or create a role containing them then assign that role to a user) ?

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#58

Earlier quoted context omitted.

Hey it's unrelated but, what's the relationship between Supabase and Postgrest? My understanding is that Postgrest is a separate project that began development in an unrelated way to Supabase, and Supabase is just an user. Is that correct? But, Supabase is also a contributor to Postgrest, right? Does Supabase employs engineers dedicated to it?

> What's the relationship between Supabase and Postgrest? Supabase uses PostgREST for its automatic/reflected REST API > Supabase is just an user. Is that correct? yep! > Does Supabase employs engineers dedicated to it? https://supabase.com/blog/2020/06/15/supabase-steve-chavez

Cool, thanks!

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#59
I enjoyed Sam Newman's take on this capability [1]

> Great to see AWS providing direct data coupling as a service. /s

> This service allows you to directly map a GraphQL endpoint to a database table. It’s like putting getters and setters on an object and claiming your encapsulating private variables. The end result is coupling between GraphQL clients and the underlying datasource.

> Information hiding is a key concept in independent change. Can I change the provider (of the GraphQL) endpoint independent of the clients? Directly exposing internal data structure makes this very difficult.

And [2]:

> So a few people have asked why I have this snarky response. What is my problem with this service? Well, to be clear, it’s not an issue with GraphQL, it’s an issue with direct coupling with underlying datasources #thread

> The service as advertised makes it simple to map a GraphQL definition against a database. Now, what’s the problem with this? Well, the devil here is in the detail. But fundamentally it comes down to how important information hiding is to you.

> ... see the thread for more ...

[1] https://twitter.com/samnewman/status/1346541251617828877 [2] https://twitter.com/samnewman/status/1346749556583780352

Post reply on HN