{"p":"","h":{"iv":"ROXSYW+cfvEbFHu5","at":"ocxplSQjdRC3tXEtB/9/wg=="}}

I've grown a bit disillusioned by GraphQL. I hoped it would solve the problem of "kitchen sink" REST endpoints, but it seems to just have its own "kitchen sink" queries anyway.

Maybe keeping state in two places was never going to work.

7
Share
Share on Mastodon
Share on Twitter
Share on Facebook
Share on Linkedin
Edward Loveall

@nateberkopec a coworker recently pointed out to me that it really only solves an organizational problem, not a technical one.

0
1y
Matt Zagaja

@nateberkopec it’s got some nice parts and features but in practice I see little de coupling from the front and back ends as a result.

0
1y
sharplet

@nateberkopec @edward Turns out the problem all along was that designing a good API is hard regardless of which technology you choose.

0
1y
Ryan Bigg

@nateberkopec definitely need diligence to keep queries light. I still think the type enforcement through TypeScript makes it a winner over REST.

0
1y
Leonardo Xavier de Brito

@nateberkopec Did you take a look at graphiti.dev/guides/ ??
I still prefer good old REST, but I think Graphiti is a huge step forward over GraphQL.

0
1y
David Aldridge

@nateberkopec I'm not sure we could manage an API without GraphQL. Our data model just seems too complex, and although we have to put significant effort into efficiency and queryability, it's been working out pretty well. Very well received by our more technically adept clientelle, certainly.

0
1y
ingemar

@nateberkopec I detest GraphQL. It always ends up with a mess. No one dares to touch anything already in there because "it will break the front end".

0
1y
Replies