Conversation
ericpgreen2
requested review from
AdityaHegde,
briangregoryholmes and
djbarnwal
|
|
||
| Each subtree uses its own transport and instanceId. Components don't need to know which runtime they're in. | ||
|
|
||
| ## Code Generator |
There was a problem hiding this comment.
Is there a library for this already?
| }); | ||
|
|
||
| const client = createRuntimeServiceClient(transport); | ||
| const explore = await client.getExplore({ |
There was a problem hiding this comment.
This doesn't populate the tanstack query cache right? We might need to restructure our generated code to support something direct fetching with cache population.
Or avoid loader functions altogether.
|
|
||
| ## Open Questions | ||
|
|
||
| 1. **Query key namespacing:** Should query keys include a version or hash to handle proto schema changes? |
There was a problem hiding this comment.
What does this give us? Wouldnt the backend APIs not exist for the previous endpoints anymore?
| // Switch to viewing as another user | ||
| async function impersonateUser(userId: string) { | ||
| const newJwt = await adminService.getImpersonationToken(userId); | ||
| // Update RuntimeProvider props → new transport created → queries refetch |
There was a problem hiding this comment.
Would this mean this function will have to sit above the <RuntimeProvider> wrap? Would be good to flesh this section out to make sure there are no issues.
|
One thing that this touches on, but does not fully incorporate is the dependency between runtime data and a project. I think, historically, bringing the terms host/runtime/instanceId to the forefront confused what was actually happening, which is that a user was simply querying something in a project. To that end, I don't think we should have a I also think the Here's a very rough working implementation of what I'm imagining: #8603 |
Replaces the original high-level options analysis with a concrete implementation plan covering RuntimeClient class, code generator, invalidation updates, consumer migration strategy, and PR sequencing. Addresses feedback from Brian and Aditya on the original doc.
The JSON bridge modifies the v2 code generator so hooks accept/return Orval-compatible types (V1*) instead of proto types. This lets consumers switch to v2 hooks without changing their type usage, unblocking global store removal independent of the oneof type migration.
Restructure the plan so the JSON bridge reads as part of the code generator's design rather than a separate phase patched on later. Phases renumbered from 7 to 6.
…design Integrates the lightweight runtime registry into Phase 1 as foundational infrastructure alongside `RuntimeClient` and `RuntimeProvider`. Adds concrete `.ts` module migration guidance to Phase 4 covering query option factories, module-level singletons, and SSE/streaming code. Addresses Brian's feedback on non-component access to `RuntimeClient`.
3 participants
Problem: The frontend manages runtime connection info (host, instanceId, JWT) through a global mutable Svelte store. This works when there's one runtime, but breaks down when a page needs to talk to multiple runtimes simultaneously — which is the case for cloud editing, where a dev deployment coexists with production. The cloud editing MVP (PR #8912) works around this with conditional rendering and manual store overwriting, but the workarounds are fragile.
Proposal: Replace the global store with a
RuntimeProviderSvelte component that creates a scopedRuntimeClientand sets it in Svelte context. Components read the client from context instead of importing a global store. Nesting providers gives multi-runtime support for free. A lightweightruntimeRegistrysupplements Svelte context for.tsmodules that can't receiveRuntimeClientfrom a component ancestor (SSE clients, test harnesses). The current Orval-generated query hooks are also tied to the global store — every generated function reads the singletonhttpClient— so they can't be reused as-is. Since we need new code generation anyway, we migrate the transport layer to ConnectRPC at the same time, using a custom code generator to produce TanStack Query hooks from the protobuf service definitions.The detailed plan is in
plans/runtime-context-architecture.md. It covers theRuntimeClientclass design, code generator, invalidation strategy, a batched consumer migration (~100 files), and a 6-PR shipping sequence. It also responds to feedback from earlier rounds of review on this PR.Seeking feedback — not intended to merge to main.
Checklist:
Developed in collaboration with Claude Code