At least with GraphQL I think the world would be better off if it had never seen the light of day. It's a steaming pile of hyper complex dung.

And for the other projects, their paths are littered with the dead bodies of engineers who had been ordered to chase down one of Facebook's hype technologies just because "Facebook does it so we can follow their best example".

It's funny to think of a scientific office tool that doesn't auto-generate macro-type operations for you as needed. Both would be on the dull side, I suppose, for somebody like me, with limited expertise in how to quantify what I guess would do the kind of thing you would most often want done with software with the name GraphQL, making graphs, but it would feel to me, I believe, more like real business work if you were asking for each graph task as needed.

I'm more of an ops person and had the misfortune having to assist an inherited Drupal/static site generator project that heavily used GraphQL. It was not fun to debug this crap, and that is my biggest issue - as if the SSG setup itself isn't already a pain in the ass, adding GraphQL to the build stack was just the icing on the cake.

(One of the issues the dev team faced was the insane amount of RAM that was consumed by the GraphQL crap in both the FE and BE containers, which was a pain to debug for the FE side because that was an ephemeral container on an EKS environment)

IMHO, GraphQL entices developers on both ends to just be lazy and throw the complexity to the other team, and Ops who has to support both teams and mediate between both sides who just blame the other side for being too dumb.

The home-baked solutions it replaced where even worse hyper comlex dung though. Graph databases are a hard problem, so the solutions are never going to be as nice as key-value with an index.

> Graph databases are a hard problem, so the solutions are never going to be as nice as key-value with an index.

The key question is do you even need to use a graph database, and for almost everyone not being a social network or other multibillion user count service, the answer is a clear "no, postgres/mysql (depending on familiarity and pain tolerance) is more than enough".

Unfortunately, many developers and even more architects are following "resume driven development" instead of going for something old and tested...

I think React and GraphQL are pretty impressive in terms of how shitty they've made the developer experience at so many companies. GraphQL especially seems to attract the kind of people who love to misuse technologies built for massive orgs in companies with fewer than 100 employees.

> GraphQL especially seems to attract the kind of people who love to misuse technologies built for massive orgs in companies with fewer than 100 employees.

This is almost exactly how I feel about Kubernetes

I have worked at companies with more kubernetes pods than customers. They loved graphql too.

That explains some of the experiences ive seen at small companies! From my pov it was "design-by-resume." People wanted to play w tech for their next job, with less concern for what the business needed.

This is the classic example of the quote:

There are only two kinds of languages: the ones people complain about and the ones nobody uses

Can we stop pulling this quote out every time someone brings up a legitimate pain point?

There's actually a well-known effect in standards, that large orgs want to overcomplicate them, as having implemented a bunch of overcomplicated standards becomes part of their moat against competitors. This is definitely done deliberately; the most blatant example is Office Open XML but it's true of others too. They know that they have the staff to waste effort on it, and others don't.

I'm not sure anyone is thinking 'lets open source our most dumb ideas to hobble potential competition' - but they would do it if they thought of it.