WASM incompatibilities GRPC (crw-client package)

[leobragaz]

Since this project is intended to be WASM-compilable I'm opening this issue to track down and clarify why currently it's not.
By design, the environment of WASM is completely isolated (or sandboxed) from the native functionality of the underlying host system.
This means that by default, WASM is designed to perform nothing more than pure computation.
Consequently, access to "OS"-level resources such as file descriptors, network sockets, the system clock, and random numbers is not normally possible from it.
Due to this, the crw-client package is not actually buildable to WASM, but I found a patch that let me compile it for WASM. It needs some more work because I need to update the adapt the patch to the latest version of the library where it's applied.

I'm not sure if this patch approach is the best one in the long term.
Probably it will make difficult to maintain the library unless those patches are merged to the libraries that I linked above.

Another approach could be wasmer which is the same library that cosmWASM use.
I'll study it and how it works and see if it's a better option than patches' Tetris.

[leobragaz]

[UPDATE 1]:
I've forked both of the provided patches, updated them to the latest versions of their upstreams libraries but it still didn't compile.
I've made some more research and found out it could be a problem of the tokio library.
There's an open issue which contains an answer that explains how to compile Tokio successfully to WASM but it did not solve the problem either.
Running cargo tree I have seen that the problem is inside hyper library. A tonic dependency.

[leobragaz]

[UPDATE 2]:
I thought that this PR would have solved our problems in the near future but it won't. As you can see from the comment to my question from the PR's creator.

So after this I've made some other researches and found out that this should be the things that should be done in order to let the client (and the wallet consequently) build to WASM.

1. Write a client that can implement GrpcService
   Done here: https://github.com/bragaz/webtonic/tree/expose-client
2. Use http-body to abstract what an http body must do.
   Wrap this and map a "HTTP/2" request into a "HTTP/1.1" by consuming the body and updating the headers.

All references here: hyperium/tonic#31

[leobragaz]

In this there's a guy who made a grpc-web client generator from proto files.
I'm trying with it now.

[leobragaz]

https://github.com/elliptic-email/rust-grpc-web

[leobragaz]

This worked. I was able to generate buildable WASM code for crw-client.
Now I'll open a PR and perform some tests to be sure this is working fine.

[leobragaz]

@manu0466 The tonic team has implemented the support for grpc-web, now they're able to introduce a fully compatible WASM-client that will give us the chance to send GRPC-web requests.
hyperium/tonic#645

[shravanshetty1]

Tendermint has an api - https://docs.tendermint.com/master/rpc/#/Tx/broadcast_tx_commit. Which takes signed proto transaction encoded in hex as an arguement and broadcasts it. Using this instead of grpc will make it completely cross platform.

Since grpc is an optional feature in cosmos-sdk-proto, we can disable it and directly send it to the tendermint endpoint. This should allow us to build for wasm.

Will be building this feature out on a fork, I can create a PR in main when its ready?

[manu0466]

Hi @shravanshetty1! Thanks for pointing this out but the doccumentation says also that the broadcast_tx_commit API should not be used in production. That said, I prefer that are used only stable API in production to prevent strange behavoirs and future refactoring if the API is removed.

[shravanshetty1]

Hi @shravanshetty1! Thanks for pointing this out but the doccumentation says also that the broadcast_tx_commit API should not be used in production. That said, I prefer that are used only stable API in production to prevent strange behavoirs and future refactoring if the API is removed.

Of course will implement all 3 broadcast api's(sync, async, commit), its upto the user on which api he would like to use

[manu0466]

I have talked with one of my collegues and we prefer to use the gRPC instead of the tendermint REST API.
This because the gRPC server in the cosmos sdk is right now the prefered method of comunication and the one that is more manteined.
btw it's seam that there is already an implementation of a gRPC client that works on the browser take a look at hyperium/tonic#645.
I think can be intresing tring to use that and see if actualy works.

[noandrea]

I am also looking into using gRPC client for a cosmos node https://github.com/noandrea/cosmos-cash-credentials/tree/feat/grpc
but so far I haven't manage also using the https://github.com/titanous/grpc-web-client prototype.

[shravanshetty1]

I have talked with one of my collegues and we prefer to use the gRPC instead of the tendermint REST API.
This because the gRPC server in the cosmos sdk is right now the prefered method of comunication and the one that is more manteined.
btw it's seam that there is already an implementation of a gRPC client that works on the browser take a look at hyperium/tonic#645.
I think can be intresing tring to use that and see if actualy works.

I agree grpc would definitely be better

I tried to use https://github.com/titanous/grpc-web-client but it wont work because according to cargo tree command says cosmos-sdk-proto crate is importing socket2 and mio crates which are not wasm compatible. Using cargo tree in the grpc-web-client repo shows that the generated code does not have socket2 or mio dependencies.

Not sure why the dependencies of generated files from tonic are different in these crates.
I am very new to rust, so i think someone else should be able to figure it out who has more exp.

[noandrea]

Here a working implementation for grpc client for a cosmos-sdk based project. Hope it helps
https://github.com/noandrea/cosmos-cash-credentials/tree/feat/grpc