I bet everyone here has heard about, used and loved GraphQL over REST API. I also know the reasons why GraphQL is better than REST API.
BUT
Everything comes with drawbacks.
Even today, not all new startups and apps use GraphQL in their backend.
What could be the reason?
What is the biggest hurdle you face when you learn/work with GraphQL?
And what are the solutions to it?
What are the CONS of GraphQL?
I am asking just for the sake of knowing why some people might not like GraphQL.
I ❤️ GraphQL.
#devDiscuss
Latest comments (41)
Inability to fetch all fields with a wildcard:
github.com/graphql/graphql-spec/is...
How about using REST for write, and graphql for read API operations?
🙌
I love it as well. A few down sides is consumers have learn a new way of requesting data. Over selection is something you have to handle. Error handling is strange and everyone does it different. I think the advantages out way these issue but not everyone agrees.
One thing that hasn't been called yet is the the spec itself or pretty open. In practice it's not a big problem, because most clients and servers take inspiration from how Appolo did it. For example some servers and some clients allow to do queries and mutations over a websocket, but some don't.
Your client needs knowledge and implementation with REST as well since the structure of data is static and defined server side.
And if you change a rest endpoint, you’d likewise have to change all clients, since they have no say in the response’s structure.
The abstraction Grapqhl provides allows you to make api changes server side without affecting the data structure the clients expect.
And yeah there’s no heat here, sorry if it came off like that 😅
Hammering out these small differences can provide some good insights is all.
"And if you change a rest endpoint, you’d likewise have to change all clients, since they have no say in the response’s structure." What? No, you change the version.
Caching
GraphQL isn’t a framework though it’s a protocol. It’s another protocol layer on top of HTTP, sure, but it doesn’t force you into any way of building an app like a framework does.
What makes you think it’s a leaky abstraction? It seems like REST is a much leakier abstraction over any dataset since it’s much more work to modify a rest api and clients than it is to correct a single graphql resolver.
I would say as you mentioned just the knowledge and learning, which is no worse than any new tooling.
Of that the one draw back I have is within the query syntax itself on consumption and getting to grips with the query/mutation fragmentation syntax a bit of a steep learning curve but easily surmounted. :)
Where rest does win is often with simple get calls for micro data where mapping the fields will take double the time to schematics forward. In these cases I have abstracted the calls into a simple get endpoint alongside my app build to save the bloat on the frontend.
Very little other than that I can think of as far as cons.
Another thing to keep in mind in addition to everything that's been mentioned already is that instrumentation requires a little additional effort. You normally get response time metrics almost for free with the majority of frameworks but you're hardly gonna get resolver-level granularity instrumentation with GraphQL unless you build it yourself.