4 ms·

> GraphQL is a huge burden I’ve recently been bolting graphql support onto a midsize legacy webapp with the goal of making native mobile apps easier, and so fa

> GraphQL is a huge burden I’ve recently been bolting graphql support onto a midsize legacy webapp with the goal of making native mobile apps easier, and so far I’ve been finding it remarkably simple and delightful — In fact implementing a graphql API so that the clients can specify which data they want for themselves has taken less time than all the design dicsussions about what a REST API could potentially look like… (edit: originally I asked how it was a burden, but after refreshing the page I see this was already discussed in another subthread, so I’ll just throw in my anecdote without asking any question :) )

timr 4y ago
It's one those "the first taste is free" kind of things. If you're just doing the transition now, you'll have to take my word that there's more pain coming. It also matters a lot what you mean by "bolting on"...is anyone on the team actually using it? I will freely admit that, depending on the size of the team and the scale of the app, YMMV. For example, if you're the only person working on a legacy app that isn't under high load or lots of regular change, it probably doesn't matter what technology you use. At the extreme other end, the best tech in the world can be an impossible lift for a high-load service with a huge team supporting it. Most of the parasitic complexity, in my experience, comes not from GQL itself, so much as the downstream burdens that come with maintaining the infrastructure needed to service the GQL. Everything being a POST, for example -- hope you don't like cacheing!
- zelphirkalt 4y ago
  Also it matters, what kind of security requirements there are. Is it an API, that everyone can query to their heart's content? Or is there stuff some people may access and others are not allowed to see? Then suddenly there is a whole security layer in the game, that needs to be carefully implemented and tested. Did the thing I implement really protect the data of the API from all possible accesses by unauthorized people?

timr 4y ago

It's one those "the first taste is free" kind of things. If you're just doing the transition now, you'll have to take my word that there's more pain coming. It also matters a lot what you mean by "bolting on"...is anyone on the team actually using it? I will freely admit that, depending on the size of the team and the scale of the app, YMMV. For example, if you're the only person working on a legacy app that isn't under high load or lots of regular change, it probably doesn't matter what technology you use. At the extreme other end, the best tech in the world can be an impossible lift for a high-load service with a huge team supporting it. Most of the parasitic complexity, in my experience, comes not from GQL itself, so much as the downstream burdens that come with maintaining the infrastructure needed to service the GQL. Everything being a POST, for example -- hope you don't like cacheing!

zelphirkalt 4y ago
Also it matters, what kind of security requirements there are. Is it an API, that everyone can query to their heart's content? Or is there stuff some people may access and others are not allowed to see? Then suddenly there is a whole security layer in the game, that needs to be carefully implemented and tested. Did the thing I implement really protect the data of the API from all possible accesses by unauthorized people?