Porting grpcwebproxy to native Node.js

[CMCDragonkai]

Nice library, we have been building our own abstractions on top of gRPC as well, but it looks like you've figured out most of the complicated details.

One thing though is the grpcwebproxy. It's still running in go. What are your thoughts on porting https://github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy this directly to JS/Node.js so that way it can run natively in a single NodeJS application? I was considering doing this early on especially with respect to the WS transport so I could have browsers directly call the GRPC server.

[aikoven]

It would be nice to have a pure JS port of grpcwebproxy, especially because it is not actively maintained and I had to do some patching to it in my fork to make it work right in all of the edge cases.

There's one concern though: grpcwebproxy serves both gRPC and gRPC-Web protocols on a single endpoint, so you can expose it and target from both the Browser and non-browser clients. It would be harder to do with NodeJS because I don't think that grpc-js allows you to control the http2 server and attach custom handlers to it. I'm not even sure that NodeJS allows you to have an http1 + http2 server, as Go does.

That said, there's still an option to make the port act as a proxy server, that forwards traffic to the gRPC server running in the same process.

Also, I'd like to note that we recommend using Envoy proxy (if you're fine with not having client streaming) because it seems to work much better than grpcwebproxy. See packages/nice-grpc-web#preparing-the-server

[CMCDragonkai]

We actually monkey patched the grpc-js to have access to the http2 instance in order to manipulate it. So in TS the http2 is not part of the same interface, but runtime JS still has the property. I wonder if both http and http2 are on the same port, a demuxer would be needed to split the protocols.

On 19 October 2021 2:43:52 pm AEDT, Daniel Lytkin ***@***.***> wrote: It would be nice to have a pure JS port of `grpcwebproxy`, especially because it is not actively maintained and I had to do some patching to it in my [fork](https://github.com/aikoven/grpc-web) to make it work right in all of the edge cases. There's one concern though: `grpcwebproxy` serves both gRPC and gRPC-Web protocols on a single endpoint, so you can expose it and target from both the Browser and non-browser clients. It would be harder to do with NodeJS because I don't think that `grpc-js` allows you to control the http2 server and attach custom handlers to it. I'm not even sure that NodeJS allows you to have an http1 + http2 server, as Go does. That said, there's still an option to make the port act as a proxy server, that forwards traffic to the gRPC server running in the same process. Also, I'd like to note that we recommend using Envoy proxy (if you're fine with not having client streaming) because it seems to work much better than `grpcwebproxy`. See [packages/nice-grpc-web#preparing-the-server](https://github.com/deeplay-io/nice-grpc/tree/master/packages/nice-grpc-web#preparing-the-server) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #25 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[VVvKamper]

I wonder if both http and http2 are on the same port, a demuxer would be needed to split the protocols.

You'll need TLS for this (through the ALPN). With the plaintext it's impossible as far as i know.

[CMCDragonkai]

This seems to be possible with Node's TLS:

ALPNProtocols: <string[]> | <Buffer[]> | <TypedArray[]> | <DataView[]> | | | An array of strings, Buffers or TypedArrays or DataViews, or a single Buffer or TypedArray or DataView containing the supported ALPN protocols. Buffers should have the format [len][name][len][name]... e.g. '\x08http/1.1\x08http/1.0', where the len byte is the length of the next protocol name. Passing an array is usually much simpler, e.g. ['http/1.1', 'http/1.0']. Protocols earlier in the list have higher preference than those later.

https://nodejs.org/api/tls.html#tlsconnectoptions-callback

So the expectation is that connecting clients will have this property and we would use this to select whether HTTP 1.1 for browsers or HTTP2 for non-browsers? Assuming they are using grpc web, would that mean they are always using HTTP 1.1, or are there possibilities that browsers will eventually use HTTP2? And if that's the case, then at some point grpcwebproxy shouldn't be needed right?

[aikoven]

Browsers are actually able to use HTTP2, but there's no control over it from the JS code. So I guess that browsers already use HTTP2 when the server supports it, but the gRPC protocol implementation requires access to low-level API of HTTP2 framing, which the web standards currently lack.

See https://grpc.io/blog/state-of-grpc-web/

[CMCDragonkai]

Cool thanks, we stopped using GRPC due to various issues like this and moved to our own transport agnostic RPC system.