At Blockdaemon, we’re constantly evolving, always looking for a way to optimize and streamline our daily interaction with the growing number of protocols we manage. A big part of this is dealing with the myriad of different APIs in the blockchain space, and for this reason, we’ve created the Ubiquity API.
Anybody – developers, exchanges, wallets, institutions and enterprises – that deals with more than just a couple of blockchain protocols knows how tedious it can be to keep switching contexts just to re-learn a new set of commands and APIs. We had those same pain points and decided to build Ubiquity. Software projects that communicate with a number of different protocols also can use less repetitive, standardized code that minimizes the need for switching logic to handle API differences.
In the spirit of not writing a whitepaper in place of a blog post, we’ll just highlight just a couple of the challenges we faced, the first one being time; A project like this in a volatile space is a timely undertaking when thinking about time to market. We would need to get from zero to hero as quickly as possible. Another significant issue is that not all protocols are created equal. For this reason, our solution had to be flexible enough to deal with a lot of variation, and yet provide a uniform interface for our customers.
Along the way, we learned some valuable lessons that we’ve learned from and been able to see the benefits across our platform. With 30+ protocols and a robust selection of node types and add-ons supported in our marketplace, a common way to extract transaction data from many different blockchain protocols proved to be a necessity. Our users have expressed a clear and universal preference for true API use cases with an easy to use interface which complements our overall platform. This valuable insight is what led us to develop Ubiquity.
We decided to save time and search for someone that had dealt with the problems we were facing. We were lucky enough to have Richard Patel, who built BlockAtlas, the multi-chain explorer serving the Trust Wallet app, join our cause. When we discussed our vision with Richard he was eager to collaborate and now he’s a full team member and a huge part of the success of Ubiquity.
Uptime was crucial, and yet as we went through the different environments, it wasn’t something that was initially prioritized in the development phase. We started by using Docker Swarm, then quickly realized that more thought around orchestration was required. We migrated to Kubernetes to take advantage of what it has to offer. We also revisited how we managed configurations and secrets, and arrived at a solution we’re proud of – scalable, performant and secure.
While trialing a few different architecture options, we decided that adding a layer of abstraction above block and object storage would provide us the ability to be flexible around where we stored blobs of data. Our initial selection of Ceph has been a success and so far looks like a great candidate.
Cost efficiency at scale
One of the benefits of Event Driven Architecture (EDA) is better scalability and fault tolerance. RabbitMQ was already part of our platform stack and we decided to expand its usage in other areas. Based on the robust Erlang language, RabbitMQ is a highly resilient, battle-tested message broker. We thought about some other contenders, such as NATS and Kafka, and yet RabbitMQ has proven to be just right for our needs.
We thought hard about the hidden benefits of a monolith over microservices and decided on abstracting the services just enough where it made sense to consider the logical separation of code and where certain functionality made sense as a separate service in terms of scaling. By taking the approach of using microservices, we could break down the architecture into independent components that allowed us to update, revise, and communicate faster without disrupting the current platform experience.
The blockchain space evolves at pace. Since we facilitate the operation of so many protocols for a wide range of use cases, we’ve learned what should be generalized and what needs to be bespoke. Over the last two years, we’ve continued to be surprised, and relished the chance to turn challenges into opportunities. If you’re interested in taking Ubiquity for a test ride, we’d love to hear from you and see how we can help you speed up your acquisition of protocol knowledge. Email us at email@example.com to get started and check out our documentation for additional details.