Announcing WebSockets & Filters Support

At Nodesmith, we’re making interacting with Ethereum via the JSON RPC API as simple, reliable, and performant as possible. To meet those goals, our initial beta offered stateless access via HTTP only. This meant we were missing two key tools for developers: 1) WebSocket support, including subscriptions which allow you to get changes pushed to you in realtime, and 2) the creation of filters, which can be polled periodically to see state changes.

Today — we’re happy to announce that we’ve released support for both! If you want to jump straight into it — check out our quick start documentation.

We’ve experienced frustration in the past with the reliability of WebSockets while using local nodes or various node provider alternatives. Driven by that, we’ve architected our solution to ensure the WebSockets connections developers make are incredibly stable — all while using the same JSON RPC interfaces that you’re accustomed to.

WebSockets

Developers using Nodesmith can now access each JSON RPC method over WSS in addition to over HTTP. This means you can now use Nodesmith as a WebSocket provider with your favorite client library.

Creating a WebSocket subscription with web3.js

But where WebSockets really shine is in the ability to support subscriptions. WebSockets provide bi-directional communication between a client and the Ethereum Network via Nodesmith. Instead of requiring a client to periodically query to see if anything has changed, WebSockets allow clients to have data pushed to them when changes occur.

To enable this, Nodesmith now supports the eth_subscribe & eth_unsubscribe methods. These methods are part of the RPC pub/sub module, and allow for the following notifications:

• New Blocks - Each time a new block is added to the chain, a notification is sent with info about that new block. If a re-org happens, all the blocks which are part of the reorg will be included as well.
• New Logs - Notifies whenever a new block includes a log which matches the filter you specify is mined. This is a great way to watch for specific events in your smart contract (see example below)
• New Pending Transaction Receive a notification whenever someone submits a new pending transaction to the network

Here’s a concrete example — this Code snippet below uses a WebSockets subscription to get notified anytime a log matching the Transfer Event is emitted by any contract address on the network. This means anytime a token is transferred, a new line shows up in the table.

Nodesmith WebSockets in Action

Filters

Filters allow for similar functionality as WebSockets, but require periodic polling to see if anything has changed. The advantage of this is that filters are available via HTTP. They are also not constrained to the lifetime of the WebSocket connection, making them ideal if you need to ensure you never miss any events. A filter is created using the eth_newFilter, eth_newBlockFilter, and eth_newPendingTransactionFilter which return a filter id. That id is then used to query for changes using the eth_getFilterChanges endpoint. The filter id is tied to your specific API key, so there is no risk of someone else messing with a filter you’ve created.

How It Works

We’ve heard from developers that they want to use subscriptions and filters, but existing solutions frequently dropped connections, causing subscription updates to get missed and filters to be lost.

Nodesmith Cluster

To solve the issue of dropped connections, instead of exposing the WebSockets server inside of a standard Geth or Parity node, we use the enterprise ready Spring Framework and their WebSocket support to maintain our connections. Since we can scale these servers up or down without worrying about them syncing (like nodes need to), we’re able to handle a large number of concurrent connections. To handle subscription updates, we publish all network state changes to our Nova Service and then let each WebSocket connection determine if an update needs to be sent. Non-subscription related requests are processed just like when using HTTP by passing the requests to the Nova Service.

To solve the issue of filters being dropped, instead of tying the lifetime of a filter to the particular Ethereum node a request was sent to, each filter is associated with your api key and persisted in our filter persistence layer. When another call comes in to check if there have been any filter updates, we lookup the filter, see the last time an update was sent, then determine what has changed since that time according to the parameters. This means filters can be created a queried not just with a stateful WebSockets connection, but also with a standard HTTP connection.

Importantly — from a developer perspective — this is all using the same JSON RPC interface that you would use with a local node. So even in the case where Nodesmith goes down or we become a giant evil company (I promise, we have no plans to), you don’t have to change any of your application code. You’ll be able to fall back to existing options, you’ll just miss the performance & reliability optimizations provided.

Want to connect to Ethereum via WebSockets? Sign up with Nodesmith to get access.