[015a]

If the primary selling point of the new technology is something like GraphQL's "if your API doesn't have a good single route to get the data for this page, GraphQL can synthesize it"; frontend just doesn't, in general, iterate at a speed that is such orders-of-magnitude higher than how quickly a new API view can be built, such that a new structurally-different communications layer is necessary.

Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only. It turns out, the problems GraphQL creates in a system are backend problems; there's some really freakin hairy edges in the domains of authorization, caching, rate limiting/complexity limiting, even just basic type safety, that can only charitably be described as "solved" if you consider "some ideas in a twenty page blog post" as a solution.

We also had constant problems educating our customers about GraphQL. "No no, you can use any REST client you want, here let me show you how to set it up" (two hour education session later).

There really isn't a perfect solution to the problem space. If your view is complex enough, synthesizing it JIT in GraphQL is just the frontend saying "its your problem now" to the backend, and whether the solution to that is "fixing performance bottlenecks" or "a new RESTful-ish view API for this screen" for the backend team, its still a ticket. If the view is less complex than that: making multiple requests isn't the end of the world. After all, those two highly predictable, optimized, even cached requests may end up being faster than one dynamic and extremely-difficult-to-cache GraphQL request.

At the end of the day, I think there's a reason why REST has lasted as long as it has, and why it still feels state of the art to me. Moving more API capabilities to edge platforms, including edge databases, shortens that string of beads quite substantially. Server-side rendering is back is in full force. There's other angles this problem is being attacked from.

[dabber]

> Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only.

The Guild [0] does some exceptional work in the GQL world and specifically server side with Yoga, Envelope, Hive, and some other stuff; but it does tend to be JS focused for now.

https://the-guild.dev/

[bryanrasmussen]

>Additionally; GraphQL never got the community love it needed on the backend side to make things hum.

Ok, well for some reason every project I've been on in the past 4-5 years has used GraphQL? What makes me so special?

As I conclude that I am not special I have to go back to what my previous position was that GraphQL is pretty much the standard way front-enders query nowadays.

That said - the project I am on right now only uses GraphQL for querying CommerceTools, and their GraphQL implementation seems like someone told a dev hey, we need GraphQL, make our SQL backend available over that, and he completed his ticket anywhere from 4 hours to 4 days, but certainly not in any amount of time to make a solution that had any of the advantages of GraphQL in it.

We used to have GraphQL for the part of the project using Contentful - but their GraphQL was so problematic we moved to their Rest API (I say was because that move was over 1 year ago, it would be wrong to say it is bad now - who knows what improvements they might have had)

[015a]

If I insinuated that GraphQL is dead, that wasn't my intention. It definitely has fallen out of the spotlight, however. I'd point to e.g. looking at statistically how many APIs ran by major internet companies are available over GraphQL versus more traditional REST or RPC. Github is the only one that springs to mind, and its available in addition to a REST API.

Even Meta has a "Graph API" that is not GraphQL (https://developers.facebook.com/docs/graph-api/overview) (they may have an odd GraphQL API here and there; I am not deeply familiar with the entirety of their offering, and I don't want to insinuate such; just that they don't seem to rave about it front and center if they do, and instead invented a second, separate thing).

I interact with a GraphQL API among much smaller integration partners maybe once or twice a year; versus dozens of REST APIs. They're definitely around, people definitely still use it (my company has one!), but arguing that its the standard way frontend APIs are written feels very detached from reality; and maybe you really are special.

[roughly]

> As I conclude that I am not special

Aww, don’t sell yourself short!

[rahkiin]

I have found Hot Chocolate to be an amazing library (together with other tools from ChilliCream) for building GraphQL APIs in dotnet/c#.