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.

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.

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)?

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.

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.

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

> the GraphQL schema should be your point of stability, whereby anything in front or behind can change

This is the bit of abstraction I see most developers fail to understand when evaluating GraphQL.

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.

I'm not quite sure what does the database schemas have to do with the front-end queries...

In this case OP is talking about the GraphQL schemas, not the DB.

I'm not sure which OP do you mean? The parent mentions "SQL experience", the grandparent is ambiguous, and the GGP explicitly mentions "database schema".

If by OP you mean the original article, I completely agree with you; my comment was directed to its ancestors.

The internal team would have a vested interest in introspecting the API but an end user (developer) would not.

But I actually found their graphql docs to be sensible? Not sure where the introspection comes into play

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.

You don't have to use anything other than `fetch` to consume a graphql API.

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.

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/

You can make your queries ride over GET very easily, using just fetch.

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.

How does the complexity bite you? Large files, bad error messages, bugs? Something else?

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.

Sounds like the problem is with your client/server library choices and not with GraphQL as a concept. Your original comment implied the latter.

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.

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.

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.

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...

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.

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.

So you’re not hiring people of equivalent skillset, that’s fair enough.

I just found it a surprising comment in isolation because most people I’ve met who’ve developed both frontend and backend skills to a senior or greater level, would argue that frontend is the more challenging of the two.

The bit about idle time is a bit confusing though, can’t you just have fewer devs if there’s not enough work to go around? Or do you always need a lot of spare resources due to unpredictable workloads?

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