Example for use with protocol buffers

[sgammon]

Is your feature request related to a problem? Please describe.
We use Protobuf objects extensively in our stack, including protobuf-js objects. We're wondering what the best way would be to plugin with protobuf-js, from J2CL.

Describe the solution you'd like
An example, perhaps in the JS Interop Cookbook, of how one would go about using protobuf objects in J2CL effectively.

Describe alternatives you've considered

1. We've thought about using the Java proto objects, but we have no idea if those will convert properly, or be as tightly optimized as protobuf-js is.

2. Otherwise, we could write bindings to call into the protobuf objects (for example, like this), but the surface area of those bindings would be huge and hard to maintain.

3. We've thought about writing a protoc plugin to generate these files, but that's beyond the scope of our team's skills right now

[gkdn]

Default Java protobuf implementation would not work with J2CL as it relies on reflection.

We have a particular implementation of J2CL that generates the same API but makes it JavaScript friendly. We are looking into open-sourcing it but cannot give you a definite time line.

[sgammon]

@gkdn thank you for your response on this. is there any update? it is becoming a blocker for us

[gkdn]

WIP but https://github.com/google/j2cl-proto

[sgammon]

@gkdn thank you for sharing, this looks awesome.

[gkdn]

j2cl-proto should be working fine for a while now. That would be great if somebody could put some samples there but for the purposes of this bug, I think we are don.

[gkdn]

There was a mistake on the release. Re-opening this.

[sgammon]

@gkdn i have a few questions, when you have some time to answer them (i know this is still under development).

1. we're already using protobuf JS and grpc-web in our frontend dependency mix - how might we pass objects between J2CL and other Closure-enabled code in JS?

2. what about gRPC on the J2CL side? assuming the answer to q#1 is complex, and we choose to keep all of our code in J2CL land (avoiding the need to bridge back and forth for immutable JS proto records), how would we dispatch to gRPC and back to produce those objects in J2CL?

[sgammon]

in any case, i'm excited to use this more, and i've integrated J2CL into Elide (the framework) and our own internal apps. but that's what's holding me up from using it in full, because our object model heavily uses protobuf, and so without those objects, J2CL is relegated to sharing constants between the frontend and backend, when it can do so much more.

[gkdn]

we're already using protobuf JS and grpc-web in our frontend dependency mix - how might we pass objects between J2CL and other Closure-enabled code in JS?

This is why we introduced immutable js proto under the J2CL proto repository. It provides seamless integration with closure. And they were "suppose" to be easy to convert to mutable protobuf JS.
I'm saying "suppose to" because we currently don't support binary wire format. We support something called JSPB which is the google's internal format. Without binary you cannot replace your existing protobuf JS usages in open-source nor easily convert them. So you would need to do copy manually or via code generation.

On the bright side, the discussions of supporting binary format in immutable protobuf as well as converging to a single js protobuf implementation is still ongoing.

what about gRPC on the J2CL side?

I don't have gRPC experience but I assume it would be using the standard proto serialization (i.e. binary format). If you would like to avoid bridging via immmutable js proto then you would need to maintain your own @JsType(isNative=true) Java model objects that maps to Closure types.
You can also experiment with auto generating them via protoc plugin (similar to J2CL protos).