WORK STORY / 02
Let GraphQL and REST share the same data model and UI
Context
At the time, I was working with two frontend projects that had originally been unrelated.
One was an application that used GraphQL as its primary data source; the other was a BPM approval system using REST APIs.
The BPM system originally handled relatively simple data until a new requirement appeared:
BPM had to import the complete, complex data from the GraphQL system and present it through the same UI.
At that point, the problem was no longer simply whether a component could be moved.
The GraphQL project’s data types came from code generation. If both projects maintained their own types, one data model would have two versions; but forcing the REST project to adopt the entire GraphQL code-generation stack for a small subset of data would create an equally unnatural technical boundary.
My Decision & Action
I did not want whether data arrived through GraphQL or REST to determine how the UI and domain model were designed.
I therefore moved the GraphQL project into an Nx monorepo and separated:
- GraphQL operations and resolvers known only by the application
- Data types shareable across projects
- UI components that depend on those data models
- Data-processing logic such as parsers and formatters
Core data types generated by GraphQL Codegen were centralized in libs/core, while the same library also managed the UI and data-processing capabilities bound to those models.
The REST project only needed to consume this shared library; using the data did not require it to understand the entire GraphQL infrastructure.
Outcome
The GraphQL and REST applications could ultimately use the same data model and UI.
Data types no longer had to be maintained manually in two places, and the related components, parsers, and formatters could evolve together.
GraphQL remained only in the application that needed it, while the domain model it described became a source shared across projects.
Reflection
This became a representative architectural judgment for me:
Transport mechanisms can differ, but the same domain should not therefore have two sources of truth.
GraphQL and REST concern how data enters the system.
What should truly become the Single Source of Truth is the system’s definition of the data itself.