No dumb questions! I opened https://github.com/camlistore/camlistore/issues/993 as you suggested. I wasn't sure where the best place to take this discussion would be, but the contribution guidelines suggested I sign up for this forum, so that's why I made this post originally instead of making an issue to discuss it.
As for your question, I think technically there might not be a great argument right now as much of the server communication in the frontend is (as far as I can tell) very fragmented. You get small wins like automatically marshalled and unmarshalled payloads to the backend, automatic HTTP/2 connection and Fetch API instead of XHR where available and other things that [Improbable make a much better case for](https://improbable.io/games/blog/grpc-web-moving-past-restjson-towards-type-safe-web-apis) than I ever could. I would like to think it would make the frontend/backend communications more "maintainable", and *nicer* to work with, but I understand your question is really about the trade off between the amount of work it would take to migrate all communications to something like this vs keeping it as it is today and spend the time elsewhere, and whether that trade off is worth it. To me, I think there's also a sense of "why not", and "to show that we can", presumably that was the reason for adopting GopherJS in the first place? I'm only tinkering on the bindings because it's fun and I imagine that's true for all contributions to Perkeep, and maybe it'd be *fun* to implement this. I completely understand if this discussion ends on a "cool idea, but not worth the time investment". After digging around the internals of perkeep for the CL I can tell it's probably not going to be a trivial transition, though if we're moving in the direction of replacing other JS parts with GopherJS, this might make things easier as well. Johan On Friday, 22 December 2017 16:17:13 UTC, Johan Brandhorst 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. > It's only a bandaid until the gRPC-Web spec adds support for client-side > and bidi-streaming. > > 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! > > Johan > -- 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.
