3 ms·

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 every

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

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.