Getting gRPC to work from a web browser.

[jhump]

Relevant discussion on mailing list: https://groups.google.com/d/topic/grpc-io/5Ic8MKgltwY/discussion

[acasajus]

It's probably already tought of/discarded, but why not use websockets as the connection and send/receive http2 frames over it?

Clearly it won't be as efficient but it may work...

[louiscryan]

Could certainly do that though it would increase the complexity in the browser significantly as we'd have to provide the HTTP2 framing layer which most browsers already have.

If we sat on top of XHR/WHATWG Fetch we don't get to interact with flow-control which is a double-edged sword

[acasajus]

What do you mean? How does the XHR/WHATWG Fetch relate to http2? Will all the request be internally translated to http1 reqs or http2 streams?

[louiscryan]

Fetch will provide an API for HTTP semantics on top of http/1.1 or http/2 depending on what the browser was able to negotiate with the host as the transport. Given that http/2 allows for full-duplex the API needs to be able to express that even if the transport it's bound to does not.

[louiscryan]

FYI

whatwg/fetch#34

[vvakame]

I have a question.
Does gRPC can support for http2 fully implemented browser?

[sulliwane]

same question
Does gRPC can support for http2 fully implemented browser with javascript?

[louiscryan]

Seems like Fetch may support trailers so there is hope we can support in a Fetch-capable browser without protocol modification. Timelines are still an issue

whatwg/fetch#34 (comment)

[pdf]

@nicolasnoble can you please detail why/how this was closed?

[nicolasnoble]

I actually don't mind keeping that one open. All the other issues and pull requests in this repository were stale and outdated since we killed it, and I just mass-closed it since all the others were relocated in appropriate locations. But there's no good location for that one, and that's in fact appropriate for what we want to do here.

[nicolasnoble]

So, in fact, let's try to get the discussion going. I have heard of different ways and suggestions for getting gRPC to work from a browser. Anyone wants to share?

[pdf]

Thanks @nicolasnoble the ideal is obviously for browsers/fetch to support trailers properly, just wanted to maintain tracking here.

[nicolasnoble]

Yes, that may be ideal, but maybe we can also do a few other things to workaround this, if for a diminished version of gRPC that is doing unary calls only for example.

[nemequ]

Thanks @nicolasnoble the ideal is obviously for browsers/fetch to support trailers properly, just wanted to maintain tracking here.

AFAICT, the Fetch API has supported trailers for about a month, so the issue is getting browsers to implement the new functionality.

Yes, that may be ideal, but maybe we can also do a few other things to workaround this, if for a diminished version of gRPC that is doing unary calls only for example.

Why not just use grpc-gateway? It can output a Swagger definition which you should be able to use to generate stubs for many languages. I haven't played with it yet, but AFAICT it supports server streaming, which seems like the hard part…

