Tech design: Runtime context refactor

[ericpgreen2]

Seeking feedback. Not to merge to main.

Brian's PRs #8559 and #8572 tackle the runtime context issues from different angles. I spent some time digging into the problem and wrote up this document to clarify the options and propose a direction.

The short version:

• fix: canvas to project navigation #8559 fixes the immediate canvas bug — I think we should merge it
• For the longer term, I'm proposing we move toward a context-based architecture with Connect Web, which would support querying multiple runtimes on the same page and align with our desired gRPC migration

Looking for feedback on:

• Does the proposed architecture make sense?
• Any concerns with the migration strategy?
• What's missing?

[AdityaHegde]

Is there a library for this already?

[AdityaHegde]

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.

[AdityaHegde]

What does this give us? Wouldnt the backend APIs not exist for the previous endpoints anymore?

[AdityaHegde]

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.

[briangregoryholmes]

One thing that this touches on, but does not fully incorporate is the dependency between runtime data and a project. I think bringing the terms host/runtime/instanceId to the forefront confuses what is actually happening, which is that a user is querying something in a project.

To that end, I don't think we should have a RuntimeProvider, but rather a ProjectProvider, with the context being the project name and org name or even the connectrpc client itself. Currently, the tech design useRuntimeService hook retrieves the instanceId and transport and then creates the client, but this is unnecessary. The responsibility for creating the client should exist further up the chain as part of some manager class (that also handles scheduled refetching, etc.). There's no need to provide the transport/instanceId as context.

I also think the useRuntimeService hook should work in both .svelte and .ts contexts. That way, the necessary ids for lookup can be provided when outside of a component. As such, the methods on the custom client object should return both createQuery functions (as they do currently) and the options object (for use with queryClient.fetchQuery()). This would hugely simplify a headache we have with Orval currently.

Here's a very rough working implementation of what I'm imagining: #8603