4 ms·

Does this actually pass as an academic study? It is presented in the format of a study (it looks like one) but to suggest GraphQL is better than REST based on

Does this actually pass as an academic study? It is presented in the format of a study (it looks like one) but to suggest GraphQL is better than REST based on the expenditure of effort for building out the first iteration of code for cherry picked scenarios is a first-year undergraduate CS101 study at best. Also, who funded this study? I want to know the actual costs of GraphQL. What are the tradeoffs with REST? What are the limitations? We're not going to hear from managers who are damage controlling their decisions, but maybe the developers paying for GraphQL adoption wouldn't mind sharing grievances? Now that money and reputations are at stake, I think that unfortunately it will be a while before the tech community starts admitting to mistakes, just as was done with adopting ORMs. The typical pitch about GraphQL is that it is intended to alleviate the pain of updating ORM dsl every time a change to an endpoint needs to be made to satisfy frontend requirements. Aren't updates to the GraphQL DSL replacing those made to the ORM? The problem hasn't been eliminated but replaced. One problem was replaced by another problem. If the worst part about working with a REST api with raw sql calls is that you have to make a few straightforward changes, while maintaining complete control of your sql, you're doing great.

akra 6y ago
For me this is the point that I feel isn't well argued against by GraphQL proponents. Why if I'm a Javascript developer with probably a similar learning curve I couldn't just whip up a simple stateless frontend (in Node since its the same lang) and write the query in SQL? More to the point the skills learnt by doing so are more transferable. You also give your data store a chance to be more performant (e.g. better query plans for a typical DB) using that DSL to query the data store and there's a lot less complexity (components, libraries) in your solution. Also from what I've seen the approaches that may result in single ideal query plans in your database increase the complexity of GraphQL significantly with "GraphQL to SQL" compilers which still may not give tuned SQL especially with large graphs. Reminds me of using ORM's where often the generated SQL wasn't performant/slow. Even if it does work the complexity of your solution just increased - all for what? To translate one query language into another? There's also times where it may pay NOT to expose too much of your internal domain structure to public API's which I feel from a naive developer's perspective GraphQL could encourage (direct internal API structure to contract mappings). It feels, at least to me, that it is another abstraction layer that solves a problem that could also be solved at the org level. If there's suddenly a use case that requires a tuned query/algorithm/index as well (happens a lot from my experience) then its easy to add as a separate endpoint and test for regression test against other endpoints/use cases supported.
PeterisP 6y ago
> Does this actually pass as an academic study? Well, it was published/presented at Working IEEE/IFIP Conference on Software Architecture - https://ieeexplore.ieee.org/abstract/document/9101226 https://ieeexplore.ieee.org/abstract/document/9101226 - though I have no idea on how respectable that conference is.

akra 6y ago

For me this is the point that I feel isn't well argued against by GraphQL proponents. Why if I'm a Javascript developer with probably a similar learning curve I couldn't just whip up a simple stateless frontend (in Node since its the same lang) and write the query in SQL? More to the point the skills learnt by doing so are more transferable. You also give your data store a chance to be more performant (e.g. better query plans for a typical DB) using that DSL to query the data store and there's a lot less complexity (components, libraries) in your solution. Also from what I've seen the approaches that may result in single ideal query plans in your database increase the complexity of GraphQL significantly with "GraphQL to SQL" compilers which still may not give tuned SQL especially with large graphs. Reminds me of using ORM's where often the generated SQL wasn't performant/slow. Even if it does work the complexity of your solution just increased - all for what? To translate one query language into another? There's also times where it may pay NOT to expose too much of your internal domain structure to public API's which I feel from a naive developer's perspective GraphQL could encourage (direct internal API structure to contract mappings). It feels, at least to me, that it is another abstraction layer that solves a problem that could also be solved at the org level. If there's suddenly a use case that requires a tuned query/algorithm/index as well (happens a lot from my experience) then its easy to add as a separate endpoint and test for regression test against other endpoints/use cases supported.

PeterisP 6y ago

> Does this actually pass as an academic study? Well, it was published/presented at Working IEEE/IFIP Conference on Software Architecture - https://ieeexplore.ieee.org/abstract/document/9101226 https://ieeexplore.ieee.org/abstract/document/9101226 - though I have no idea on how respectable that conference is.