5 ms·

I worked with GraphQL a bit over a year and half ago on a project. I was the front end consumer, working with backend microservices via graphQL. I wasn't sold

I worked with GraphQL a bit over a year and half ago on a project. I was the front end consumer, working with backend microservices via graphQL. I wasn't sold on the GraphQL hype then, and I'm still not, but this article seems to miss the point. [Edit: I mean, it agrees, but it does so poorly] A lot of people TALK about the lack of multiple back-and-forth, and about not wasting unnecessary data, but honestly, that wasn't a big deal. I expect there are some situations where that comes into play, but for most people the appeal of GraphQL lies elsewhere. If HTTP/2 means that's less of a big deal, I don't expect much change. The legit upside to GraphQL was that backend could change rapidly without breaking compatibility for existing consumers. Some changes could be fixed purely frontend by changing the query, but if we needed new data that wasn't provided (or a variation on data that was provided) the backend could add that AND NOT IMPACT EXISTING CONSUMERS. That's not the only benefit (and remember, I remain a skeptic) but that was by far the biggest and was definitely real. Even if the claims of HTTP/2 rendering the call overhead are correct (see other comments to doubt that), that has no impact on this value of GraphQL.

MuffinFlavored 7y ago
> I wasn't sold on the GraphQL hype then, and I'm still not, Why not?
- ergothus 7y ago
  Foremost, I'm not comfortable with abandoning the meaning of HTTP methods. Changing everything to POST means pushing all sorts of caching decisions to the start-and-end points and bypassing decades of work done on improving GET caching for intermediate layers. (Caveat: this is where people start talking about how GraphQL doesn't _require_ POST. I fully allow I don't know enough to be sure, but on the face it seems problematic). Secondly, it may just be something solved as the tech becomes more mature and practiced, but there are numerous smaller issues such as versioning (the ability to change rapidly without breaking backward compatibility is separate from when you DO want to break that compatibility) and tooling. These are hardly solved issues with, say REST, but they are "more solved". Most places have some level of versioning, and requests are trivial to read with existing tooling. When doing an involved front end app (I was in ag tech working on app that was tying data models with farm field overlay maps and setting values by geographic region - which sounds way more impressive than it really is) I found that GraphQL seemed great for straightforward CRUD apps, where the results of a query and the display of the page mapped closely, but the value add on the front end was pretty minimal for more complex applications. Lots of tooling (Apollo at the time, and I hear "Relay" being discussed today) performs magic to make this all effortless. "magic" is great when it works - we adopt it and stop considering it magic. The other times it is usually a flash in the pan that spawns lots of regrets. I'd be an idiot to claim I knew which side of magic this falls on, but my experience is currently saying to avoid anything too involved. A GraphQL API? Sure, it's not my first pick but I'll use it. A framework that magically hides all the complexity on the front end? I'm willing to bet I'll run afoul of some hidden boundary. If I'm at a company that starts talking GraphQL I'd ask about the solutions for caching and versioning. If they have answers, I'll keep listening. If they wave it off as something to worry about later, I'd expect headaches. A long, rambling, and subjective answer, but that's my answer.
  - TurningCanadian 7y ago
    https://www.apollographql.com/docs/ios/fetching-queries/#using-get-instead-of-post-for-queries https://www.apollographql.com/docs/ios/fetching-queries/#usi... I use this in prod, and the only downside I'm aware of is the length limit on the query string. (Haven't hit it though) https://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request https://stackoverflow.com/questions/2659952/maximum-length-o...

MuffinFlavored 7y ago

> I wasn't sold on the GraphQL hype then, and I'm still not, Why not?

ergothus 7y ago
Foremost, I'm not comfortable with abandoning the meaning of HTTP methods. Changing everything to POST means pushing all sorts of caching decisions to the start-and-end points and bypassing decades of work done on improving GET caching for intermediate layers. (Caveat: this is where people start talking about how GraphQL doesn't _require_ POST. I fully allow I don't know enough to be sure, but on the face it seems problematic). Secondly, it may just be something solved as the tech becomes more mature and practiced, but there are numerous smaller issues such as versioning (the ability to change rapidly without breaking backward compatibility is separate from when you DO want to break that compatibility) and tooling. These are hardly solved issues with, say REST, but they are "more solved". Most places have some level of versioning, and requests are trivial to read with existing tooling. When doing an involved front end app (I was in ag tech working on app that was tying data models with farm field overlay maps and setting values by geographic region - which sounds way more impressive than it really is) I found that GraphQL seemed great for straightforward CRUD apps, where the results of a query and the display of the page mapped closely, but the value add on the front end was pretty minimal for more complex applications. Lots of tooling (Apollo at the time, and I hear "Relay" being discussed today) performs magic to make this all effortless. "magic" is great when it works - we adopt it and stop considering it magic. The other times it is usually a flash in the pan that spawns lots of regrets. I'd be an idiot to claim I knew which side of magic this falls on, but my experience is currently saying to avoid anything too involved. A GraphQL API? Sure, it's not my first pick but I'll use it. A framework that magically hides all the complexity on the front end? I'm willing to bet I'll run afoul of some hidden boundary. If I'm at a company that starts talking GraphQL I'd ask about the solutions for caching and versioning. If they have answers, I'll keep listening. If they wave it off as something to worry about later, I'd expect headaches. A long, rambling, and subjective answer, but that's my answer.
- TurningCanadian 7y ago
  https://www.apollographql.com/docs/ios/fetching-queries/#using-get-instead-of-post-for-queries https://www.apollographql.com/docs/ios/fetching-queries/#usi... I use this in prod, and the only downside I'm aware of is the length limit on the query string. (Haven't hit it though) https://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request https://stackoverflow.com/questions/2659952/maximum-length-o...