5 ms·

GraphQL is actually pushing all the complexity to the server; to make a joke using the words in the article, it reduces the frontend coding time to 4 hours whil

GraphQL is actually pushing all the complexity to the server; to make a joke using the words in the article, it reduces the frontend coding time to 4 hours while making backend to take 32 hours. Actually, I also tried to move to GraphQL and still haven't a good fit yet. GraphQL queries are hard to translate to efficient SQL, and there are additional problems to tackle like authorization which is much complicated than the REST model.

vinsuper 8y ago
The way we are doing this is, we have a proxy layer that exposes REST APIs, the proxy translates the REST requests to GraphQL requests; For the ones which are challenging, like authentication for instance, we are just forwarding the request to the main server.
ordinaryperson 8y ago
I see GraphQL queries at work and some of them are almost 100 lines long because we're asking for/receiving almost all of the available data fields. So what would be a 1 line request in REST format is now 100x longer and complex and why? It's an internal service so we weren't worried about reducing bandwidth costs (the problem FB was presumably trying to solve). I assume it was adopted because it's sexy and/or the developer wanted an excuse to use it. I also wonder about the performance benefits if your data is in a SQL db...if you're running a no-SQL db then you can specify only the fields you want but I'm guessing a SQL db is likely to lock and read the entire row/record, even if it's only returning a subset of values. If you're building a big, public-facing API or if people will only want a small subset of available data fields exposed by the API, GraphQL makes sense, but I feel like devs are swapping out easier-to-implement and use REST APIs just because GraphQL sounds cool.
- arisb 8y ago
  If you are only reading from a table I don't think any relational database implementing MVCC would lock anything.
timwis 8y ago
Same here. Very complex to implement, or you decide to use libraries that provide tremendous abstraction. And you still have to worry about query optimisation and n+1 problem. Not to mention if certain users can see certain fields!
oliwarner 8y ago
Yup. Complexity. You may spend more time writing REST endpoints, but they're very simple to profile and target for optimisation. In situations where you're consuming the API you're writing, just iterating on a REST API is so much faster.

vinsuper 8y ago

The way we are doing this is, we have a proxy layer that exposes REST APIs, the proxy translates the REST requests to GraphQL requests; For the ones which are challenging, like authentication for instance, we are just forwarding the request to the main server.

ordinaryperson 8y ago

I see GraphQL queries at work and some of them are almost 100 lines long because we're asking for/receiving almost all of the available data fields. So what would be a 1 line request in REST format is now 100x longer and complex and why? It's an internal service so we weren't worried about reducing bandwidth costs (the problem FB was presumably trying to solve). I assume it was adopted because it's sexy and/or the developer wanted an excuse to use it. I also wonder about the performance benefits if your data is in a SQL db...if you're running a no-SQL db then you can specify only the fields you want but I'm guessing a SQL db is likely to lock and read the entire row/record, even if it's only returning a subset of values. If you're building a big, public-facing API or if people will only want a small subset of available data fields exposed by the API, GraphQL makes sense, but I feel like devs are swapping out easier-to-implement and use REST APIs just because GraphQL sounds cool.

arisb 8y ago
If you are only reading from a table I don't think any relational database implementing MVCC would lock anything.

timwis 8y ago

Same here. Very complex to implement, or you decide to use libraries that provide tremendous abstraction. And you still have to worry about query optimisation and n+1 problem. Not to mention if certain users can see certain fields!

oliwarner 8y ago

Yup. Complexity. You may spend more time writing REST endpoints, but they're very simple to profile and target for optimisation. In situations where you're consuming the API you're writing, just iterating on a REST API is so much faster.