author here! happy to answer questions
Am I correct in saying that for read queries, you essentially translate the GraphQL query into nested jsonb_agg calls?
Pg_GraphQL: A GraphQL Extension for PostgreSQL
81–90 of 102 posts
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#82As 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…
It is nice Hasura offers it as well via the /v1beta1/relay endpoint[1].
[1] https://hasura.io/docs/latest/graphql/core/databases/postgre...
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#83Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#84Whilst I don't like the paradigm of generating a GraphQL schema from your database (or vice-versa!), I appreciate this one for having a specific goal of being able to run as part of a small database VM. So congrats on the release!
Ideally you don't expose the schema directly, you make views in another schema and expose that instead of exposing your real tables.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#85Naive question: If your entire DB schema is automatically reflected into a GraphQL schema, then how is this better than just having the client send SQL queries directly to the backend? Does GraphQL make it easier to do this securely?
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#86author here! happy to answer questions
Congrats on release. We use Hasura but haven’t been happy with their speed of iteration, lack of communication of various large bugs, and lack of M1 support / communication. But we do use a lot of their more advanced features like being able to use aggregates in sorts, aggregates in results, custom functions, etc. What are your plans there and will you have a public roadmap?
I joined Hasura recently to lead the Product team because I love the tool and the people are nice.
Thanks for the feedback on what you're finding valuable and sharing your dissatisfaction with the lack of communication around bugs and M1 support.
M1 support is very close to ready, we've been waiting on a couple of dependencies to support M1.
For what it's worth, I agree with you that our communication needs to improve and it is something we're working on.
Also, congratulations to Oliver and the Supabase team on pg_graphql! PostgreSQL extensions are slick and it'll help even more people embrace APIs from databases.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#87Earlier quoted context omitted.
Pretty recently, as of 2.0, hasura has added support for multiple databases.
It's a VERY fragile support: https://github.com/hasura/graphql-engine/issues/6648 Basically, if two entities in the databases have the same names, Hasura fails unless you manually define a unique `custom_name` for each such entity. Given that the most common multiple database scenario involves different databases with either the exact same schema (one-db-per-tenant) or similar schemas (staging vs. production database…
For what it's worth, this is addressed in 2.1, which is only out in beta. Maybe should have been there from the start.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#88Looks excellent, and I'm pleased to see you've provided the relay connection style pagination, using keyset pagination under the hood. That's awesome!
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#89I 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 think that (on paper at least) it makes perfect safe to allow graphql to be your only hammer (or turtle). I don't think federating graphql over bespoke swahger/json, sql, redis, soap is inherently better - expose graphql and federated graphql:
https://www.apollographql.com/docs/federation/v2/
Smack graphql on your postgres, and on your ldap, and your graphdb - and federated them as graphql?
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#90While this is super neat, this and the amplify thread can't help but make me wonder:
Is everyone really this okay with their API always being 1-to-1 with their DB models?
In my experience, that kind of setup is only viable for the smaller, simpler projects and otherwise you always run into something where you'd really prefer to have a layer between you and your database.
I am currently using graphql at work and this is a very hard requirement for us. Our database schema is not translated literally into graphql(or the other way around) and this is very intentional. The whole idea of the API layer is to be able to make changes to your internals without breaking all your consumers.
This was a problem with amplify(though the least of the problems we had) and it seems to me this is also a problem here, as it is with Hasura and postgrest.