Subway: The missing Substrate JSON RPC Gateway

Tech Talk
1

Background

Anyone with enough backend experience will know that reverse proxy or API gateway is almost a must-have component for any public large scale API services. However, to my surprise, I still cannot find a production ready API Gateway with decent JSON RPC support.

Without API Gateway, it is hard to scale RPC servers as create a new node is very expensive and time-consuming. It is simply not feasible to scale out RPC nodes base on real-time demand. As a result, we need to over-provisioning RPC nodes and that is costly.

It is also relatively easy to DOS RPC nodes, as there are some RPC calls could be resource intensive. Substrate is not designed to run as a robust RPC server, which requires features like rate limiting and response caching.

Subway: Substrate JSON RPC Gateway

Subway aims to fill the missing gap by offering a high performance JSON RPC API Gateway with features specifically built for Substrate and Ethereum RPC.

Repo: https://github.com/AcalaNetwork/subway

Features

  • Multiple upstream node for failover and load balancing
  • Cache responses to reduce upstream node load
  • Merge identical subscriptions to reduce upstream node load (WIP)
  • Rate limiting for DOS prevention (WIP)
  • Advanced RPC call filtering (WIP)
    • e.g. filter what runtime call are allowed for state_call
  • High performance (it is written in Rust so it must be fast :crazy_face:)

Subway is only two weeks old and missing a lot of features to be production ready. However I do believe it could significantly improve RPC services and reduce infrastructure cost.

Let me know if you have any feedbacks and if you happen to enjoy writing async Rust, contributions are also welcome!

19 Likes
2

Nice to see a RPC reverse proxy dedicated to Substeate. The upcoming method filtering feature will be very useful. Two question though: does it support both ws and http endpoint? What leads you to develop your own reverse proxy instead of using more general ones like nginx / caddy?

3

I never tested http but if it is not working, it is trivial to enable it as the underlying jsonrpsee library handles it all.

I did some research with other general purpose reverse proxy but can’t find anyone meets my requirements. e.g. rate limit number of messages in a websocket channel and merge identical subscriptions.

1 Like
4

I had this topic on my list for a while but did not get a chance to get to it and I am very happy to see this project happening. Having such a proxy is great, especially if it could handle some kind of configurable plugin/extension system.

Some users will want no caching, some will want caching with specific rules and backend, the ability to let a caching plugin (for instance) control how the proxy behaves could not only reduce greatly the load on the rpc endpoints but also improve the users’ experience by shortening the response time.

Such a plugin system could be also helpful to virtually add new RPC methods that do not exist (yet?) in the nodes’ rpc endpoints.

5

This is really great.

In parity-ethereum we had a bunch of logic in the node itself which was essentially a bad reverse-proxy and with Substrate we decided to just keep things simple and have reverse-proxies built on top of it. Here it is! :slight_smile: