@whatsgood/nexus is currently in pre-alpha. Some features may not work as expected. Please report any issues you encounter at our community Discord or file a GitHub issue.

​
Introduction

There are many benefits to using reverse proxies for traditional applications. The benefits become even more significant in the context of blockchain applications. Below are some of the most important ones:

​
Cost Savings

Most node providers bill their clients based on the number of requests they serve. This implies that significant cost-savings can be achieved by reducing the number of requests sent to the node. Since blocks are mined at fixed intervals, this is the perfect use-case for caching read requests. In fact, this is how most node providers operate: they wrap their nodes with a reverse proxy of their own, and serve their clients their own cached results. You can employ this very same strategy and significantly cut down on your node provider costs. Check out Caching for more information.

​
Privacy

While there are many successful and trustworthy node providers out there, it is still a good idea to avoid exposing the IP addresses of your users. When you use Nexus as a reverse proxy, the node provider will only see the IP address of your Nexus server, thus respecting the privacy of your end users.

​
Vendor lock-in

When you use Nexus, you are able to switch node providers from a single location, without downtime and without having to change your dApp code or configuration. This is especially useful if you are publishing multiple dApps, connecting to multiple blockchains, or operating multiple clients and services that require blockchain access.

​
Future-proofing

You will occasionally find that your dApp requires to connect to a new chain. If the chain is especially new, such as the latest testnet, your current provider may not have begun supporting it, but perhaps another provider has. When this happens, you will suddenly find yourself juggling multiple providers, which increases operational complexity. When you use Nexus, you can simply add a new node provider to your configuration and you’re good to go. No need to introduce additional providers to your dApp.

​
Availability

If one of the RPC providers you’re using experiences failure or downtime, Nexus will cycle the request to another one, effectively multiplying your availability and uptime. Check out Load Balancing for more information.
In the upcoming release, Nexus will continuously track response times and availability of your providers and will automatically forward requests to the fastest one.

​
Key protection

The de-facto way we as dApp authors share blockchain node access with our users is by exposing our access keys in our client code. These keys are usually statically compiled into the build (such as Next.js or Render environment variables). This is a security risk, as anyone with access to the client code can extract the keys and use them to access the blockchain on your dime. Worse, this can cause your keys to be rate limited or even disabled by your provider, causing outages for your users. Industry leaders have done good progress in implementing access protection through CORS, contract addresses, wallet addresses and even IP addresses. These are all great solutions, but they are not universal or standard. If you commit to a provider that implements these measures, you will risk vendor lock-in. If you switch providers, you will risk key exposure. Nexus brings the best of both worlds: you can use any provider you want, and you can protect your keys from being exposed. Nexus will protect your keys and will only expose its own access keys to your users. If run in token mode, unlike standard providers keys which are baked into your client code, Nexus will manage access through jwt tokens at runtime.

​
Custom authorization

The industry standard for access protection is to isolate modes of access into “applications” or “keys”, and then bake these keys into your various dApps. We usually make do with these, but we end up with a very coarse-grained access control that tends to apply to the entire dApp. If you want to restrict access to certain parts of your dApp, or specific users, you are out of luck. Consider the following scenario, which is unattainable without Nexus:
  • Anonymous users can only read totalSupply() and balanceOf() for your token contracts A and B.
  • Logged-in users can read totalSupply() and balanceOf() for your token contracts A, B and C, and also call transferTo() on A and B.
  • Admin users can read all contract data, or call any contract method.
Nexus is currently under development. Fine-grained access protection (described below) will be available in an upcoming release.
Nexus allows you to create fine-grained scopes via middleware. If you’re already using a token-based authentication system, you can configure your services to sign Nexus tokens as you authenticate your users. Check out Authorization and Middleware for more information.

​
Decentralization

If you’re using a single rpc provider, it becomes your single point of failure. Nexus round-robins the relayed requests when it detects multiple configured providers for a given chain. For example, if you configure your access keys for infura, alchemy and ankr, since they all support eth mainnet, your clients will have their requests randomly relayed to one of these providers at any given time, effectively decentralizing your blockchain access.
In the upcoming release, Nexus will optionally allow you to configure quorum based strategies, such as 2-of-3, 3-of-5, etc. This will provide additional security and decentralization, beyond the randomized-round-robin strategy.
Many client libraries such as web3.js and ethers.js actually allow you to configure multiple providers on the client-side. They empower you to implement RPC quorum strategies such as 2-of-3, 3-of-5, etc. If decentralization is your highest priority, you are highly encouraged to use these strategies in conjunction with Nexus.

​
Coordination

If you’re building anything beyond a simple, single-purpose dApp such as a token swap, you will likely be coordinating distinct services and web2 state with your web3 activity. The current de-facto solution is setting up background jobs that listen to web3 events and update your web2 state accordingly. The issue here is that you want your user experience to be as close to realtime as possible, and the inherent asychronicity of this solution makes it very difficult to achieve this. This will also require you to implement web2 subscriptions on your client side to adapt your UI to the changing state, which further complicates your codebase. Alternatives include orchestrating a series of api calls directly on the client-side, where you may first dispatch a web2 call to your backend, then dispatch a web3 transaction, await its confirmation and finally dispatch another web2 call to your backend for post-processing. This is a very brittle solution, as it requires implementing a lot of error handling and retry logic. It further raises concerns over atomicity too, as you may end up with a partially completed state transition if any of the steps fail. Nexus allows you to execute custom code before, during and after your web3 transactions, allowing you to handle state transitions atomically and in a single request. Since this happens on the server-side, you are no longer required to implement web2 subscriptions on the client-side. You are further protected from client-specific failure modes, such as network connectivity issues or request interruptions (e.g. user closes the browser tab in the middle of a state transition). Nexus does this through Event Handlers, which allow you to coordinate web2 and web3 state updates in a single request. This is a much more robust solution, as it allows you to handle errors and retries in a single place, and it also allows you to implement atomicity, as you can rollback your web2 state if your web3 transaction fails. Nexus allows you to inject custom code based on built-in events, as well as custom events that you define yourself.

​
Rate limiting

Nexus allows you to configure rate limiting on multiple levels. You can limit based on IP addresses, request types (e.g. eth_call, eth_sendTransaction, etc.), request parameters (e.g. method, params, etc.), aggregate number of requests per second, user roles, and many more. You can even configure different rate limits for different providers. This allows you to protect your providers from being rate limited or disabled by your provider, causing outages for your users. If the out-of-the-box rate limiting capabilities of Nexus are not enough for your use case, you can easily extend them by implementing your own rate limiting logic of your choice. Check out Rate Limiting for more information.
Nexus is currently under development. Rate limiting will be available in an upcoming release.