[mschuster91]

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

[cobradefinitive]

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.

[jeswin]

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

Of course not. GraphQL has vastly simplified our backend development, and has also resulted in better coordination between backend and frontend teams. There are so many things which GraphQL gets right - TYPES and schemas, traversing entity relationships, selectively querying fields, builtin API explorer etc. We use REST only for super trivial projects.

[mschuster91]

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.

[wisty]

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.

[mschuster91]

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