Make RPC transports responsible for preparing payloads

[lorisleiva]

This PR slightly adjusts the boundaries of the RPC Transport layer by making RPC transports responsible for creating the payload they will send over the wire.

This mean, the RpcRequest type flows from the RPC API layer to the RPC Transport layer (with the addition of the abort signal when reaching the send method).

In other words, this is the key change this PR makes:

// Before.
type RpcTransportRequest = Readonly<{
    payload: unknown;
    signal?: AbortSignal;
}>;

// After.
type RpcTransportRequest<TParams = unknown> = RpcRequest<TParams> & {
    readonly signal?: AbortSignal;
};

[changeset-bot]

🦋 Changeset detected

Latest commit: f62ca3a

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lorisleiva]

• Make RPC transports responsible for preparing payloads #3186 👈
• Make RpcResponse provide the resopnse payload directly #3185
• Remove temporary fix for Agave issue 479 #3184
• Update getClusterNodes response #3201
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @lorisleiva and the rest of your teammates on Graphite

[steveluscher]

So, this makes sense if you think of the transport as particularly a JSON-RPC transport. I expected that we'd stop short of this thing knowing anything about JSON-RPC.

These are the levels of ‘knowing about stuff.’

1. I know how to send and receive bytes over HTTP
2. I know how to send and receive JavaScript objects over HTTP
3. I know how to prepare JSON-RPC method calls as JavaScript objects and interpret the responses
4. I know how to fulfil @solana/web3.js API calls.

This is how I thought we'd divide these responsibilities up.

1. createHttpTransport() makes something that just ferries bytes (as text) back and forth
2. createHttpTransportForSolanaRpc() something that wraps createHttpTransport. Inputs and outputs are JavaScript primitives (as unknown). It looks inside them (ie. check if it's an object, then a JSON-RPC message, then one of the allowlisted methods) to see if it should muck around with them or not according to the specific rules we have around upcasts. Ultimately passes text to the underlying transport.
3. createSolanaRpcApi knows about the JSON-RPC protocol. Can prepare a struct representing a JSON-RPC method call and interpret a response struct.
4. Delegates userland API calls to the RpcApi as normal.

This would mean that these calls live at these levels.

1. fetch
2. Your fancy JSON.stringify implementation, isJsonRpcMessage(payload), bigint upcast stuff
3. createRpcMessage(request)
4. the usual crap

The implication of this architecture is that you could swap out 1 & 2 for the createCarrierPigeon() transport, and as long as the carrier pigeon knew how to take the JavaScript object {jsonrpc: '2.0', method: 'getSlot'. id: 1} to its destination and to bring back the JavaScript object {id: 1, result: 123n} everything else continues to work without modification. Carrier pigeons, after all, understand large numbers and don't need our stupid JSON serialization code.

[github-actions]

Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up.