Read this article recently while doing additional research on the points brought up by other articles such as "Don’t Build A General Purpose API To Power Your Own Front End"[0] and "Splitting Your Data & Application APIs: Going Further"[1], and found it to be very insightful.
Isn't the point of GraphQL to allow each client to select what they want? On desktop, you want fields A B C, on mobile you want fields X Y Z-- great! It goes against the "don't build a general-purpose API" thought, but it works great in unlocking the front-end teams from having to request a change from the backend team. But that's assuming you have separate front-end and back-end teams. The most useful architecture might be contextual to your organization's size and structure.
> The most useful architecture might be contextual to your organization's size and structure.
I think this is a huge part of it, the other part is what is the scope of the app? Is it just a crud app that needs to integrate with some billing and auth services, or are you building a true web application with multiple front ends?
[0] https://max.engineer/server-informed-ui [1] https://htmx.org/essays/splitting-your-apis/