bytechefhq / bytechefhq/bytechef
[task] Migrate all remaining internal REST calls to GraphQL
- Dominant language
- Java
- Stars
- 1k
- Forks
- 170
- Avg merge
- 11h 25m
- Merged PRs (30d)
- 115
Description
## 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:
1. Inventory the remaining internal REST usage and group it by domain, so each domain can be migrated and verified on its own.
2. 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.
3. 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.
Contributor guide
Assessment
This issue has not been assessed yet.