4 ms·
It can't fall out of favor if it was never really in favor to begin with. GraphQL was a quite brief hype then a big technical debt.
by owebmaster 1y ago
It can't fall out of favor if it was never really in favor to begin with. GraphQL was a quite brief hype then a big technical debt.
- tunesmith 1y agoSo if not graphql, then what's the latest "in-favor" thinking to solve the problem of underfetching and overfetching? Especially in an environment with multiple kinds of frontends?
- cluckindan 1y agoWhat do you mean by technical debt here?
- owebmaster 1y agoEverywhere I worked with GraphQL it was always a pain for the backend team to keep the graphql server updated and also a pain to use in the frontend, simple REST apis or JSON-RPC are much better.
- cluckindan 1y agoInteresting. Why did you not have these pains with other tech? Team unfamiliar with GraphQL?
- owebmaster 1y ago> Why did you not have these pains with other tech? You don't need a new layer between database -> backend -> frontend So GraphQL became a backend-for-frontend layer that needs maintaince. The team knowing GraphQL or not is not what causes this, but definitely makes it worse as they use the tool, which is quite complex, wrongly. NextJS is the "evolution" (or more like growth? as a tumor) of this backend-for-frontend approach, glued with the mentioned RSC in this post. Great recipe to fight accidental complexity all days and nights.
- cluckindan 1y agoSo because they were not generating resolvers from the schema, a maintenance burden was created. You CAN create resolvers manually but that’s really not the best idea when automated approaches exist. That’s poor engineering, not bad technology. GraphQL federation is where the thing really shines.
- RexM 1y agoInteresting take considering graphql adoption is growing and generally in favor at my company.