5 ms·

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is

As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and move on to the next thing. I don't want to spend time figuring out your database schema. Or perhaps I've just yet to see single good public GraphQL API. I just recently had look at the Github GraphQL API and it's non-existent docs (no, I don't want introspect your data models at runtime), noped the hell out of that, and got the REST integration for the bit I needed done in an hour.

pandeiro 8y ago
I <3 this comment. How I _wish_ I could nope the hell out of our GraphQL dependency, for the reasons listed and for the frighteningly complex client libs we have to use to consume it, rather than straight up ajax/fetch.
- smt88 8y ago
  How does the complexity bite you? Large files, bad error messages, bugs? Something else?
  - pandeiro 8y ago
    Limited error handling mechanism in Apollo and our backend GraphQL library means I can't use then/catch to reliably handle both network and server errors. Apollo also hijacks state management and somehow decides when to fetch over the network or render a cached response, with no particular logic I can deduce or find documentation for. Then there's the thousand lines of repetitive query code that is a joy to read/write/manage.
    - jupp0r 8y ago
      Sounds like the problem is with your client/server library choices and not with GraphQL as a concept. Your original comment implied the latter.
    - smt88 8y ago
      I think we handle our GraphQL like we do our SQL -- handle the repetitive queries as templates. I'm curious now and will dig into the repo tonight. The state management is a problem by default. We wrote our own cache driver to fix it, which is pretty well documented thankfully. "Un-magic it" is a phrase we use a lot.
- ericcoleman 8y ago
  You don't have to use anything other than `fetch` to consume a graphql API.
  - pandeiro 8y ago
    Right, then you basically lose caching, since the everything's-a-POST requests would go to the wire every time. Not that I haven't considered making that trade-off.
    - invisible 8y ago
      You can use GET if you want (since GraphQL is still just over HTTP). The implementation can largely be up to you (like REST) if you want, but you get loads of things already if you opt into some opinions that libraries have established (e.g. Apollo). See https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/
    - yencabulator 8y ago
      You can make your queries ride over GET very easily, using just fetch.
  - nailer 8y ago
    You shouldn't be using fetch directly accoriding to it's creator anyway - use a high level HTTP client which handles MIME types, query string encoding, etc.
