Goal
Finish the migration of the client's internal API traffic to GraphQL, so that GraphQL is the single read/write surface for the application UI and the generated internal REST clients can be retired.
Why
The client currently talks to the backend two ways at once. GraphQL is the intended surface — it is where the newer domains live, where the centralized error handling and toast behaviour is implemented, and where the codegen workflow is established. The generated internal REST clients are the legacy half, and keeping both means:
- two request pipelines to keep in step (auth, CSRF, error surfacing, cancellation, cache invalidation), where a fix applied to one silently misses the other
- two code-generation workflows and two sets of generated types for the same domain concepts
- query caching and invalidation split across two conventions, so a mutation on one surface does not invalidate reads on the other
Scope
Over a thousand client modules still import the generated internal REST clients, so this is not a single change. Expected shape of the work:
- Inventory the remaining internal REST usage and group it by domain, so each domain can be migrated and verified on its own.
- Per domain: add the GraphQL schema/operations if missing, regenerate, migrate the call sites, migrate the query keys and invalidation, remove the domain's generated REST client.
- Retire the internal REST endpoints server-side once no client references remain.
Public REST surfaces are explicitly out of scope — only the internal, client-facing API is being migrated.
Definition of done
- No client module imports a generated internal REST client.
- The internal REST controllers that existed solely to serve the client are removed.
- One documented path for adding a new client-facing read or write.
Suggested approach
File a tracking issue per domain rather than attempting this in one pass — each domain is independently shippable and independently verifiable, which keeps the migration reviewable and lets several people work in parallel.
Goal
Finish the migration of the client's internal API traffic to GraphQL, so that GraphQL is the single read/write surface for the application UI and the generated internal REST clients can be retired.
Why
The client currently talks to the backend two ways at once. GraphQL is the intended surface — it is where the newer domains live, where the centralized error handling and toast behaviour is implemented, and where the codegen workflow is established. The generated internal REST clients are the legacy half, and keeping both means:
Scope
Over a thousand client modules still import the generated internal REST clients, so this is not a single change. Expected shape of the work:
Public REST surfaces are explicitly out of scope — only the internal, client-facing API is being migrated.
Definition of done
Suggested approach
File a tracking issue per domain rather than attempting this in one pass — each domain is independently shippable and independently verifiable, which keeps the migration reviewable and lets several people work in parallel.