Hacker News new | ask | show | jobs
by awirick 749 days ago
I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs.

The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.

1 comments

OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.
At that point you've recreated the exact same problems many here are complaining about, N+1, authorization on leaf nodes, ability for the client to create queries that are hard to optimize, etc...
The client doesn't create queries in this situation, you explicitly define them server-side. So optimization is easier. I've seen this time and again with services that aren't GraphQL but tried to provide a semi-freeform query feature; if you only have a few clients and control them all, it's way easier to just make separate endpoints for whatever they need. If you have many clients, maybe GraphQL makes sense.

Auth on leaf nodes, maybe I'm not understanding the issue but it seems solved without GraphQL. JWTs are one way.