The Guild Blog comes from an open source group building GraphQL tools such as Mesh, Codegen, Envelop, and GraphQL Yoga.
HN commenters link its GraphQL tools, such as Mesh, in threads weighing GraphQL against alternatives like feTS and openapi-fetch.
Postgraphile https://postgraphile.org/
Hasura https://hasura.io/
Examples of "batteries included" GraphQL. Combine with a type generator for the language of your choice (eg. https://the-guild.dev/graphql/codegen), and you've got your client interface to avoid any type errors. Each comes with a GraphiQL UI for access out of the box as well. It's more turnkey than any REST solutions I've seen, that's for sure.
For different environments, it's quite possible (even normal?) to generate your types and GraphQL schema ahead of time, before CI/CD build of the UI to catch errors early at compile time.
Now add in SvelteKit with KitQL (https://www.kitql.dev/), and you've got a very simple, flexible, and efficient end-to-end solution.
As for errors, because each resolver can generate errors and not all errors are considered fatal, the errors must necessarily be embedded with the response and treated by the network client as they see fit. It's definitely different from REST, but not inferior. It's a different set of tradeoffs. When using a schema generator like Postgraphile or Hasura, it's unlikely you'd get errors in practice. The endpoints are basically guaranteed to resolve, and the generated SQL is nigh certain to execute correctly. If you get one error, chances are the whole endpoint is down due to a database connectivity problem. (That has been my experience at any rate.)
Don't take my word for it. Bring up a Postgres database, put some data in, and point one of these tools…
The OP didn't write about a UI and we don't know what their needs are, so for all we know they're writing a Python-based back-end API in REST or GraphQL which is being consumed by a mobile UI or a SPA UI in React or Vue.js or whatever, such that that back-end API doesn't have to provide a UI. If the existing Python back-end doesn't provide a UI then any proposed substitute--including one in SQL--shouldn't have to provide a UI either, just an API. In that case, there are some ready-made solutions already available:
- PostgREST (https://postgrest.org/): REST API for PostgreSQL
- PostGraphile (https://www.graphile.org/) GraphQL API for PostgreSQL
- pg_graphql (https://github.com/supabase/pg_graphql) GraphQL API for PostgreSQL
- Hasura (https://hasura.io/) GraphQL API for various databases
If you want to blend data from a web API and you're content with GraphQL, for some use-cases (not all, but some), there are options:
- Apollo Federation (https://www.apollographql.com/apollo-federation/)
- GraphQL Mesh (https://the-guild.dev/graphql/mesh)
- Hasura Remote Schema (https://hasura.io/blog/tagged/remote-schemas/)
If you want more control over the web API and you were going to fetch the data within your Python back-end and process it there, for some use-cases (not all, but some), there are options:
- pg_http (https://github.com/pramsey/pgsql-http)
Life is about trade-offs. Doing the work in SQL is not without its drawbacks, but it's also not without its benefits, and…
Indeed, I used to use Apollo for quite a while and started asking myself why I was doing this to myself, the benefits didn't seem that clear. But someone mentioned to me on /r/GraphQL about how Relay is the correct way, as Facebook initially envisioned, and once I learned it, I was hooked.
Sadly, Relay usage is 1/100 the size of Apollo, even though it is literally the way GraphQL was meant to be used, so I try to talk about it wherever I can. It really is such a simple concept (list out all of the data that you need for a given part of the app, then let the compiler manage these dependencies) that is only now starting to be used in other areas, such as the GraphQL Codegen tool: https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen. It's still more incomplete and not as powerful but hopefully we can start integrating fragment stitching into the mainline GraphQL entities so that everyone benefits from this approach.
It really reminds me of Vim, it started off being one of the best ways to write, and now 20 years later we have other editors reinventing the wheel to get closer to the Vim philosophy.
Not sure it this is a great reply. Some valid concerns were raised, and in summary all you are saying is GraphQL is awesome because it has types, schema and defined queries / mutations. This is of-course the basics of GQL, there are a lot of complexities under the surface.
GraphQL does add some risks IMHO, e.g. client can send a really complex query (even a recursive one, e.g. get accounts for user, get user for each account). We cannot say this will not happen as we define the queries ourselves, since sometimes the API is exposed to clients which are not in our control. Queries can be sent which can almost bring a server down, so you need to handle that.
Also error reporting / handling is trickier as compared to REST (e.g. https://the-guild.dev/blog/graphql-error-handling-with-fp).
Nice! You guys are crazy productive and responsive!
What I like from Mesh is also some "tidying" utilities like renaming transforms https://the-guild.dev/graphql/mesh/docs/transforms/rename
I guess some error masking/customization can be done with your hooks but I haven't played with it yet.
When .wundergraph/generated/wundergraph.schema.graphql is getting generated and there are some errors it can be harder to debug this (or I don't know how to do it properly) so I resorted to putting console.logs to places like node_modules/graphql/language/lexer.js
Rate limiting per user can be nice, but not that important, I can live with broader limiting on ingress level.
Want to give a shout out to an alternative to Apollo, which is GraphQL Yoga[0]
It tends to support the latest accepted RFCs of the GraphQL spec, works with subscriptions, can do a form of federation via Schema Stitching[1] and is a blast to work with.
The company behind it (The Guild) also has a service called Hive[2] that can provide analytics, schema checks, manage gateways etc.
For complex cases, they also have GraphQL Mesh[3] as an alternative to Apollo Gateway
[0]: https://the-guild.dev/graphql/yoga-server/docs
[1]: https://the-guild.dev/graphql/stitching/docs
[2]: https://the-guild.dev/graphql/hive
[3]: https://the-guild.dev/graphql/mesh