I loved using GraphQL on my last big project (8 people, 5 years). We used it as a shared type layer between the Python (mypy) and TypeScript parts of our codebase. It took effort to setup, but once we had a well-typed codebase with e2e codegen, it was a real winner.
But I’m not sure GraphQL was the reason for that. We could have gotten the same benefits with gRPC.
I share the author’s sentiment that persisted queries are a necessity. But at that point, why use GraphQL? Just because it’s more expressive and has better client library support? meh…
Next time I think I will take a look at gRPC, or tRPC if it’s all TypeScript. I just want something where interfaces can be defined ahead of time (so backend and frontend developers can work on a new feature in parallel), and that encourages well-typed code on both sides.
But I’m not sure GraphQL was the reason for that. We could have gotten the same benefits with gRPC.
I share the author’s sentiment that persisted queries are a necessity. But at that point, why use GraphQL? Just because it’s more expressive and has better client library support? meh…
Next time I think I will take a look at gRPC, or tRPC if it’s all TypeScript. I just want something where interfaces can be defined ahead of time (so backend and frontend developers can work on a new feature in parallel), and that encourages well-typed code on both sides.