Pattern: Back Ends for Front Ends

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.

[0] https://max.engineer/server-informed-ui [1] https://htmx.org/essays/splitting-your-apis/

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.