evans VS wasmws

Note: gRPC services can also be tested from CLI using tools like evans-cli. But for that reflection needs (if not enabled the path to the proto file is required) to be enabled in gRPC servers. This compare link shows the way to enable reflection and how to enter into evans-cli repl mode. Post entering repl mode of evans-cli, gRPC services can be tested from CLI itself and the process is described in evans-cli GitHub page.

Do you mean this one https://github.com/ktr0731/evans ?

I use Evans, it supports gRPC and gRPC-web and also supports reflection protocol.

https://github.com/ktr0731/evans it's the best cli tool I've ever used

Over the holidays, 2021, Postman gifted a fine upgrade to its users: beta support for the gRPC protocol in its API platform. As a Product Manager for Lightbend and helping out on its new gRPC native PaaS for building and running APIs and microservices, I was excited, to say the least. In another, recent blog post, I mentioned my desire to leverage UI test-and-try tools for APIs (my time in the REST API world of Mashery and PubNub was the source of such desire). In that same post though, I noted the lack of several important gRPC features, like server reflection and more robust import capabilities, as blockers; hence, my deep dive, in that post, into the CLI tool, Evans.

And who am I kidding? I'm a CLI-type person. Which is why I was super excited to stumble about Evans. Within minutes, I had gone from installation to trying out TLS-secured APIs and microservices running in the cloud on Lightbend's new serverless offering.

If everything is set up correctly, you should now be able to use evans to access your web server at the load balancer url or even the url for your ec2 instance directly e.g.

After running the server with cargo run, I needed a way to test that the server works. I had heard of an interesting tool called evans, so I decided to use this. It took me a while to figure out the right parameters to query the server, especially because tonic doesn't seem to support gRPC reflection right now, and there are few examples out there.

For testing gRPC we can use evans and need add reflection:

Thanks for writing this! I found it really great to use when I wrote https://github.com/tarndt/wasmws

Before looking at the readme, I thought this was an alternative to using https://github.com/tarndt/wasmws which lets you use gRPC over websockets so that you can use gPRC via WASM without needing an http to gRPC gateway. Now I'm understanding a bit differently. It looks like this uses protobufs but doesn't have anything to do with gRPC at all, instead implementing some of the communication parts of gRPC while ignoring the generation of services but instead focusing a bit more on message routing and pub/sub that you would probably still need NATS.io for if you were using gRPC.

The hijacking a websocket works very well, live in the future today! https://github.com/tarndt/wasmws

Everything said above is valid, but if you do think you have a need to transpile... consider running any Go frontend code as WASM rather than Javascript. A few years ago I started doing my frontends and backends all in Go and its been wonderful. I even wrote a library so I could use gRPC from my WASM/Go frontends rather than REST: https://github.com/tarndt/wasmws . Extra wonderful, at least for my tastes. Once caveat is if your brotli compressed, CDN/browser cached, etagged Go WASM is still to big, you can usually make it even smaller by using tinygo rather than the std tool chain for the compiling to WASM.

A while back I was writing a pure Go frontend app (WASM) and I wrote this so I could use gRPC rather than REST to talk to my backend: https://github.com/tarndt/wasmws