March 31, 2020
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.
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.
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.
CorDapps themselves are conceptually split into two parts, the plugin paradigm adds a third:
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:
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.
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.
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.
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
Share this post
Stay up to date on the latest news and articles related to Corda.