Then it's just REST with extra steps and none of the benefits
This gives the front-end developers lots of flexibility when initially developing new screens and components. Once the UI is ready to ship, the backend team checks to make sure that performance is acceptable (optimizing if necessary), allowlists the new query/queries, and ships to production.
No. With RPC we can just make a HibernateServer call and be done with it.
We just joined the CNCF, too!
The best practice for GQL is to make frequent, small, queries (Apollo handles batching them) throughout your application. Apollo won't do any extra work to fetch new fields if they're already in the cache
Not to be that person because I understand there's always edge cases, but in general with GQL if your queries are highly complex or too nested "you're doing it wrong™"
using OPENAPI, rpc, GQL types in client, etc to share typing (schema) information between client/server
resolver/dataloader in GQL, eager join in ORM is to handler internal data composition
presenter layer should not care about data composition, so that writing Query at presenter is an anti-pattern.
presenter should fetch schema info & data passively, like what https://github.com/hey-api/openapi-ts did, the job of implementation belongs to backend.
In fact what rest/rpc really need is the resolver and dataloader, to help backend easily extend or composing data together, and immediately transferring the schema & data to clients.
pydantic-resolve is the python binding for this idea.
One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already 'vetted'", where you can look at things like complexity, ACL behavior, etc ahead of time. Since clients (in my experience) aren't usually modifying GQL queries at runtime, this is a pretty good tradeoff.
All that said, I find Buf Connect to be the best set of tradeoffs for most projects: strongly typed servers and clients, strong ecosystem support around protobuf (e.g. to generate an OpenAPI spec), a standard HTTP/JSON interface for easy curl et al compatibility, etc.
OpenAPI as the source of truth is annoying because it's too flexible, and it's rarely possible to generate type-safe servers + clients from an OpenAPI spec without running into one edge case or another.