By Parth Shukla, 180Protocol CTO
As promised during our presentation at CordaCon last week, we want give more detail on our initiatives building on Corda, sharing our experiences with the community. For a refresher, please check out our CordaCon presentation here.
When we set out to develop our own digital assets issuance and administration platform (the IAN) for private fixed income instruments on the eve of 2020, we had little doubt that R3 Corda was the right technology platform. It made a lot of sense: open source core, strong transaction-level privacy, very mature technology stack (Java), strong developer community, excellent documentation, and — last but not least — access to the Corda team itself. We were sharing physical office space with R3 in London as entrepreneurs-in-residence.
Fast forward a month, and we were in the weeds of the day-to-day reality of being a pre-seed fintech startup developing their first product on Corda. As early as during the detailed design and initial prototyping phases we started tripping over things. Strangely enough, the team had hands on experience with Corda in an enterprise setting from previous lives, and none of the issues we stumbled upon were novel. However, aspects of Corda that were perceived as non-issues, or even desirable features, in an enterprise context suddenly started to be problematic.
R3 were very supportive, and our commitment to Corda has not wavered in the slightest. It’s a fantastic product, and our tech team felt privileged to have access. What we saw were not bugs (although we saw one or two), or outright missing critical functionality (no product is ever complete), but incompatible features for fintech Cordapp developers. Corda’s product philosophy wasn’t always suited to the volatile environment of a fintech with its urgency-driven and resource-constrained full-stack technology team.
The IAN, our digital assets issuance and administration platform, is built on Corda, but Corda itself is not the only component of the architecture. A few other moving parts had to be developed including user interface components and middleware that would allow the IAN to be fully integrated into client’s IT systems estates (for example payment gateways). We saw that due to several Corda product design decisions, using Corda as a component of the system exerted disproportionate impact on other components.
Metaphorically, it was as if there was a massive gravitational pull in the middle of the galaxy making all stars, even the heaviest and brightest, spin around and ultimately converge. The challenge we had was to fight Corda’s pull toward taking our overall architecture in a direction we did not want to go.
As of today, the standard way to interact with a Corda node is through Corda RPC – a highly flexible and vastly complicated binary protocol tightly coupled to the implementation of Corda itself. To use Corda RPC one must have Corda client code, which effectively forces use of Java.
This isn’t much of a problem for a corporate user or a consultant. Java people are in ample supply, and the general consensus architecture is to develop a middle-tier component in Java, which speaks to Corda via the RPC on one end, implements all server-side business logic, and then presents a UI to the user. Pretty uncontroversial, and has been done by many organisations many times over, ourselves included.
Except we felt uncomfortable. There are two key reasons:
FIRST we needed an appealing and intuitive user interface for visualising and interacting with digital assets on the IAN, which necessitated a single-page application approach powered by modern JavaScript framework (we chose React). We also wanted to use Node.js on the backend to benefit from the pace and flexibility of a full-stack JavaScript approach and tooling. Node.js cannot talk to Corda directly. Developing a backend in Java and a frontend in JavaScript requires widely different skills that are hard to balance without unfortunate compromises.
The SECOND reason was infrastructure. At 180Protocol we are big proponents of Cloud-native architectures. We like to use managed services from Cloud providers. They are cost-effective, but principally they allow us to minimise risk around managing and securing the infrastructure used to run our application components. We wanted to optimise and use a function-as-a-service architecture pattern (also known as serverless) which is supported by all major cloud platforms, and is a very cost-effective way to develop and deploy loosely coupled backend components. Now, it happens that Node.js is a good option for developing functions owing to its fast bootstrap time and low memory footprint. One would have thought that Java is also a valid choice, but in practice many web and middle-tier frameworks like Spring Boot come with a lot of baggage and footprint, making it nearly impossible to develop serverless function-based applications. So, in short, Java did not feel right from this perspective either. Interestingly, this is also an area which did not feel problematic in enterprise context, as entire departments are dedicated to running Java-based application backends, which are taken for granted.
Our solution was to move towards cross-platform integration technology. Having researched the options, we focused on REST API. We developed a simple adapter component, instances of which are deployed next to Corda nodes as a ‘sidecar’. The adapter was connecting to the node over Corda RPC via the host network, and exposed an HTTPS endpoint making relevant RPC operations available. It also published OpenAPI specification for the endpoint, allowing rich tooling ecosystem from Postman to Autorest to be used to accelerate development. The adapter was ‘brainless’ and did not contain much business logic, and which made it relatively stable in the face of product iterations. Vast majority of changes effecting the UI and backend components were possible to achieve by JavaScript full-stack team, and ongoing changes in digital assets layer were limited to Java/Kotlin. Only when we had to extend the interface of Corda workflows or contract state domain objects, the adapter had to be changed to accommodate this.
This way we were successfully able to limit the pull of Corda and use a technology stack we were comfortable with. We also thought such approach would be better for a start-up, as it allows more efficient resourcing and makes production of infrastructure more secure and light-weight. Finally, we believe this is not a unique problem for 180Protocol, and that many other development teams using Corda – from start-ups to corporates – face similar challenges.
For more information, please check out our presentation from CordaCon 2020, where we discussed our exciting initiatives building on Corda. Please don’t hesitate to reach out if you wish to follow up via our website www.180protocol.com.
