You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gRPC-web support for GWT/J2CL projects - starts with the basic gRPC APIs and stubs, and provides both replacements for
4
+
those jars, plus gRPC/gRPC-web Channel implementations.
5
+
6
+
Generated from the Java projects for grpc-api, grpc-stub, grpc-protobuf, and grpc-protobuf-lite. Makes use of standard
7
+
OpenRewrite rules and some rules specifically written to
8
+
[simplify projects for GWT](https://github.com/vertispan/gwt-compatible-recipes/).
9
+
10
+
A future version might split these dependencies into separate jars, but for now a subset of the original classes from
11
+
all four are included in a single jar.
12
+
13
+
## Implementation differences
14
+
To simplify the effort of transforming the implementation, two features have been removed. Both technically could be
15
+
restored, but at a glance there doesn't seem to be an obvious need.
16
+
17
+
At present, there is no ASCII charset in GWT, so it is assumed that the server is correctly sending ascii status and
18
+
metadata values. All valid ascii (e.g. below 128) are equal to their corresponding utf8 value, so there should be no
19
+
difference in behavior.
20
+
21
+
BinaryStreamMarshaller has also been effectively removed, along with the `Metadata.Key.of()` overload that supports it.
22
+
The current implementation used Class.isInstance to check which marshaller was in use, though if required this could be
23
+
reimplemented without any reflection at all.
24
+
25
+
## Browser limitations
26
+
gRPC is marketed as a "universal" RPC framework that runs in "any environment", but in practice it is entirely unusable
27
+
in browsers. Instead, gRPC-web offers a few small changes over gRPC to make it mostly compatible with browsers:
28
+
- http/1.1 is supported instead of just h2. In most browsers this limits the number of concurrent streams (usually
29
+
6) to a single server, so h2 is still desired for most use cases.
30
+
- Additionally, browsers do not support h2c (h2 over cleartext), so gRPC-web over h2 is limited to TLS connections.
31
+
This can make localhost or dev/staging deployments difficult to use.
32
+
- Rather than HTTP trailers, a final body payload can be read as if it were an http/1 headers block. This doesn't apply
33
+
to trailers-only responses
34
+
- The `user-agent` header cannot be controlled by clients in a browser runtime, so `x-user-agent` should be used
35
+
instead.
36
+
- Since all of this adds up to "not actually gRPC", the `content-type` header should be prefixed with
37
+
`application/grpc-web` or `application/grpc-web-text`.
38
+
39
+
These limitations are intended to "make it easy for a proxy to translate between the protocols as this is the most
40
+
likely deployment model." Unfortunately, they only cover a subset of the limitations that browsers impose, so it isn't
41
+
actually possible to run a proxy which can translate arbitrary gRPC services. The browser's `fetch()` implementation
42
+
does not support any client-streaming use cases, which limits clients from participating in either bidirectional
43
+
streaming or client streaming RPCs. At the time the spec was written it was believed that [by 2019 this would be resolved](https://github.com/grpc/grpc/commit/4daba4b6ba9717f7ffdde725043bac7e8fd90d28#diff-5f77fa0e0ca74be75527c69b5e918d30f02999e2285c8bd4787464effea8ed5dR29-R32),
44
+
and was [later revised](https://github.com/grpc/grpc/commit/f5809cced8c1161645f964c8b011c9e54e6ae075) (still with a
45
+
two-year estimate) to instead be part of the streams spec. While Chrome does now technically support streaming uploads,
46
+
it is required that this be done in "half duplex" mode, which still prevents bidirectional streams from being useful.
0 commit comments