2 ms·

To dig in on the persisted queries thing, which I mentioned in a reply to the sibling comment, have you seen practical advantages doing this vs just doing a pla

To dig in on the persisted queries thing, which I mentioned in a reply to the sibling comment, have you seen practical advantages doing this vs just doing a plain old RPC style http API? It seems to just move all the flexibility of GraphQL to dev time, and makes it only useful for a private API where you control both the client and the server. This is all fine, but then I just don't see why you'd move away from a classic API where caching is free for GETs and you don't have to go through the abstraction of GraphQL schemas and resolvers etc to do your endpoint logic, you can just do it. One thing I could possibly see is that client side libraries like Apollo etc bring huge advantages like free client caching or other things I'm not aware of - is that the case?

strken 7y ago
At the company which used GraphQL in production, two of the major reasons for adoption were decoupling the backend from the UI of the client, and allowing front-end developers to easily update the payload without making changes to the server, which weren't affected by using persisted queries. Caching was handled by separate backend services rather than the graphql service or the client, which wouldn't make sense for every usecase. Apollo was really useful for managing state across the client. Tools like optimistic updates were very nice too. Unfortunately, it was somewhat buggy when we were using it, and the API kept changing, but I think it's more stable now. It was also good to have a well-defined schema between client and backend, although you should have one anyway.
- davnicwil 7y ago
  Yeah, that makes sense. I think the usecase I'm optimising for is solo and/or full stack engineers in a relatively small team where everyone is free to do everything. When that's the case, obviously these kinds of abstractions may just get in the way rather than help. I've worked for companies in the past that had the organisational setup you describe, however, where frontend engineers didn't even have pull access to the code for api services they were talking to, where this would have been a massive advantage in terms of productivity. I seem to end up at this conclusion in most discussions about GraphQL, usually with facebook scale being referenced, where it seems that as a technology its main advantages might actually be architectural in terms of the organisation of how massive systems are engineered, by huge numbers of people. The temptation is always to jump in and compare the technical merits and specifics, and overlook this, but I'm coming more to the opinion that this is the answer here to when to use GraphQL over REST / RPC over http. That is, at the scale of a massive engineering organisation, it might be an abstraction whose advantages outweigh the downsides, but probably not if you're a small team.
  - strken 7y ago
    It's less about what front-end engineers are allowed to do, and more about having an abstraction flexible enough that new front-end features don't need changes on the backend unless the data model changes. Backend or full stack engineers can design endpoints however they want, whether it's RESTful JSON or gRPC, and GraphQL acts as a flexible aggregation and presentation layer. If you're finding that your endpoints are filled with unnecessary optional fields, that they're specific to a single screen in the UI, that nearly every new feature involves work that's duplicated across front-end and backend, or that you're suffering a performance hit from the round-trip time between front-end and backend when you query nested objects, then GraphQL can be an option. These are problems that you run into when your product starts to get bigger and more unwieldy, so if your UI has five screens and doesn't reuse the same content then you might not see a lot of gain. Having said that, my former company was under ten engineers, so I don't think you need to be Facebook-scale to benefit. Totally agree that the advantage is architectural. It's not a question of technical merits or of REST being bad. GraphQL is a layer of abstraction to separate data from presentation, and like other abstractions, you shouldn't use it unless you have a reason to.

strken 7y ago

At the company which used GraphQL in production, two of the major reasons for adoption were decoupling the backend from the UI of the client, and allowing front-end developers to easily update the payload without making changes to the server, which weren't affected by using persisted queries. Caching was handled by separate backend services rather than the graphql service or the client, which wouldn't make sense for every usecase. Apollo was really useful for managing state across the client. Tools like optimistic updates were very nice too. Unfortunately, it was somewhat buggy when we were using it, and the API kept changing, but I think it's more stable now. It was also good to have a well-defined schema between client and backend, although you should have one anyway.

davnicwil 7y ago
Yeah, that makes sense. I think the usecase I'm optimising for is solo and/or full stack engineers in a relatively small team where everyone is free to do everything. When that's the case, obviously these kinds of abstractions may just get in the way rather than help. I've worked for companies in the past that had the organisational setup you describe, however, where frontend engineers didn't even have pull access to the code for api services they were talking to, where this would have been a massive advantage in terms of productivity. I seem to end up at this conclusion in most discussions about GraphQL, usually with facebook scale being referenced, where it seems that as a technology its main advantages might actually be architectural in terms of the organisation of how massive systems are engineered, by huge numbers of people. The temptation is always to jump in and compare the technical merits and specifics, and overlook this, but I'm coming more to the opinion that this is the answer here to when to use GraphQL over REST / RPC over http. That is, at the scale of a massive engineering organisation, it might be an abstraction whose advantages outweigh the downsides, but probably not if you're a small team.
- strken 7y ago
  It's less about what front-end engineers are allowed to do, and more about having an abstraction flexible enough that new front-end features don't need changes on the backend unless the data model changes. Backend or full stack engineers can design endpoints however they want, whether it's RESTful JSON or gRPC, and GraphQL acts as a flexible aggregation and presentation layer. If you're finding that your endpoints are filled with unnecessary optional fields, that they're specific to a single screen in the UI, that nearly every new feature involves work that's duplicated across front-end and backend, or that you're suffering a performance hit from the round-trip time between front-end and backend when you query nested objects, then GraphQL can be an option. These are problems that you run into when your product starts to get bigger and more unwieldy, so if your UI has five screens and doesn't reuse the same content then you might not see a lot of gain. Having said that, my former company was under ten engineers, so I don't think you need to be Facebook-scale to benefit. Totally agree that the advantage is architectural. It's not a question of technical merits or of REST being bad. GraphQL is a layer of abstraction to separate data from presentation, and like other abstractions, you shouldn't use it unless you have a reason to.