3 ms·

GraphQL, from what I see, is a solution designed by tech that is still best meant for big tech. Facebook had their reasons for coming up with it, because their

by ljm 6y ago

GraphQL, from what I see, is a solution designed by tech that is still best meant for big tech. Facebook had their reasons for coming up with it, because their user base is hitting the billions in scale. "But my mobile app makes too many requests!" says the hopeful engineer, "and graphql means we can optimise the network!" Well, yeah, it probably looks like that when you see one nice request from the browser dev-tools, rather than dozens, but that's not what it will look like on the server side, or in the database, when you can get into situations with quadratic queries, never mind N+1. And yes, I've seen that with my own eyes. If you're sending a dozen or so requests to the server to render a screen in a mobile app, then the slowest thing might just be the stage where you spin up a connection and do the old TLS dance. Unless you're hitting Big Tech scale that's probably acceptable versus the insane amount of money you'll dump into building and maintaining a GraphQL-based architecture without any data proving that this approach would actually be an optimisation. Just like Kafka, Kubernetes, etc. which have come out of incredibly large-scale projects and businesses...you don't have to and shouldn't use this stuff just because it's the popular thing to do. Startups and small businesses became successful without any of this.

Skgqie1 6y ago
The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. Most places seem to just pick something because they heard it's used by Facebook or Google, and they think cargo culting those companies might make them successful too. Usually, any disagreement is seen as either contrarian or ignorant, and you end up building an over engineered monstrosity because that's what they want.
- rodgerd 6y ago
  > The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. As someone who is nominally a decision maker (in that my job title has "architect" in it), I have the opposite experience, I guess: most of the pushes for GraphQL have come from devs desperate to have a magic bullet, rather than to rework an overly-granular API. (Of course there are also the folks who want a tick on their CV but that's a whole other problem)
ForHackernews 6y ago
I sort of disagree. The big win from GraphQL (vs REST) is flexibility: You don't have to define all your endpoints up front. The client(s) can make the sorts of queries they want. If you're building a single page app frontend where most of the business logic is on the client side, it makes sense to empower the client to define the types of queries it wants to make. If anything, running a GraphQL architecture seems like less maintenance burden to me, because it makes the server side API less rigid, so the coupling between client and server becomes looser.
- ljm 6y ago
  And how often do you need that sort of decoupling at all? Beside that, I disagree in principle because, like the OP said, it's just hiding the maintenance burden elsewhere. It doesn't go away.
  - zionic 6y ago
    The problem is the server has a connection to the database that’s infinitely more reliable than the client -> server. I’ve dealt with garbage REST APIs with tons of sequential calls and in low reliability scenarios 1 call is a massive improvement over a scenario where 4-5 sequential calls need to be made and if/when one of them fails you need to start over. Now the client has to handle result caching and all the different error states because some server dev couldn't be bothered to batch a few calls and return all the required models.
  - ForHackernews 6y ago
    At my company, we benefit from loose coupling between components every time we'd like to release an update to one without a concomitant deploy to some other service.
- vlunkr 6y ago
  If you control the back and front end, I don't buy into this argument. You don't have to define all your REST endpoints up front, you can add them as needed. If you're serving a public API and you really don't know up front what endpoints people will need, or like facebook you have tons of people with different needs, then maybe GraphQL makes sense.

by ljm 6y ago

Skgqie1 6y ago

The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. Most places seem to just pick something because they heard it's used by Facebook or Google, and they think cargo culting those companies might make them successful too. Usually, any disagreement is seen as either contrarian or ignorant, and you end up building an over engineered monstrosity because that's what they want.

rodgerd 6y ago
> The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. As someone who is nominally a decision maker (in that my job title has "architect" in it), I have the opposite experience, I guess: most of the pushes for GraphQL have come from devs desperate to have a magic bullet, rather than to rework an overly-granular API. (Of course there are also the folks who want a tick on their CV but that's a whole other problem)

ForHackernews 6y ago

I sort of disagree. The big win from GraphQL (vs REST) is flexibility: You don't have to define all your endpoints up front. The client(s) can make the sorts of queries they want. If you're building a single page app frontend where most of the business logic is on the client side, it makes sense to empower the client to define the types of queries it wants to make. If anything, running a GraphQL architecture seems like less maintenance burden to me, because it makes the server side API less rigid, so the coupling between client and server becomes looser.

ljm 6y ago
And how often do you need that sort of decoupling at all? Beside that, I disagree in principle because, like the OP said, it's just hiding the maintenance burden elsewhere. It doesn't go away.
- zionic 6y ago
  The problem is the server has a connection to the database that’s infinitely more reliable than the client -> server. I’ve dealt with garbage REST APIs with tons of sequential calls and in low reliability scenarios 1 call is a massive improvement over a scenario where 4-5 sequential calls need to be made and if/when one of them fails you need to start over. Now the client has to handle result caching and all the different error states because some server dev couldn't be bothered to batch a few calls and return all the required models.
- ForHackernews 6y ago
  At my company, we benefit from loose coupling between components every time we'd like to release an update to one without a concomitant deploy to some other service.
vlunkr 6y ago
If you control the back and front end, I don't buy into this argument. You don't have to define all your REST endpoints up front, you can add them as needed. If you're serving a public API and you really don't know up front what endpoints people will need, or like facebook you have tons of people with different needs, then maybe GraphQL makes sense.