grpc-web VS wasmws

A proxy is required to communicate from web clients to a server running gRPC, and there are only two choices for this proxy: a. The Improbable gRPC-Web client or b. The Google gRPC-Web client

I'll have to try the Improbable method (https://github.com/improbable-eng/grpc-web) - as it definitely includes a websocket transport, hopefully this multiplexes requests on that transport and would hence solve the problem. I'll post again once I know...

I think you should check out https://github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy

What I like with gRPC is that it allows both client and server side streaming. Twirp seems to not have this feature at all. In contrast the https://github.com/improbable-eng/grpc-web even supports server and client streaming while wrapping gRPC in a HTTP1.1 Web connection.

I highly recommend also to look into https://github.com/improbable-eng/grpc-web in contrast to the 'official' gRPC-web from google the improbable-eng Implementation can do both server side and client side gRPC streaming (when used with their JavaScript client library) and all this on an http1.1/websocket basis...

We use https://github.com/improbable-eng/grpc-web for the server part with https://github.com/protobufjs/protobuf.js on the frontend.

I'm debating whether or not to rely on grpc for all client to API transport using improbable-eng's grpc-web project. The hesitation I'm running into is concern over unforeseen pitfalls. The fact that it isn't widely used is the main cause for my apprehension.

If you use https://github.com/improbable-eng/grpc-web you do not need envoy, you can wrap your golang grpc connection. I then mux the grpc and grpc-web so that I can use the same endpoint to serve http1 and http2 clients. This makes it easy to host on the cloud, eg. google cloud run.

I'm setting up a server portion of a website which uses (g)RPC. My dev setup is a docker-compose.yml that starts up my server on 50051 & another service that runs grpcwebproxy (exposes 8080 and proxies to my server @ 50051).

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