Pretty recently the team from Hyperledger Composer posted a relevant note for any software developer creating on top of Composer. Its content could be quite shocking for a lot people in the community, since the project has always proven to be so robust.
Basically what Simon outlines in the note, posted on August 30, 2018, is that even though a lot of efforts has been invested in the Composer project, they will mostly stop bringing new features to it. In synthesis the main reasons are regarding its growing architecture and the difficulties to maintain it. According to the note, they will focus more on bringing more features straight to Fabric (which is great for all of us!).
“The IBM team will continue to update Composer to maintain compatibility with the latest Fabric v1.x releases, and we will fix any high priority bugs — but certainly for the time being, we will not be looking at delivering any major new features into Composer.”
As a software developer getting into Hyperledger, you may find it overwhelming to hop in into the ecosystem. There are lots of things to learn and a tool like Composer made it really easier for all of us to create POCs for Hyperledger Fabric. Yet, like a lot of people, we also noticed a few downsides on their architecture. Having to chose between “native” Fabric or Composer really pushed us (and a lot of developers) to reduce dependencies and get into native Fabric when going into production, while using Composer only for proof of concepts.
Internally a few months ago, while creating our own development framework, we learnt a lot from Composer’s limitations and created Convector, a nimble smart contracts system framework, initially supporting Hyperledger Fabric.
A few weeks ago we made it open source. At WorldSibu we understand the needs of the developer community (since we are developers ourselves), and our desire to give back to the community made it clear to make the decision. You can read more about it here.
Our vision for Convector is similar to the one that the Composer project had, to support multiple blockchain technologies, but our approach is different, componentized by default.
Your options from now own
Hyperledger Fabric supports chaincodes (smart contracts) written in Go and Node.js. That has always been the option for people choosing to go “native” with Fabric. From our experience, developing in Go if you are not at an expert, can get out of control quickly, you end up creating a lot of helpers and validators to translate data, reusable functions that carry its respective cost of risks, and if you have the rest of your stack in another language, it gets really hard to integrate it (CI/CD/Testing).
If you choose to go with Node.js and you already know JavaScript (or similar languages in terms of syntax like Java, C#, C++) it gets way easier. But still, you have to fight a lot of the common downsides of a flexible technology like JavaScript, its so flexible that you can get it wrong really fast.
As I was telling before, we found ourselves creating native Fabric solutions and during the maturity of our development experience, we conceptualized and developed Convector. It may be helpful in case you decide to go with Node.js as your development language option. It embraces a Model/Controller pattern, making it easier to bring business concepts without adding extra layers to your code. It’s still your same code that runs in the blockchain. You still develop natively.
If you find yourself looking to create smart contract systems, Convector may support you on your development experience. Here are some links:
- Writing Smart Contracts using Convector — a Fullstack Typescript Framework
- Convector: Smart Contract Systems the easy
- Getting started with Convector
- Announcing: Convector, a JavaScript Framework for Smart Contract Systems
Its approach is to support a fullstack JavaScript solution, without adding extra components, what it does is to extend your code while bringing a ecosystem of tools like development environment setup and testing mocks.
A part of the note mentions that they could not get as much support of the community as they desired, and we also believe that community support (bug reports, enhancements, documentation) is key for Convector. We’d love to get support from the community to make Convector the standard in smart contract systems development. Our vision is for it to enable a Software Developer to create once, and deploy anywhere (any blockchain platform). To contribute here are some guidelines. You can also join the Discord Community for Convector here.
As a conclusion regarding their decision to stop advancing the development of Composer what we can say is that we think it is normal for things like that to happen, they got into the technology too early and took the burden to make the world easier for us all. They provided value at a time when getting into Blockchain was way harder than today.
Since the Hyperledger community is open, we would love that the Hyperledger Project can find our framework useful and decide to contribute to it. As well, we look forward for those new tools Simon says they plan to release to integrate them in the wider spectrum that Convector aims to cover.