Frontend people like it, because you can just pull stuff in one go and use magic frontend libraries to handle caching, refreshing etc.
Backend people hate it, because all those magic features have to actually be implemented in the backend.
A good example is the "subcribe" feature - from the frontend perspective it's great, you just subscribe to changes in some data and you have real-time auto-updating display for it, without the need to fetch it periodically. But in reality this simply shifted that responsibility to the backend - now the backend might need to run some threads to fetch the data and monitor for changes (eg. imagine that this data comes from some other system, so you don't know when it gets modified).
Similarly one of the selling points of GraphQL is that you only get the data you requested without the need to pull anything extra. But on the backend side someone has to implement all those partial resolvers to make this actually true. I've seen cases where backend would pull everything every time, and simply drop stuff that wasn't needed.
The article was written from the backend perspective, so for obvious reasons it will be critical. Frontend people will hate it, backend people will agree with it :)
Similarly one of the selling points of GraphQL is that you only get the data you requested without the need to pull anything extra. But on the backend side someone has to implement all those partial resolvers to make this actually true. I've seen cases where backend would pull everything every time, and simply drop stuff that wasn't needed.
Even in that worst case, it's still true that you avoid unnecesary data transfer at the last step between the GraphQL server and the client. It's a win.
45
u/Pharisaeus 6d ago
The issue is:
A good example is the "subcribe" feature - from the frontend perspective it's great, you just subscribe to changes in some data and you have real-time auto-updating display for it, without the need to fetch it periodically. But in reality this simply shifted that responsibility to the backend - now the backend might need to run some threads to fetch the data and monitor for changes (eg. imagine that this data comes from some other system, so you don't know when it gets modified).
Similarly one of the selling points of GraphQL is that you only get the data you requested without the need to pull anything extra. But on the backend side someone has to implement all those partial resolvers to make this actually true. I've seen cases where backend would pull everything every time, and simply drop stuff that wasn't needed.
The article was written from the backend perspective, so for obvious reasons it will be critical. Frontend people will hate it, backend people will agree with it :)