loading...

re: What are the cons of GraphQL? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: One more framework. More code you need to maintain. (You still own the code.) One more thing your team needs to know about. Another item you have t...
 

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.

 

The official documentation recommends:

"With GraphQL, you model your business domain as a graph"
"Your business logic layer should act as the single source of truth for enforcing business domain rules"

I realize not everyone does this, however these two statements do force a constraint on your application. But yes, it can just be a protocol if isolated enough.

It's a leaky abstraction because your client needs to have a specific implementation on the front end. And I would say it is easier to change change a specific API endpoint that has few dependencies than an interface that has many more clients.

Comparing REST to GraphQL is apples to oranges.
I don't really have any bad feelings about GraphQL, its just another hammer to hit nails with.

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.

code of conduct - report abuse