I have experience with grpc-go and have thought about what camlistore would look like ported to protobuf/grpc, but ultimately feel neutral about it. It would be nice for client developers, since bindings could be generated for native iOS, Java, etc. It would also make implementing alternative servers easier. But it would be a giant compatibility break. I will at least try to find some time to look at your POC this weekend.
On Thu, Dec 28, 2017 at 6:16 PM, Brad Fitzpatrick <[email protected]> wrote: > > > On Fri, Dec 22, 2017 at 8:15 AM, Johan Brandhorst < > [email protected]> wrote: > >> Hi! >> >> I'm the author of the GopherJS gRPC-Web bindings >> <https://github.com/johanbrandhorst/protobuf>. I was introduced to >> Perkeep by Paul Jolly, who is the author of the GopherJS React bindings >> <https://myitcv.io/react> used by Perkeep to render some of its frontend >> UI. I thought since Perkeep has already invested in GopherJS through this >> UI it might be interested in trying out my gRPC-Web bindings to abstract >> away the communications layer between the frontend and backend in a >> familiar gRPC/Protobuf fashion. >> >> The bindings are built on top of the Improbable gRPC-Web client >> <https://github.com/improbable-eng/grpc-web>. It features support for >> the Fetch API in supported browsers and automatically downgrades to XHR >> where necessary. It implements the gRPC-Web spec >> <https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md>. However, >> the gRPC-Web spec only mandates support for unary and server-side streaming >> at this time. My GopherJS bindings adds support for client-side and >> bidirectional streaming with a custom Websocket proxy on top. Please see my >> demo website <http://grpcweb.jbrandhorst.com/> for an example of this. >> > > Cool! > > >> It's only a bandaid until the gRPC-Web spec adds support for client-side >> and bidi-streaming. >> > > Well, first Javascript itself (the Fetch API) needs to support JavaScript > streaming an HTTP request body to a server. :) I've been waiting for that > for years. > > >> I've submitted a small CL with a prototype of what this could look like >> on a small scale, to show how the bindings are used and hopefully give an >> idea of the impact on the codebase. At this time I only implemented it in >> one place, but ideally for something like this the whole communications >> layer between the frontend and backend would go through the generated >> interface. >> >> https://camlistore-review.googlesource.com/c/camlistore/+/12406 >> >> Please let me know your thoughts! >> > > This could be nice. > > But if we get addicted to this, does it also speak JSON for people who > want to speak JSON? I'm afraid we'd either let our JSON rot, or we'd have > twice the maintenance cost. Ideally we'd get both for free, with one > sufficiently-annotated proto file. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Camlistore" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- best, Eric eric.pdxhub.org <http://pdxhub.org/people/eric> -- You received this message because you are subscribed to the Google Groups "Camlistore" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
