> Just as it could be in the backend? I don't follow that point.

GraphQL server is the part of the backend.

The problem is that client has a new requirement, it is verbally communicated through UI change request. Frontend team implements the change then has to make a verbal request to the backend team for new data to be exposed. There's a bit of back and forth, testing. Everybody waits for everybody. It all takes time and is most of the time brainless busywork. GraphQL makes it so that request to the backend team doesn't need to be verbal (jira is same as verbal for me). It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development. The cost of that streamlining is that at some point security or performance issues might arise, but those then can be dealt with solely by the backend and db team, as they should be because frontend is always insecure.

> if you offer a third-party API at all

For one such app 99 have both server and the client developed in sync.

And even then with offering third party api I think it's way easier to fall into the trap of special-casing your frontend with poorly designed REST than with GraphQL, althought there might be performance and security challenges as there always are with anything public. So there might be a bit to learn about how to deal with that in GraphQL ecosystem.

> It can be mediated through software and even fulfilled automatically if the GraphQL server is open enough during development.

You pretend that GraphQL is magic.

If there's requirement not exposed by the GraphQL server, the way to add it is literally exactly the same as for any other backend API.

Sure. But it's magic enough for me if I don't have to create a ticket for adding existing database field to a DTO every single time.

> But it's magic enough for me if I don't have to create a ticket for adding existing database field to a DTO every single time.

It means that those fields are already exposed to you by backend. Had they not been, no amount of magic on your side would make them appear.

So you've reached a point where working together collaboratively is such a burden that you've adopted technologies to circumvent that activity.

This suggests that GraphQL adoption is a sign of impending business stagnation. This does in fact align with my experience around GraphQL.

> So you've reached a point where working together collaboratively is such a burden that you've adopted technologies to circumvent that activity.

On braindead busywork, yes. Please automate everything about it as soon as possible, including communication. I don't want to collaborate on it with a human the same way I don't want to collaborate with a human on my McDonald's order and I prefer to access their ordering software through a kiosk or a phone.

> This suggests that GraphQL adoption is a sign of impending business stagnation. This does in fact align with my experience around GraphQL.

That very well might be. But stagnation understood as predictably churning an app after an app.

In my experience, braindead busywork is largely non-existent. Yes, there are times when you'll have to do something easy that conforms to code requirements and standards. But when the frontend needs to update something that is coming from a server, there is a real opportunity to discover, illuminate, and even solve architectural issues.

Sometimes that solution is to use GraphQL to make it easier to manage client implementation fan-out and requirement diversity. But GraphQL is never a substitute for communication and collaboration.

> In my experience, braindead busywork is largely non-existent.

Lucky you. In corporate environments I worked at it took easily half of the time.