Corda for Javascript, Python, etc


(Fuzz) #1

Hi,

We’re thinking of open sourcing a package that may be useful for NodeJS, HTML5, Python, and other dynamic languages and runtimes. Would be great to hear feedback from the community.

In a nutshell

  • Easy access to Corda from the language and runtime of your choice
  • First-class classes and methods for accessing Corda services and cordapps flows
  • RPC and streaming semantics e.g. listening for transactions from the vault
  • Secure transports and signed payloads
  • Fully managed transport. Degrades gracefully from Websockets to XHR POST requests without any fuss
  • Can easily expose your own custom services as simple POJOs / POKOs. No more hand-crafted REST services!
  • Pluggable authentication and authorisation API

An example in Javascript

(other language driver could also be easily created)

  1. Install the package.
npm install --save hermes-corda-client
  1. Use the library in your Javascript app:
// import the library
import CordaClient from `hermes-corda-client`

// bind to the corda node
const corda = new CordaClient('localhost:8080', onOpen /*, onClose, onError */);

function onOpen() {
    let notary = null;
    let otherParty = null;
    const nm = corda.networkMap;
    nm.notaryIdentities()
        .then(notaries => { notary = notaries[0] })
        .then(() => nm.getNodeByLegalName({ organisation: 'BankB'}))
        .then(bankB => { otherParty = bankB})
        .then(() => corda.vault.updates(item => console.log('vault update: ', item))
        .then(() => corda.flows.makePayment({ quantity: 100, token: 'GBP' }, otherParty, notary))
        // etc 
}

Meanwhile, on the server-side …

@CordaService
class MyService(serviceHub: ServiceHub) : SingletonSerializeAsToken() {
    init {
        val config = HermesConfig.readFrom(path)
            .withFlow('makePayment', MyPaymentFlow::class.java)
            // ... and much more
            // ... e.g. pluggable authentication and authorisation
            // ... ports, interfaces
            // ... your own custom services 

        HermesServer.bootstrap(serviceHub)
    }
}

If this is something that interests you, your feedback would be very much appreciated.

Thanks,
Fuzz


(Yaakov Sash) #2

I love this proposal


(Fuzz) #3

Thanks! I’ll try to get an early version of the docs and examples out. Comments on features and shape of the API much appreciated.


(Yaakov Sash) #4

Looking forward! Are you planning on doing anything special to support Corda on the browser via Angular, React, Vue, and other Javascript frameworks?


(Fuzz) #5

Currently, the library is agnostic to the frameworks so it should integrate well with them.
Internally we use a combination of React, Angular and plain old HTML5+JS.
The library provides standard Promises (it works well with async-await) and RX-JS (for streams).
I think it would be easy to provide a thin shim for React etc. Perhaps that something we could collaborate on :slight_smile:


(Richard Green) #6

Looks very cool indeed. Is hermes an existing project - ie is this it ? https://www.npmjs.com/package/hermes-server - I need to ask as there is a fair bit of clashing in the npm library namespace…

I couldn’t find a lot of other documentation about hermes on the web - it may be my google-fu isn’t aligned today but the only java stuff I could find was in reference to a project that has gone 8+ years without a commit.

This would be a great contribution to the platform if I could ensure that we aren’t going to break it with future changes and that anything it exposes is secure. Obviously it exposes things service by service - I guess at this stage any users would be given the usual caveat emptor ?

Oh and I am personally interested in the python integration as well … I did implement API access via jython but although that was an interesting exercise, we didn’t receive much feedback about it so it may well be absent now… In fact… we didn’t receive any feedback regarding any other language access whatsoever - so it’s good that this has been received positively (ie - to me that demonstrates we have a larger audience now).


(Fuzz) #7

Thanks Richard.
Hermes is just a code-name for our project, served up from our internal npm repo.
It’s not open source yet.
Mike, James and I were chatting about alternative names. I have a session next week in R3 to demo it, if you’re interested. I’m not sure how we would want to open source it. We’re open to any suggestions.

Re stability: I have a battery of unit and integration tests for the project which should help it remain stable.
Re security model: it’s pluggable, partly because we have our own SSO services that would require integration. We think other organisations will want that flexibility to integrate their own. I think this is a big topic that we may discuss if you wish. Mike suggested connecting with Igor and Jose regarding this area.

Also, very interested to look at your Python implementation.


(Fuzz) #8

w.r.t Jython and other JVM based implementations for dynamic languages - we’ve taken a view that some (most?) folks would want to stay with their own VM. That convenience means the cost of extra programming effort in networking, transport protocols, and marshalling.


(Richard Green) #9

This was my original attempt:


(Fuzz) #10

Thanks. Yes, so running in the JVM makes it pretty straightforward to access the RPC API. The tricky concern being

  1. Some shops have an ops model and tools for specific runtimes - I can count one or two banks that have quite a bit of tooling around Python - these may not work in quite the expected way, when running with the JVM.
  2. There’s an additional dependency on the JVM on an existing server-side process that was originally written to work with Python. These may not work as before.
  3. Reduced availability of the JVM within the browser.

Having said that, both approaches have some common concerns.
For example, we were discussing how in Javascript, numbers outside the interval +/-2^52 need to have special representation (either an object with two 32bit ints or a string). This would be an issue irrespective of native runtimes or those based on the JVM.

“hermes-corda” handles these cases transparently, using libraries common to the client runtime (e.g. in the case of Javascript, it uses the long npm package).

I wonder if you saw any type mapping issues in Jython?