Pg_GraphQL: A GraphQL Extension for PostgreSQL • Hacker News Board

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#71

Post by a-priori » Fri, Dec 03, 2021, 7:37 PM UTC

intrasight wrote: post #70

This runs within the database engine? Doesn't that adversely affect scalability?

On the contrary, this could scale much better.

If the GraphQL server is a separate component, then a GraphQL query needs to do its own query planning, then the resolvers turn that into SQL queries to the database, then the database does its own query planning and execution for each query.

Since one GraphQL query will often turn into multiple SQL queries, there's likely to be duplicated work on the database side across those queries since they relate to the same data.

By integrating the GraphQL server into the DBMS, it can do query planning once for the whole GraphQL query, which means that it can reuse parts of the plan and prevent duplicated work and N+1 queries.

Either way it's going to have to query the database to get all the data, so the essential work is the same. But this way you have opportunities to reduce wasted work to process the whole GraphQL query.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#72

Post by syastrov » Fri, Dec 03, 2021, 7:39 PM UTC

intrasight wrote: post #70

This runs within the database engine? Doesn't that adversely affect scalability?

Most likely the actual work done by this extension is little compared to the actual work required to perform the queries…but…

If you want to scale horizontally you can run multiple read replicas with something which distributes connections evenly to the replicas.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#73

Post by mritchie712 » Fri, Dec 03, 2021, 7:56 PM UTC

mmargerum wrote: post #21

Thanks for giving this to the community. Will definitely be looking at you for a SASS app i'm building.

They just released a free course you might like: https://egghead.io/courses/build-a-saas-product-with-next-js...

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#74

Post by lstamour » Fri, Dec 03, 2021, 8:00 PM UTC

sporkland wrote: post #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 concep…

We could use PG views or functions to make our own abstraction layer inside the database and handle security better, etc. But putting that complicated database rebuild aside, just because we can publish GraphQL APIs from the database doesn’t mean we have to: it would be interesting to use GraphQL as a communications layer from backend to database too. Just as frontend-to-backend could use GraphQL, so too could backend-to-database communication, but with different schemas (data models) between frontend and backend. Having a backend GraphQL server between the frontend and database could allow for connection pooling, schema versioning and abstraction, for proxying multiple databases, handling business logic and perhaps validating inputs, caching or managing compute tasks.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#75

Post by mritchie712 » Fri, Dec 03, 2021, 8:00 PM UTC

solidsnack9000 wrote: post #49

Apaec wrote: post #29

How does it compare with https://github.com/solidsnack/GraphpostgresQL ? It's like 7 years older and it takes the same approach, it seems.

GraphpostgresQL is no longer maintained and hasn't been updated for many years. I am the person who wrote it. It was a proof-of-concept, written in PL/pgSQL. This made it fairly easy to set up and test but made maintenance and contributions very difficult.

Never ceases to amaze me when someone pops up on HN with a "yeah, I made that, ask me anything".

Nice work, looks like an awesome project.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#76

Post by samwillis » Fri, Dec 03, 2021, 8:13 PM UTC

oliverrice wrote: post #7

author here! happy to answer questions

Hi Oliver, Supabase team,

Love what you are doing with Supabase!

Quick question, have you considered building any kind of local mirroring system for offline mobile app/PWA, say on top of SQLite? Something like Realm for mongodb or PouchDB/Couchbase Lite for CouchDB/Couchbase.

It would obviously need devs to add some extra columns to tables for tracking, and a way to define the merge/overture characteristics for each column, but it would be awesome to have something like that!

It’s something I have thought about building for a while but never found the time. (I want to combine it with Yjs for collaborative offline rich text editing)

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#77

Post by AtNightWeCode » Fri, Dec 03, 2021, 8:16 PM UTC

sporkland wrote: post #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 concep…

For front-end development where you already using GQL as a layer on top of content I can see the use case for this.

A lot of old systems have this tight coupling between databases and back-end code. I would advice against going down that path.

GraphQL was designed to solve the flaws in the utterly poor service design at Facebook. Do not forget that.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#78

Post by doctor_eval » Fri, Dec 03, 2021, 8:37 PM UTC

Twisol wrote: post #63

sporkland wrote: post #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 concep…

I don't think Sam is wrong, exactly -- and that second thread does add some of the missing nuance -- but I do think there's a key missing piece here. He's absolutely right that you shouldn't couple directly to the underlying representation. But Postgres lets you transparently define views that can be queried (and, with a little more elbow grease, updated) just like any other table. You can provide decoupling from wit…

Totally agree.

I consider views and functions to be my database’s API, and when using a wrapping tool (I’ve used Hasura) I get it to use only the views in a dedicated API schema rather than the tables directly.

In addition to coupling, you want control over what tables and fields you publish.

A simple view is literally one line of SQL; it’s hardly a burden.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#79

Post by config_yml » Fri, Dec 03, 2021, 8:42 PM UTC

oliverrice wrote: post #45

config_yml wrote: post #34

Earlier quoted context omitted.

So you're calling Graphql via PostgREST, but I didn't ready about why you're including Graphql in the first place. Isn't it orthogonal to PostgREST which is already used in your stack?

PostgREST does solves a few of the core challenges that GraphQL is intended to address like over/under-selection and resource embedding (relationships). Even so, there has still been a lot of interest in GraphQL so users can leverage the growing ecosystem for things reflecting the data model/types for client usage, offline caching, etc

Thanks, this was missing for me in the Motivation section on the blog post. It was a genuine question, not sure why it‘s downvoted.

Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL

#80

Post by n0w » Fri, Dec 03, 2021, 8:43 PM UTC

As someone that has used Hasura very heavily in the past, I can see the operational benefit of not needing to manage one more service.

The talk about memory constraints seems a bit odd though. The extension is still going to require memory and without profiling the alternatives it seems odd to say: "we won't use any more memory with an extension". Especially when you say "these established/stable alternatives fulfill all our feature requirements". In practice I always found Hasura to be reasonably lightweight (I can't speak for PostGraphile).

I think there's an advantage to running this API layer as an additional service in front of the DB though. Then it can act as an API gateway to more than just your database.

Also, the generation of a "Relay style" schema is off putting for me. I'm really not a fan of the style and was one of the biggest advantages for me in using Hasura.