GraphQL is quickly moving to one of my least favorite technologies

Re:GraphQL is quickly moving to one of my least favorite tec... by manv1 on Friday July 29, 2022 @01:58PM (#32279986)

Graphql slows you down and enforces types. Both can be good or bad.

I suspect that front-end people like it because it requires less thinking on their part. A GraphQL call can replace a bunch of REST calls, and they don't have to deal with error handling and networking which in the front-end can be really difficult. Pushing that to the back-end makes their lives easier.

I've found that on the back-end GraphQL is more work than REST, because there's a bunch of extra crap you have to do to essentially do the same thing as REST.

And there's a bunch of stuff that's deliberately undefined, like "what do you do if there's a partial failure of your calls?"

[ Parent | on HN ]

Re:GraphQL is quickly moving to one of my least favorite tec... by eurasiantiger on Friday July 29, 2022 @03:44PM (#32281011)

At the risk of sounding like an evangelist: if it’s slowing you down, you may be doing it wrong.

If you are hand-crafting interdependent query logic to resolve GraphQL queries from multiple sources and doing that at scale, you may want to look at db adapters and the federation pattern.

Also, GraphQL absolutely still requires error handling in the frontend, and many clients actually provide great facilities for error handling: retrying failed requests, refreshing auth tokens transparently on received auth errors, network state detection, offline functionalities, etc.

[ Parent | on HN ]