Request/Response Middleware

[esterlus]

This draft introduces a new endowment that would allow a snap to register itself as a request middleware.

[hmalik88]

I think this SIP would better serve as defining Snaps JSON-RPC middleware instead of catering to becoming solely a JSON-RPC provider. I'm interested in re-writing this spec to have a Snaps middleware stack in the extension. I can envision a HOPR middleware snap still sending the request to the provider through HOPR and terminating execution through some res object. HOPR can be one of the first few snaps providing middleware.

[tolbrino]

I think this SIP would better serve as defining Snaps JSON-RPC middleware instead of catering to becoming solely a JSON-RPC provider. I'm interested in re-writing this spec to have a Snaps middleware stack in the extension. I can envision a HOPR middleware snap still sending the request to the provider through HOPR and terminating execution through some res object. HOPR can be one of the first few snaps providing middleware.

I think a generalized middleware stack would certainly be useful. However, as you already correctly described the RPCh integration would have to be some kind of middleware processing termination point because it touches the entire request (target, headers, body) and other middleware would not be able to process it further. As long as that is supported the approach should be good.

[tolbrino]

@hmalik88 @esterlus I updated the proposal to match the discussed middleware approach. Feedback is welcome.

[hmalik88]

Suggested change

	title: JSON RPC provider
	title: JSON RPC Middleware

I think Middleware is more appropriate here, given that we want to forward the result to our selected provider.

[hmalik88]

Suggested change

	"endowment:json-rpc-provider": {}
	"endowment:json-rpc-middleware": {}

[hmalik88]

Suggested change

	This SIP specifies a new exported event handler `onOutgoingJSONRpcRequest`.
	This SIP specifies a new export: `onOutboundJSONRpcRequest`.

[Mrtenz]

onOutboundRpcRequest maybe, so it's more consistent with the existing onRpcRequest.

[hmalik88]

What happens when there are multiple middleware snaps competing for these different points in the stack?

[tolbrino]

Good question. I think this must be handled at 2 points: (1) Within MM where snaps are loaded which will simply skip over more middlewares for points which are filled already. (2) Allow the user to specify some order through the MM settings where its easy to show that these points are filled and limit that no more middlewares are enabled which would compete for such a point.

An alternative could be during installation of snaps which could be prevented if the middleware tries to fill a point which is already taken.

[Mrtenz]

Within MM where snaps are loaded which will simply skip over more middlewares for points which are filled already.

Generally, a middleware stack can run multiple middlewares in a row, and each one can run their own logic to modify the request/response, before it's passed on to the next middleware. Do you think we need to limit it to a single middleware?

Allow the user to specify some order through the MM settings where its easy to show that these points are filled and limit that no more middlewares are enabled which would compete for such a point.

I think middleware would be very difficult to explain to a user in a meaningful way. 😅

[tolbrino]

Generally, a middleware stack can run multiple middlewares in a row, and each one can run their own logic to modify the request/response, before it's passed on to the next middleware. Do you think we need to limit it to a single middleware?

If its limited then I would move away from calling it a middleware and focus on specific use cases, similar to the original proposal in this SIP which focused on RPC http call execution.

I think middleware would be very difficult to explain to a user in a meaningful way. 😅

I agree, the middleware concept is developer-oriented, nothing users are usually confronted with.

[tolbrino]

@Mrtenz @hmalik88 I would like to turn this SIP into a form which is acceptable to you and which works for our use-case. As it stands the current proposal is somewhat in between a generic middleware approach and a focused support for RPC request execution.

To keep things simpler I would actually propose to split this into 2 SIPs: (1) Middleware without support for entry or termination, which simply can modify the request headers and data; (2) A RPC request executor, only a single one can be set, which replaces the "simple" fetch internally.

Thoughts? I am happy to write both SIPs if we agree on the approach.