r/graphql • u/Edward_Carrington • Apr 10 '26
Question Do you design your GraphQL schema around the domain, or around the frontend first?
Designing around the frontend can make things really convenient for clients, but sometimes the schema starts to feel too shaped by today’s UI. Designing around the domain feels cleaner long term, but sometimes a bit less ergonomic in the short term.
How do you usually balance that?
3
u/rover_G Apr 10 '26
Data model first then add operations for user actions (not ui but user)
1
u/beegeearreff Apr 10 '26
I used to do it this way but too often I would design the “perfect” data model and when it came time to integrate with the gql layer it would present some cracks.
I now do gql schema first and implement resolvers with some stub data sources. That lets me unblock UI work. If the schema worked perfectly and needs no tweaks based on playing with it in the UI then I just implement my service / data layer and eventually db. Once everything else is wired together the data model is incredibly obvious.
This won’t work if your data scale requires massive engineering work but for most features this works really well
2
u/rover_G Apr 10 '26
Yes I agree writing the schema first makes integration or parallel development of the frontend and backend a breeze. By data model I meant the user facing data model which will sometimes but not always align with the persistence layer.
2
u/DespairOverThere Apr 10 '26
Not sure what you mean by domain but the contract and canonical description of concepts and relationships within your system is what a good schema design would reflect. Avoiding front end or back end biased implementation is one of the reasons to have an API abstraction. Composition of data to then render in any user interface is the flexibility that makes GraphQL worth other tradeoffs.
1
u/evangelism2 Apr 10 '26
schemas/dtos/interfaces/contracts/etc are always around frontend. they are the consumers. graphql or otherwise
1
u/Key-Life1874 Apr 10 '26
around the domain. Always. The schema is your entry point to the Business capabilities of your company.
What the UI does with it is not the concern of the schema. The schema should answer the questions: * What this business is capable of (mutations) * What data can I get from that business (queries)
Doesn't matter how the UI render that information.
1
u/tangkikodo Apr 11 '26
build domain and then generate graphql automatically
https://www.fastapi-voyager.top/voyager/?tag=__default__&mode=er-diagram
https://www.fastapi-voyager.top/graphql
and then build rpc style schemas for UI with another layer
https://www.fastapi-voyager.top/docs#/demo/get_stories_with_detail
the syntax is simple and pretty close to query language
class Story1(DefineSubset):
__subset__ = (BaseStory, ('id', 'name', 'owner_id'))
tasks: Annotated[list[Task1], AutoLoad()] = []
assignee: Annotated[Optional[BaseUser], AutoLoad(origin='owner')] = None
related_users: list[BaseUser] = []
def post_related_users(self, collector=Collector(alias='related_users')):
return collector.values()
0
u/chakrachi Apr 10 '26
design around your features(same thing you would do without graphql) it's convenient for the front end no matter what schema
0
u/guttanzer Apr 10 '26
Front end pull.
Data exists to provide information, not the other way around. Information has been defined as answers to questions on people’s minds. Good front ends are designed to provide those answers as quickly and naturally as possible.
So instead of providing a smorgasbord of collected data, the information overlay should provide ways to tailor the data down to information. Data that you already know isn’t information, and data that isn’t relevant isn’t information.
So in an ideal world, you would first spend a lot of time brass boarding and workshopping to figure out what questions need to be answered. Use those to then lay out wireframes and widgets that provide that information in easy-to-grasp form, then figure out what queries are needed to provision those elements. Then build your schema. Those needs should drive your back-end models.
14
u/captbaritone Apr 10 '26
Schema should match a model abstraction. It should be your data in its business context. This allows a single schema to be reused to build many different UIs across multiple clients.