I guess "giant" is too big of a word. Most clients currently are first-party and using the same Go implementation. Maybe now is the time to make any breaking changes to get ready for ecosystem growth.
On Thu, Dec 28, 2017 at 8:39 PM, Eric Drechsel <[email protected]> wrote: > 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> > > -- 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.