Given how closely gRPC is tied to HTTP/2, and assuming unary-only is insufficient (it certainly is for me, otherwise I'd just use REST with protobuf payloads), I only see two options for true gRPC:

• Wait for browser vendors to implement the relevant portions of the Fetch API. For some of us, requiring a recent version of a specific browser is feasible, so if Chrome or Firefox implements it quickly this could work. For people who have to work with whatever ancient browsers people have installed, this probably isn't a very attractive option.
• Shove HTTP/2 over a WebSocket, and gRPC on top of that. For JavaScript this may require a HTTP/2 client library (maybe someone has created an implementation for Node.js or something). For Dart, there is already an HTTP/2 library, so it may actually be pretty straightforward (though a bit bloated).

Anything else wouldn't really be gRPC, it would be (at best) something which maps well to gRPC. At that point, I don't see a reason not to just use grpc-gateway, though it would be great to have grpc-gateway integrated into the gRPC server instead of proxying requests to it.

[louiscryan]

I must admit I get nauseous at the idea of using WebSockets but layering a basic H2 implementation over it and wrapping that up in the Fetch API might present a reasonable path forward.

I would NOT want to put termination for that protocol into every GRPC runtime, I would look to put it into a proxy that could de-awful it.

I haven't looked at the Dart library but I have looked at molnarg's for Node though I think that's getting swapped out with nghttp2 as we speak.

I believe there is already some polyfill for the Fetch API over XHR that could be used to deliver unary & half-duplex streaming though we would still need to address the trailer issue. That seems fairly tractable as there is flag-space in GRPC framing that we could use to indicate a trailers-in-payload model. I've done a prototype for this and it's not overly onerous in the runtimes.

[nemequ]

After I wrote my last comment I also came across prpc, which may be interesting for people coming across this issue… it doesn't seem to be nearly as polished as grpc-gateway, can't generate a Swagger definition, and it's unary-only, but it works even in App Engine's very limited standard environment.

I must admit I get nauseous at the idea of using WebSockets but layering a basic H2 implementation over it and wrapping that up in the Fetch API might present a reasonable path forward.

I would NOT want to put termination for that protocol into every GRPC runtime, I would look to put it into a proxy that could de-awful it.

Agreed. Pushing the existing gRPC protocol over HTTP/2 over WebSocket over HTTP/1.1 is definitely a very ugly hack, but the advantage is it doesn't require any modifications to the existing gRPC protocol. It's still "real" gRPC, just over a slightly odd stack (though obviously less strange than some). I think the bigger problem is that it would require an HTTP/2 implementation in (or transpiled to) JavaScript, which is probably a rather large amount of code.

I believe there is already some polyfill for the Fetch API over XHR that could be used to deliver unary & half-duplex streaming though we would still need to address the trailer issue. That seems fairly tractable as there is flag-space in GRPC framing that we could use to indicate a trailers-in-payload model. I've done a prototype for this and it's not overly onerous in the runtimes.

Now I'm a bit unclear about the constraints on this issue. Are we talking about (1) how to get gRPC as-is working in browsers, (2) how to modify gRPC so it would work in modern browsers, or (3) developing something gRPC-like which would work with HTTP/1.1? I thought this was about (1), but wouldn't what you just suggested be (2)? If it would be possible to extend gRPC slightly to allow it to work in current browsers that sounds great, I just didn't realize it was an option.

[marcelocantos]

Given that this is a (somewhat) temporary problem until browsers catch up, an HTTP/1.1 gRPC proxy using WebSockets would be more straightforward and might therefore be preferable to the extra complexity of HTTP/2 emulation.

The gRPC library could fall back to the HTTP/1.1 protocol on old UAs or you could use server-side browser detection to deliver an alternate library. This would be trivially easy if the UA connects using HTTP/2, and would be very light on the client.

A proxy could also optionally do JSON ⇔ Protobuf transcoding, using feature-detection on the client to decide this transparently.

[nemequ]

I think you're confusing "Getting gRPC to work from a web browser" with "Getting gRPC to work from HTTP/1.1". HTTP/2 has fairly good browser support, the real issue (IMHO) is that the changes to the Fetch API to support trailers are, as far as I can tell, not available in any current browser.

If there is a way to get gRPC working with current Fetch API implementations I'd be happy. Based on what @louiscryan mentioned about the possibility of trailers-in-payload, it seems like that's quite possible with only relatively minor changes on the server side.

A proxy could also optionally do JSON ⇔ Protobuf transcoding, using feature-detection on the client to decide this transparently.

Please no. Several reasons this would be terrible come to mind:

• One of the major reasons I like gRPC is protobuf. Schemas are extremely helpful, especially for languages which are less strongly typed than JavaScript (Dart, TypeScript, etc., as well as lots of languages compiled by emscripten).
• This would mean a very different code path for clients which use HTTP/2 and HTTP/1.1 if they opt-in to the JSON version, which would likely hold people back from upgrading when HTTP/2 becomes available to them (since the server would no longer do the transcoding for them).
• It would require a lot of extra processing on the server side. If a client really wants JSON they can transcode to/from protobuf on the client side and distribute that (relatively) expensive computation.
• Supporting it would still significantly increase the complexity of a server implementation.

I'd greatly prefer a faster, leaner server. For most applications I think it makes a lot more sense to do more work on the client, basically distributing the workload instead of centralizing it on the server. The only time that may not be true is when client-side code is performance-critical, and using JSON instead of protobuf for such code probably isn't a great idea (though we are probably comparing native JSON decoding with JS-based protobuf decoding, so maybe it is).

[marcelocantos]

You're right, I did confuse the issue, since the other suggestions were around sitting HTTP/2 on top of HTTP/1.1. However, my suggestion remains valid, I think: Instead of emulating HTTP/2, provide an alternate gRPC client library that uses WebSockets as is.

Regarding JSON, I wasn't suggesting a different API, but a way to support the same API on older browsers that don't handle binary wire formats well. If you don't care about such old browsers, then this is moot.

[paralin]

I'm commencing work on a package that will allow clients to call GRPC services from the browser using a Node.JS server as a proxy. So, the client forms a two-way connection to the node server, and then can perform calls through that server as if they were local using a similar api to the GRPC node.js package.

https://github.com./paralin/grpc-bus

[WhileLoop]

Has anyone tried using the grpc bridge functionality from Envoy?

"This is a simple filter which enables the bridging of an HTTP/1.1 client which does not support response trailers to a compliant gRPC server."

https://lyft.github.io/envoy/docs/configuration/http_filters/grpc_http1_bridge_filter.html

[louiscryan]

For those folks not on the community call today there was a demo of using
GRPC from the browser. Everything is a rough prototype right now but you
should expect to see a formal proposal for a 'grpc-web' protocol from the
authors by the end of November at the latest.

On Thu, Oct 20, 2016 at 12:30 PM, Argishti Rostamian <
[email protected]> wrote:

Has anyone tried using the grpc bridge functionality from Envoy?

"This is a simple filter which enables the bridging of an HTTP/1.1 client
which does not support response trailers to a compliant gRPC server."

https://lyft.github.io/envoy/docs/configuration/http_
filters/grpc_http1_bridge_filter.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com./notifications/unsubscribe-auth/AIoKPIrX9zrDoGyBUKPZ3nLKXAKlB7Ouks5q18FLgaJpZM4DvZro
.

[louiscryan]

Folks please rview

grpc/grpc#8682

[tbillington]

What is the status of this? It seems like there is an implementation here: https://github.com./improbable-eng/grpc-web.

[thughes]

@wenbozhu Can I get an invite?

[jylin]

@wenbozhu I'd be interested in an invite as well.

[manifest]

@wenbozhu I'm interested in an invite too.

[millisecond]

@wenbozhu would love an invite too.

[acasajus]

I'd like one also if possible. El 13 ago. 2017 20:23, "millisecond" <[email protected]> escribió:

…

@wenbozhu <https://github.com./wenbozhu> would love an invite too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#159 (comment)>, or mute the thread <https://github.com./notifications/unsubscribe-auth/AAohL9eP5EgyCbGMi_J2JgsJNKpu76uQks5sXz8JgaJpZM4DvZro> .

[ghost]

@wenbozhu hi thanks, but I didn't really see the invitation. Could you send it again? Thanks

[emmaly]

Many folks are going to want invitations. Is there a chance it could be made public instead? I certainly want to use it, even if in pre-beta stage.

[Nyarum]

@wenbozhu hey, can you send invite to me too? It very interesting project I think and I'd love to help.

[drather19]

@wenbozhu would like an invite as well, thanks!

[hallum]

@wenbozhu Can I get an invite?

[travisjeffery]

@wenbozhu I'd like an invite as well. We'd use it heavily and deploy it if there's no major problems.

[MathieuLorber]

@wenbozhu same for me, I didn't want to notify everybody but it seems attempts to be noticed didn't work ;)

