Creating a CorDapp Plugin System

Get to production faster

The Plugin Paradigm

Using a plugin pattern allows you, as a CorDapp product vendor, and your customers to build highly focused and unique business logic that bolts on to a specific running instance of your CorDapp.

Importantly it allows Development and Ops teams to use languages, protocols, deployment processes and infrastructure they are familiar with to integrate your CorDapp into their existing systems and make it work for them.

RESTful API

After Ivno’s highly successful Global Corda Trial, we polled the participants and asked them if a RESTful API would likely be useful in a production setting— the answer was a resounding yes.

The default interface into a Corda node is RPC, which the majority of development teams are not familiar with. Http interfaces, on the other hand, are highly prevalent in modern-day programming.

Ivno have built a rich RESTful API to allow the querying of the vault and instructing the node to perform actions, such as starting the token transfer process. We also provide a real-time API to allow a “push” model into other systems.

It’s this interface that our Plugins will utilise.

The anatomy of an Ivno CorDapp Plugin

At Ivno all our Plugins are written in TypeScript as that’s the language we prefer to write web-tech products in. We have created a Plugin Library that encapsulates communications into our RESTful API. This Library is used across all of our Plugins and significantly reduces the development and testing time for each Plugin.

Where to Place Business Logic

CorDapps themselves are conceptually split into two parts, the plugin paradigm adds a third:

• States/Contracts — this is where your “absolute” rules go, things that must absolutely be true for your system to make sense. E.g. an IOU state cannot have the lender and the borrower be the same person.
• Flows— this is where the business processes that are core to your system are placed. They control the process flow by utilising Corda’s Flow Framework. Generally speaking they are used to build up a transaction by asking different parties for data, signatures etc., ultimately leading to a finalised transaction and thus a change to the shared ledger.
• Plugins — this is where you place instance-specific business logic. E.g. when a new IOU state is set to requested and you are the lender, and it’s less than or equal to $500, check your external system to see if the borrower is “trusted”. If they are, then automatically start a Flow to set the IOU to Accepted.

Benefits of Writing Plugins

You could create this logic inside of a separate, customer specific CorDapp. You could write custom Flows and utilise Corda Services to achieve the desired outcome. This is fine for a Corda shop, who already have the intimate Corda knowledge required to build a production-grade CorDapp. They already have testing and deployment processes and test environments suitable for CorDapp development.

Most customers won’t have this and so giving them the option to use technologies they already know to interface into the Corda node greatly reduces friction to production.

Simply put, Plugins make your CorDapp immediately accessible by your customers.

At Ivno we supply customers with our Plugin Library which reduces their development time and allows them to benefit from our products more quickly.

Customers can use languages, protocols, deployment processes and infrastructure they are familiar with. Empowering them like this has the following benefits:

• Customers can create Proof of Concepts easily and cheaply which they can use in their business case to get budget sign off for your CorDapp
• Customers can move into production much more quickly
• Customers will be able to maintain and improve their Plugins on their own, giving them freedom to iterate as and when they see fit

When not to use Plugins

Anything that is core to your application should go in a Flow and be provided as part of your product.

Plugins are for custom logic/integration points that are node-instance specific.

Example Use Cases

Creating connectors into existing systems: The Plugin can take events from the real-time API that triggers actions in another system. Equally the Plugin could listen for events in an external system that trigger an action on the node. It can keep the two systems in sync to create a seamless integration.

Customer specific logic: The Plugin could automate an otherwise manual step in a Flow — for example, to approve a token transfer given some customer specific requirements.

Slack notifications: The Plugin could fire messages to a Slack channel when certain events occur on the node.

Automate certain node roles in a test environment: At Ivno we’ve created a Plugin that automatically approves token issuance and redemption on the Custodian’s node. This isn’t something that would be done in production (obviously) but is exceptionally helpful when testing and demoing the product. Using a Plugin model avoids us shipping test-only code in the production product.

Here is some sample code utilising our Plugin library:

When a new inbound token transfer request is sent to this node, the Plugin will automatically accept it and the tokens will be transferred to this node.

What makes a Plugin System?

By creating and supplying a Plugin Library we are standardising the way external systems communicate with the node. For example, authentication is handled by a module within the library.

We also promote certain patterns when writing Plugins. For example, how to handle state to keep track of which events have been processed by the Plugin and the way in which the Plugin is deployed.

Infrastructure Architecture

We follow the sidecar pattern for the majority of our Plugins as we generally consider them an extension of the core product. As such they follow the same life cycle as the main CorDapps and are updated in lock step.

This isn’t always applicable so make sure you choose the correct architecture for your given situation.

In summary, adopting a Plugin system for your CorDapps will empower customers to get hands on with your app faster. They will be more comfortable with the technology, which can only be a good thing in such an emerging and complex world such as DLT.

 

– Authored by Adam Dry, Head of Technology at Ivno