bytechefhq / bytechefhq/bytechef

[task] Migrate all remaining internal REST calls to GraphQL

Open
#5,538 0 comments 0 reactions 1 assignee Claimed by @ivicac View on GitHub
backend task
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.