gRpc and browsers?

[Gregg Donovan]

This may be a dumb question... is it possible to have a gRpc service that supported a browser client or would a gRpc client be required? The note that "DATA frame boundaries have no relation to Delimited-Message boundaries and implementations should make no assumptions about their alignment" makes me think the normal browser assumptions about HTTP/2 streams might not work.

Solr has been interested in both HTTP/2 and Netty, but much of the existing debugging, API, load-balancing, and caching infrastructure is built around browser-friendly URLs. Ideally, services on a single port could support JSON or XML output when called by a browser and protobuf output when called by a gRpc client. Would this be possible with gRpc? Would a separate Http2ConnectionHandler be needed to handle browser clients?

Thanks!

Gregg 

[Eric Anderson]

On Mon, Mar 30, 2015 at 2:55 PM, Gregg Donovan <greg...@gmail.com> wrote:

This may be a dumb question... is it possible to have a gRpc service that supported a browser client or would a gRpc client be required?

gRPC can't support browsers natively at this time because browsers generally don't support trailers in HTTP.

Solr has been interested in both HTTP/2 and Netty, but much of the existing debugging, API, load-balancing, and caching infrastructure is built around browser-friendly URLs. Ideally, services on a single port could support JSON or XML output when called by a browser and protobuf output when called by a gRpc client. Would this be possible with gRpc?

Such a thing is possible, but not with the current implementation (which I think you are aware due to your next question). Note that JSON/XML vs Protobuf isn't as much the issue as the gRPC protocol itself. gRPC itself is okay with JSON/XML (although we don't have anything to auto-choose the appropriate way to demarshal).

 

Would a separate Http2ConnectionHandler be needed to handle browser clients?

Yes and no. The HTTP/2 stuff in Netty is very monolithic and doesn't support any sort of swapping of handlers on a per-request basis. So while some sort of handler is needed, there isn't any way to make use of it.

I've been planning a design for HTTP/2 in Netty that would allow for such things, but it would be a good while yet before I'm able to start coding it/championing the design.

After such a thing was developed, there is still the issue of what API to expose to applications. We could require applications to write a Netty Handler, but from what I've seen that seems overly burdensome. Maybe we would instead allow plugging gRPC's handler into an existing Netty server... And there is the cross-language aspect; we would be hesitant (but still open) to do such a thing in Java if C/Go wouldn't want to do something similar (which can easily be the case, because then it is a generic HTTP/2 server).

All that is to say, this is a medium-to-long-term goal at best. We are trying to figure out the browser story, but are still organizing ourselves around solutions.

[Louis Ryan]

Gregg,

The primary issue we have with implementing a browser-client that works with GRPC is that browsers don't provide an API to access HTTP trailers yet. The proposed Fetch API should help to address that so we'll look at providing a binding for that when it's ready. 

The note in the spec about DATA frame boundaries is not an issue here for browsers, it's there to allow the data stream to be carried over different framing protocols in the future and is compatible with HTTP/1.1 in this regard.

Sharing a port with a REST+JSON exposure of the same underlying service is supported, we explicitly require 'Content-Type: application/grpc' to allow servers to disambiguate REST vs GRPC for these types of scenarios.

[Jayant Kolhe]

There is more discussion in #159 and fetch issue #34. Adding those to issues to this post. Let keep the discussions in those two issues.

[Gregg Donovan]

Thanks for the replies! I can see how the missing trailer support would be relevant for full browser-hosted JavaScript gRPC client. 

How about debugging a gRpc service via typing URLs into the browser's URL bar or curl-ing a gRpc endpoint from the command line? Would the missing trailer support prevent seeing proper output?

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/8t4lXbgEPOU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6df0c9ea-a611-4d8b-bdab-8aa1dc68f0dc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Louis Ryan]

curl works fine with grpc though you need to get a version of curl that supports HTTP2 (or build it yourself). We'd like to provide a simple command line tool for doing curl like things too.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAC%3DTrKAf4uvYmcDd8A1F98V-peejQ4y46tJ7G4rPSd%3D9hkqo6g%40mail.gmail.com.

[byz...@gmail.com]

Can you provide an example on how to use curl to access the gRpc service, e.g. the helloworld in grpc-common?