Could you please provide a way to access to the beta here, or juste say it's not possible =) ? So we can all stop to receive pointless notifications.

[bobbyrullo]

@wenbozhu same here please! (everyone else, sorry to get you excited with another pointless invitation :) )

[weitzj]

See https://docs.google.com/forms/u/0/d/15iRDHoP-VBenc4hWgKn7bk7IirJLgs0uh88nw1vi_Hc

[variantf]

@wenbozhu Could you invite me as well? Thank you!!!!!

[tommling]

@wenbozhu ^^^ Ditto ^^^
Interested in that invite and happy to contribute!

[glerchundi]

@wenbozhu Interested in an invite too! Thanks in advance!

[ansarizafar]

@wenbozhu I'm interested in an invite too.

[agonopol]

Could I get invite to grpc-web as well?

[mvuksano]

@wenbozhu would it be possible for me to get an invite too?

[jschoedt]

It looks like people are not taking the time to read through the post :-(
Because you can sign up here: https://docs.google.com/forms/u/0/d/15iRDHoP-VBenc4hWgKn7bk7IirJLgs0uh88nw1vi_Hc

@weitzj Could you give some indication of a time frame?

[shanshanzhu]

How is this different from https://github.com./improbable-eng/grpc-web ?

[marpaia]

@wenbozhu could I get an invite as well please?

[ericbets]

This might be helpful to you folks. https://github.com./ericbets/danby

[sgon00]

@wenbozhu could I get an invite as well please?

[matthijskooijman]

I believe the beta is now open and published at https://github.com./grpc/grpc-web (not 100% sure it refers to the same code, but I suspect so. Perhaps @wenbozhu can confirm?).

[wenbozhu]

@matthijskooijman

Yes.

Please have all future discussion on https://github.com./grpc/grpc-web