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