I use Hasura heavily and the thing I wish it had out of the box is groupby aggregates.
This doesn't have aggregates yet but when that conversation happens hopefully it's considered.
Pg_GraphQL: A GraphQL Extension for PostgreSQL
91–100 of 102 posts
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#92Whilst 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.
Even so, the patterns I really enjoy using with GraphQL make heavy use of interfaces and unions; and I’ve yet to see any automatic “data model to schema” tool make use of them.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#93While 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…
[deleted]
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#94While 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…
> The whole idea of the API layer is to be able to make changes to your internals without breaking all your consumers.
You can do so by not exposing tables and instead use views and stored functions/procedures.
See https://postgrest.org/en/v9.0/schema_structure.html#schema-i...
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#95Can I also install such extension in a Google Cloud SQL Instance?
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#96Earlier quoted context omitted.
> It would take a lot for me to switch. We were pretty happy with Hasura but had to switch to Postgraphile due to poor multi-database support, bummer. (Postgraphile is not as polished as Hasura in some ways, but since it can used as a library, it's easy to dynamically create N instances of it with different configurations at runtime. Hasura required our ops team to define a new instance of the service in the docker-c…
Hey, I'd be curious to hear your thoughts on our solution. It allows you to combine any number of Databases with PostgreSQL, MySQL, SQLite and SQLServer are supported, here's the full list of supported DataSources: [0] Our solution comes with a feature called Namespacing [1], which means, every API has its own namespace so there are 0 collisions between the different types and fields. It even goes so far that we also…
Hadn't heard of Wundergraph, I will keep it in mind if we encounter issues with Postgraphile. Thanks!
Regarding your solution, it seems to be the same that Hasura is working towards. It's a perfectly fine solution if you have a few types that happen to clash in their basic names (we have that too, e.g. for "products.suppliers" vs "services.suppliers").
For multi-tenant solutions, i.e. where all data sources are identical but they refer to different customers' data, separated by user/schema/database/instance, namespacing works but it's not _great_.
It means that the client code needs to get the tenant's namespace from somewhere (probably a claim in the authn system), and then manually interpolate it in all the graphql queries. It's not a security flaw (if you screw up and query spacex_users from a different tenant, you'll just get a 404 - I hope!), but it's going to play awkwardly with most developer tooling, having to always work with interpolated strings.
More importantly, if you use namespace for tenants, now you can't also use them to solve simple name overlaps, unless you split each tenant over multiple APIs.
If you want to improve your multitenant story, here's what we did with Postgraphile (which is a straight adaptation of what our .NET backend does): when the backend starts up, it initializes one identical GraphQL source per tenant. Then looks up each tenant's authorization URL. When a request comes in, the backend validates the auth token, and it uses the signed authorization URL to determine which GraphQL source should run the query.
In this way the clients don't need to worry about tenancy or namespaces at all, there might be a single tenant for all they know. The same request that a developer tests with his login under TestCompany will also run for every other customer, but the auth token and the auth token alone determines which data source it gets run against.
As you can see, this approach isn't a replacement for ad-hoc namespacing. It's meant specifically for the scenario where the same identical schema exists in multiple data sources.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#97Earlier quoted context omitted.
Hey, I'd be curious to hear your thoughts on our solution. It allows you to combine any number of Databases with PostgreSQL, MySQL, SQLite and SQLServer are supported, here's the full list of supported DataSources: [0] Our solution comes with a feature called Namespacing [1], which means, every API has its own namespace so there are 0 collisions between the different types and fields. It even goes so far that we also…
Hadn't heard of Wundergraph, I will keep it in mind if we encounter issues with Postgraphile. Thanks! Regarding your solution, it seems to be the same that Hasura is working towards. It's a perfectly fine solution if you have a few types that happen to clash in their basic names (we have that too, e.g. for "products.suppliers" vs "services.suppliers"). For multi-tenant solutions, i.e. where all data sources are ident…
Hey, thanks for your feedback. This sounds like a great feature to add. Would you be available for a chat? I'd like to learn more about how you solved this problem. Your solution sounds very well thought out. You can find me on this discord: https://wundergraph.com/discord
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#98Earlier quoted context omitted.
Hadn't heard of Wundergraph, I will keep it in mind if we encounter issues with Postgraphile. Thanks! Regarding your solution, it seems to be the same that Hasura is working towards. It's a perfectly fine solution if you have a few types that happen to clash in their basic names (we have that too, e.g. for "products.suppliers" vs "services.suppliers"). For multi-tenant solutions, i.e. where all data sources are ident…
Hey, thanks for your feedback. This sounds like a great feature to add. Would you be available for a chat? I'd like to learn more about how you solved this problem. Your solution sounds very well thought out. You can find me on this discord: https://wundergraph.com/discord
No problem. Not right now, but I'll see if I can drop by in the next couple of days.
Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#99Re: Pg_GraphQL: A GraphQL Extension for PostgreSQL
#100author 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…
There have been a few discussions about offline-sync support for the postgREST clients but nothing concrete to announce yet
On the graphql side, we'll be targeting making mutations offline capable but are still in the brainstorming phase. If you have any suggestions for how you think it could work please open an issue on supabase/pg_graphql and we can discuss over there