Yes. Where it can be logged, inspected and dealt with wholesale.
It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods.
> Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven.
Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.
Just as it could be in the backend? I don't follow that point.
> apps that evolve through their development usually have most changes UI driven.
That's a fair point certainly, but isn't completely generalisable - if you offer a third-party API at all (or think you might) then maybe don't special-case your own frontend.
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. 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.
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.
This suggests that GraphQL adoption is a sign of impending business stagnation. This does in fact align with my experience around GraphQL.
On braindead busywork, yes. Please automate everything about it as soon as possible, including communication.
> 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.
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.
Lucky you. In corporate environments I worked at it took easily half of the 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.
Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven.
(Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)