# Multi Client Ecosystem Support

## Description

Determine:

* How will the development process for a new client look like
* How will the maintenance of multiple clients look like
* How will we track the supported and unsupported features across clients, and their versioning
* Creation of a roadmap of clients to have in the future
* What is the MVP for a Polywrap client

### What do we currently have?

Currently we have a Javascript client. However, there is no full client standard yet, and this might be necessary to fully implement a Polywrap client in a different language.

### Why is this a current priority?

Portability is one of Polywrap's huge selling points. Having other clients, and therefore, enabling developers across different platforms to perform an integration without having to rewrite it in each platform's language would be an early proof of Polywrap's concept.

We have no way of performing end-to-end testing without a Javascript setup. This issue becomes more evident as we start to support different wrapper implementation languages, like Rust. This could, however, be solved/mitigated with a more solid testing infrastructure.

We're already reaching the Rust developer ecosystem by enabling them to build wrappers in Rust, but they cannot consume them from Rust.

## Discussion points

### Which client should be next?

As per the last PWV report, the two most popular languages in the Web3 ecosystem (excluding Javascript) are Python and Rust. So, with adoption in mind, these two options are the most logical next possible client implementations.

While Python is the [second most popular language in general](
https://octoverse.github.com/#top-languages-over-the-years), having a Rust client first, might be better.

Rust allows, easily, the creation of native libraries that can be imported and used in other languages like Kotlin, C++, and even Python.

In the particular case of Python, it's possible to import a Rust native library to Python using PyO3, and after [some quick research](https://marshalshi.medium.com/performance-comparison-rust-vs-pyo3-vs-python-6480709be8d), it seems that the imported Rust libraries are considerably more performant than regular python code.

So it makes sense to consider/explore the possibility of implementing (maybe just partially) the client's core in Rust, and then export it as native libs, easing the development of clients in other languages like Python; even having performance gains in some cases.

### Repository organization

TODO

### Feature support matrixes and versioning

TODO

| | Standard feature #1 | Standard feature #1 |
| ----------- | ----------- | ----------- |
| Javascript | ✅ | ✅ |
| Python | ✅ | ❌ |
| Rust | ✅ | ❌ |