Why Explorer uses WAMP to communicate between backend and frontend?

[frol]

There were the following requirements:

• request-response type of communication
• publish-subscribe (pub-sub) type of communication
• reasonable support from older browsers
• simple to run

What was sacrificed:

• scalability
• public API spec

Transport Layer

There are three transport layers available in modern web browsers: HTTP, Websocket, Server-sent Events (SSE)

HTTP

Pros:

• Dumb simple
• Highly compatible with everything else
• Supports request-response mode

Cons:

• No pub-sub support (long-polling is ugly)
• Inefficient in terms of communication latency and traffic overhead

Websocket

Pros:

• Fairly simple
• Widely supported in web browsers
• Supports request-response mode
• Supports pub-sub mode
• Efficient in terms of latency / traffic overhead

Cons:

• Raw Websocket connections are cumbersome to maintain (reconnections on the client side, and state management on the backend side)

SSE

Pros:

• Fairly simple
• Supports pub-sub mode

Cons:

• Edge browser only got the support in 2020
• No request-response support

API Layer

Given the things mentioned above, and the wish to keep the backend code under a single umbrella (I don't feel it is a requirement anymore), I was looking into various solutions out there: OpenAPI (Swagger), gRPC, Thrift, Cap'n'Proto, ZeroC (ICE), JSON-RPC, GraphQL, and WAMP-proto.

• OpenAPI and RESTful API in general was ruled out for lack of pub-sub (btw, I used to be a huge fun of OpenAPI and RESTful APIs).
• gRPC requires one to have an extra HTTP-gRPC proxy, and it felt ugly and fragile.
• Thrift had only partial pub-sub support.
• Cap'n'proto is too low-level and not designed for web.
• ZeroC (ICE) did not have JS or Rust server implementation as far as I remember, and JS client implementation was quirky.
• JSON-RPC has nothing to offer at all.
• GraphQL server implementations are impossible to get right from the security (DoS and permissions [not applicable here]) points of view.
• WAMP-proto was simple enough, and it got us running in minimum amount of time.

Future Considerations

I feel that these days, we don't necessarily need a single backend service for request-response and pub-sub. We can afford going with separate implementations for those, and that will relax requirements for pub-sub, where we can even consider having a barebones websocket server that will just publish events with kind field in it, so the frontend can decide how to handle those.

[luixo]

Thanks for detailed explanation!

Pub/sub and request/response

I believe pub-sub and request-response should be decoupled in current state of the project, as extra wamp layer:

• adds latency
• adds one more point of failure
• makes DX significantly worse with current tooling
• requires more powerful hardware for wamp server

Request/response solution

I don't see no need to reinvent the bicycle, let's just use plain REST over HTTP.

Pub/sub solutions

Considering pub-sub requirements, I'll dig into solutions offered in open source at the moment.
From the first glance it seems that there are not many requirements for the API layer:

• it manages errors;
• it manages reconnections;
• it handles sockets (memory-wise);
• it scales;
• it is controllable inside out (unlike wamp).

I hope we can find a library that can fit in this pretty simple list, but if not - it doesn't look like a big challenge to write one.

Please let me know if I forgot to mention something significant.

[frol]

I don't see no need to reinvent the bicycle, let's just use plain REST over HTTP.

If you mean, let's use URL-based plain HTTP GET calls, I would agree with you. Defining a proper RESTful API is tiresome work that is not worth the trouble when we don't plan to launch it as a public API.

From the first glance it seems that there are not many requirements for the API layer

It is a well-thought list of requirements 👍

Please let me know if I forgot to mention something significant.

I cannot think of anything else for Explorer use-case, but in general case what I want to bring to your attention is that when we step into authenticated access area (DevConsole might need it), pub-sub backends will need to be more complicated when it comes to scaling personalized access to the data.

[luixo]

We made our decision and moved to TRPC: #1008