Please describe your proposed solution.
Context
- Marlowe is a brand new language and runtime for developing financial smart contracts.
- Marlowe contracts are built by combining a small number of building blocks that describe making a payment, waiting for a certain condition and other similar types of concepts.
- The Marlowe Runtime is the backend component of the Marlowe framework that handles interaction with the blockchain. It exposes a REST API that provides operations such as: get-contracts, create-contracts, etc.
- To interact with the backend, developers need to manually craft the REST API Requests, which involves a lot of boilerplate code with little specific value to their particular use-case.
Technical Plan
We’ll build a set of idiomatic SDKs (software development kits) in common programming languages with the goal of reducing the boilerplate required to interact with the Marlowe Runtime API.
The selected languages are:
- Rust
- Go
- Python
- Javascript (Typescript)
- .NET (written in C#)
The rationale for selecting the above languages is the following: they are the subset of popular languages in the Cardano ecosystem that overlap with the technical expertise of our team. Meaning, these are the languages we know how to implement and that we believe will provide value in the ecosystem.
Each SDK will present the following features:
- All data structures defined by they core Marlowe spec will have their types represented as part of the SDK. We'll explore how to abstract this types into it's module for potential reutilization in other contexts.
- For the Marlowe Runtime operations, each API methods will be represented as callable functions, making use of whatever asynchronous IO mechanic is provided by the language. This is will also be abstracted into its own module to decouple it from the core types (previous bullet)
- Naming of structures and functions will respect the naming conventions of the corresponding language (eg: use camelCase for Javascript and snake_case for Python).
- Client-side validations will be executed by the SDK to avoid errors due to invalid requests.
- Appropriate logging will be added in relevant functions to facilitate debugging.
- Code-generation from the OpenAPI spec will be leveraged whenever possible to streamline SDK updates on future changes of the API.
- DocStrings will be available whenever possible to improve integration with IDEs and documentation sites.
- Public packages will be published to the corresponding package manager of the language, if any (eg: NPM package, Crates.io package, PyPi package).
There's an existing effort for a Typescript SDK being done by IOHK. Our plan is to reach to the specific devs behind the project and seek a plan for integrating both projects into a unified effort that covers all of the languages mentioned.
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Our proposal accelerates the development of dApps that integrate with the Marlowe framework by removing much of the boilerplate required to interact with the backend API.
How do you intend to measure the success of your project?
We’ll measure the success of the project by level of engagement and usage of our new integration mechanism:
- Common activity metrics in the open-source Github repository, such as: number of issues, contributors, traffic, etc;
- Package manager activity metrics, such as downloads per unit of time.
- Level of engagement from developers through TxPipe existing communication channels, such as: our Discord server, our Twitter announcements and tech support ticketing system.
Please describe your plans to share the outputs and results of your project?
Being an open-source project, the outputs will be available to any developer in the ecosystem at every step of the development process:
- Latest version of the source-code will be available in the Github repository.
- Source code changes will be applied through a pull-request process.
- Alpha and Beta versions will be released at every milestone.
Upon reaching the end of the development process, we’ll provide:
- Links to the latest published versions of the SDKs in their corresponding package managers.
- A documentation website with instructions for usage and deployment
- A collection of examples showcasing the usage of the SDKs
- A tutorial video showing a walkthrough of how to use some of the SDKs
After a reasonable (1-3 months) period after the end of development, we’ll provide:
- A report describing package manager activity
- A report describing dev community engagement with the project