CGamesPlay 8y ago
Why do you think it makes the most sense if “the backend and frontend teams don't like to talk to each other”, given that your biggest complaint seems to be “I don't want to spend time figuring out your database schema“? Aren’t you the frontend guy in this scenario, and not wanting/able to talk to the backend guys (the people who designed the database schema)?
- StavrosK 8y ago
  He (the hypothetical he) doesn't want to talk to them to get them to add the endpoint he needs, so he'd prefer to just get the schema directly and query for whatever.
  - tormeh 8y ago
    Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.
    - RussianCow 8y ago
      Not forever, just as long as you support out-of-date clients (either because of cached JS on the web, or mobile apps that haven't been updated recently). Plus, you generally don't want to introduce backwards-incompatible changes to your schema anyway at a certain scale, unless you can afford to have planned downtime, so GraphQL doesn't add anything new here.
    - alexchamberlain 8y ago
      I disagree; the GraphQL schema should be your point of stability, whereby anything in front or behind can change. That being said, ofc, you'll need to deprecate something at some point and that is fine, it might just take a couple of weeks. See @deprecated decorator examples
      - tomnipotent 8y ago
smt88 8y ago
As a manager/business owner, I like GraphQL because it shifts the burden to the API consumer. That consumer, for us, is a front-end resource who is sometimes less expensive but very often less busy than our backend team. That's obviously not the same formula for every company. I'm just offering it as a potential counterpoint.
- ergothus 8y ago
  This is a common swing point though: PM: Make this change to the site Backend: that would take 2 weeks to make sure it doesn't break anything Frontend: That's a tiny change! I can do it in 2 hours Frontend makes the change. Along with the next several. Overtime, the backend team uses the lessened pressure to overhaul/replace/refactor to decrease the complexity. Meanwhile, Frontend is starting to accumulate a collection of unrelated exceptions to the "normal" flow to meet demands. Eventually.... PM: Make this change to the site Frontend: Um...that would risk all sorts of complications. Consider it a few weeks to make sure it doesn't break anything Backend: That's a straightforward change, I can do it in 2 hours And the pendulum starts to swing in the opposite direction...
- andrewingram 8y ago
  If a frontend employee isn't earning a comparable salary to a backend employee, you're either not hiring people of equivalent skillset, or you're underpaying your frontend people. Where the GraphQL burden lies is largely due to who is considered to be its product owner. This varies significantly depending on whether it's an API for first or third parties.
  - smt88 8y ago
    You don't know enough about my products to be so certain about my payment practices. First of all, our backend is extremely complex and our frontend isn't. Our backend devs need a lot of legal and financial training. Other companies will have an inverse situation. Second, there's a glut of frontend devs (at least when I look for them) because bootcamps seem to produce people who are better at frontend than backend. And third, our frontend devs just don't have as much work to do, so they're idle a lot more often.
sheeshkebab 8y ago
Recently tried out GraphQL in a new web app - and ripped it out all out shortly after from frontend and backend. Unnecessary complexity over simple rest calls with no benefits.
sgrove 8y ago
Interesting! Were you doing a server-to-github integration, or were you using the GraphQL API directly from the frontend?
MattyRad 8y ago
This is my experience as well. We briefly worked with GraphQL for one of our smaller projects. One of the biggest shortcomings of the API we created was that there was an incredibly large learning curve for teams/people not interested in using GraphQL. Instead of using the sensible features of GraphQL queries, the other team consuming our API were writing the most verbose queries they possibly could, not utilizing any of the nice convenience operations that GraphQL offers. They were no doubt frustrated with what they thought was a needless hassle compared to REST, and I myself found a lot of the query building pretty tedious.
- RussianCow 8y ago
  That's interesting, because as a frontend engineer, I find most RESTful APIs to introduce more "needless hassle", mostly in the form of making me send multiple requests to get data multiple levels deep and then consolidating it on the frontend, rather than just sending me what I want to begin with. I agree with query building being tedious, though I'm working on a query builder helper library to make this less painful. Hopefully at some point I can open source it.
  - deleted 8y ago
    [deleted]
deleted 8y ago
[deleted]

pandeiro 8y ago

I <3 this comment. How I _wish_ I could nope the hell out of our GraphQL dependency, for the reasons listed and for the frighteningly complex client libs we have to use to consume it, rather than straight up ajax/fetch.

smt88 8y ago
How does the complexity bite you? Large files, bad error messages, bugs? Something else?
- pandeiro 8y ago
  Limited error handling mechanism in Apollo and our backend GraphQL library means I can't use then/catch to reliably handle both network and server errors. Apollo also hijacks state management and somehow decides when to fetch over the network or render a cached response, with no particular logic I can deduce or find documentation for. Then there's the thousand lines of repetitive query code that is a joy to read/write/manage.
  - jupp0r 8y ago
    Sounds like the problem is with your client/server library choices and not with GraphQL as a concept. Your original comment implied the latter.
  - smt88 8y ago
    I think we handle our GraphQL like we do our SQL -- handle the repetitive queries as templates. I'm curious now and will dig into the repo tonight. The state management is a problem by default. We wrote our own cache driver to fix it, which is pretty well documented thankfully. "Un-magic it" is a phrase we use a lot.
ericcoleman 8y ago
You don't have to use anything other than `fetch` to consume a graphql API.
- pandeiro 8y ago
  Right, then you basically lose caching, since the everything's-a-POST requests would go to the wire every time. Not that I haven't considered making that trade-off.
  - invisible 8y ago
    You can use GET if you want (since GraphQL is still just over HTTP). The implementation can largely be up to you (like REST) if you want, but you get loads of things already if you opt into some opinions that libraries have established (e.g. Apollo). See https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/
  - yencabulator 8y ago
    You can make your queries ride over GET very easily, using just fetch.
- nailer 8y ago
  You shouldn't be using fetch directly accoriding to it's creator anyway - use a high level HTTP client which handles MIME types, query string encoding, etc.

CGamesPlay 8y ago

Why do you think it makes the most sense if “the backend and frontend teams don't like to talk to each other”, given that your biggest complaint seems to be “I don't want to spend time figuring out your database schema“? Aren’t you the frontend guy in this scenario, and not wanting/able to talk to the backend guys (the people who designed the database schema)?

StavrosK 8y ago
He (the hypothetical he) doesn't want to talk to them to get them to add the endpoint he needs, so he'd prefer to just get the schema directly and query for whatever.
- tormeh 8y ago
  Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.
  - RussianCow 8y ago
    Not forever, just as long as you support out-of-date clients (either because of cached JS on the web, or mobile apps that haven't been updated recently). Plus, you generally don't want to introduce backwards-incompatible changes to your schema anyway at a certain scale, unless you can afford to have planned downtime, so GraphQL doesn't add anything new here.
  - alexchamberlain 8y ago
    I disagree; the GraphQL schema should be your point of stability, whereby anything in front or behind can change. That being said, ofc, you'll need to deprecate something at some point and that is fine, it might just take a couple of weeks. See @deprecated decorator examples
    - tomnipotent 8y ago

smt88 8y ago

As a manager/business owner, I like GraphQL because it shifts the burden to the API consumer. That consumer, for us, is a front-end resource who is sometimes less expensive but very often less busy than our backend team. That's obviously not the same formula for every company. I'm just offering it as a potential counterpoint.

ergothus 8y ago
This is a common swing point though: PM: Make this change to the site Backend: that would take 2 weeks to make sure it doesn't break anything Frontend: That's a tiny change! I can do it in 2 hours Frontend makes the change. Along with the next several. Overtime, the backend team uses the lessened pressure to overhaul/replace/refactor to decrease the complexity. Meanwhile, Frontend is starting to accumulate a collection of unrelated exceptions to the "normal" flow to meet demands. Eventually.... PM: Make this change to the site Frontend: Um...that would risk all sorts of complications. Consider it a few weeks to make sure it doesn't break anything Backend: That's a straightforward change, I can do it in 2 hours And the pendulum starts to swing in the opposite direction...
andrewingram 8y ago
If a frontend employee isn't earning a comparable salary to a backend employee, you're either not hiring people of equivalent skillset, or you're underpaying your frontend people. Where the GraphQL burden lies is largely due to who is considered to be its product owner. This varies significantly depending on whether it's an API for first or third parties.
- smt88 8y ago
  You don't know enough about my products to be so certain about my payment practices. First of all, our backend is extremely complex and our frontend isn't. Our backend devs need a lot of legal and financial training. Other companies will have an inverse situation. Second, there's a glut of frontend devs (at least when I look for them) because bootcamps seem to produce people who are better at frontend than backend. And third, our frontend devs just don't have as much work to do, so they're idle a lot more often.

sheeshkebab 8y ago

Recently tried out GraphQL in a new web app - and ripped it out all out shortly after from frontend and backend. Unnecessary complexity over simple rest calls with no benefits.

sgrove 8y ago

Interesting! Were you doing a server-to-github integration, or were you using the GraphQL API directly from the frontend?

MattyRad 8y ago

This is my experience as well. We briefly worked with GraphQL for one of our smaller projects. One of the biggest shortcomings of the API we created was that there was an incredibly large learning curve for teams/people not interested in using GraphQL. Instead of using the sensible features of GraphQL queries, the other team consuming our API were writing the most verbose queries they possibly could, not utilizing any of the nice convenience operations that GraphQL offers. They were no doubt frustrated with what they thought was a needless hassle compared to REST, and I myself found a lot of the query building pretty tedious.

RussianCow 8y ago
That's interesting, because as a frontend engineer, I find most RESTful APIs to introduce more "needless hassle", mostly in the form of making me send multiple requests to get data multiple levels deep and then consolidating it on the frontend, rather than just sending me what I want to begin with. I agree with query building being tedious, though I'm working on a query builder helper library to make this less painful. Hopefully at some point I can open source it.
- deleted 8y ago
  [deleted]

deleted 8y ago

[deleted]