From the beginning, one of the primary drivers of OpenRelay’s design decisions has been operational simplicity. We have a very small team, and spending lots of time maintaining services would mean not spending enough time on developing the platform. Out of the gate, we decided we wanted to use a storage engine for the order book that was a managed database. We believed at the time that DynamoDB would be an adequate storage engine with minimal operational overhead.

DynamoDB

However, we soon found that the limitations of DynamoDB were going to limit what OpenRelay was capable of. DynamoDB only allows for five global secondary indexes, so if we wanted to support querying by:

We were going to need additional global secondary indexes, and things were going to get complicated quickly.

Additionally, DynamoDB requires our code to specify what indexes to use, and does any additional filtering with a scan. Essentially, it lacks a query optimizer that uses statistics about the distribution of data to choose the most efficient index.

Another downside of using DynamoDB is that the Go drivers for DynamoDB left a lot to be desired. Enough so that we decided that any services interfacing with DynamoDB would be written in Python, to take advantage of the PynamoDB ORM. While we think Python is a great language, and OpenRelay’s Microservices API makes writing different services in different languages pretty trivial, adding a new language to our system was not a decision we took lightly. It has a number of operational implications, and also raises the bar for contributors, who now need another language under their belt to make contributions.

Finally, DynamoDB is an Amazon Service, meaning OpenRelay couldn’t run anywhere other than Amazon. This wasn’t an immediate concern for OpenRelay.xyz, which is indeed hosted in Amazon Web Services, but it certainly wasn’t something we considered a feature.

PostgreSQL

PostgreSQL solves most of the issues we had with DynamoDB. It gives us as many indexes as we need, it has a query optimizer, it plays nicely with Go, and since it’s open source you can run it anywhere. Amazon Web Services provides managed PostgreSQL via RDS, and advanced scaling via Aurora, so it should be relatively easy to manage for the foreseeable future. For those who want to run OpenRelay outside of Amazon, they can manage their own PostgreSQL server, or use any of a number of other managed PostgreSQL providers.

API Versioning

As the services that interact with the Order Book have been rewritten, we have built the search API to implement the 0x Standard Relayer API. The new spec compliant API will be found at https://api.openrelay.xyz/v0/, while the old version will continue to be available at https://api.openrelay.xyz/v0.0/. The /v0/ API will be served from the PostgreSQL version of the order book, while the /v0.0/ API will continue to be served from DynamoDB. Uploaded orders will be added to both versions of the order book as they are processed.

OpenRelay.js

OpenRelay.js is a JavaScript library for interfacing with OpenRelay.xyz, as well as any other 0x Standard Relayer implementation. In our previous announcement, OpenRelay.js implemented our /v0.0/ api, but now it fully complies with the Standard Relayer API, and should work with any Standard Relayer API implementation.

Despite implementing the Standard Relayer API, we still consider OpenRelay.js to be in preview while we implement some of the remaining APIs and, very importantly, get the documentation ready to go.

Ropsten Testnet Support

As of today, we have support for the Ropsten Testnet. Orders for the Ropsten testnet can be submitted to https://api.openrelay.xyz/v0/order just like transactions for mainnet. They are distinguished by the exchange address specified in the order. Transactions for mainnet should specify the exchange as 0x12459c951127e0c374ff9105dda097662a027093, while transactions for Ropsten should specify the exchange as 0x479cc461fecd078f766ecc58533d6f69580cf3ac.

We have orders available to acquire Ropsten ZRX in exchange for Ropsten WETH. We will try to keep the exchange stocked with orders for more Ropsten ZRX, but would ask that you take only what you need so that Ropsten ZRX is available for those who need it.

We have no immediate plans to support Kovan or Rinkeby, but are open to doing so if there is significant interest.

Coming Soon

Now that OpenRelay.xyz has stabilized a bit and fully implements the Standard Relayer API, our next focus will be on polishing off OpenRelay.js, and getting a portal site working to submit and explore orders on OpenRelay.xyz. Our portal site will be relatively unique, in that it will focus more on educating users and developers about the 0x Protocol and Tokens in general, rather than trying to build an exchange focused dapp.

A Call for Help

OpenRelay has a small team, and is stretched pretty thin. We would love to get some more community involvement, and invite people who are interested in participating to take a look at our list of open issues. If you’re interested in contributing, we’ll try to make the time to help you get up to speed if you’ll take on some of those listed issues.