On 22 December 2017 at 18:12, Johan Brandhorst <[email protected]> wrote: > 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.
Yes, opening a discussion here is fine, but follow-up progress is easier to keep track of in an issue. > 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. Yes, originally most of it was is server-connection.js, but I think we've been moving away from it with first React, then GopherJS (because we can write, and hopefully reuse, client code in Go with it). > 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 If you want, I might have a communications use case that I (nor Paul afaik) wasn't able to solve in a very satisfying way, and for which maybe you could come up with a better solution with gRPC-Web? Let me know and I'll send you the details. > 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. Yes, I'm glad you perfectly understand. > 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. Jsyk, there's a much more pragmatic reason for GopherJS: neither Brad nor I like to work in javascript and keep in touch with the madness of its ecosystem. I haven't moved much of the existing codebase yet to GopherJS, but the features/fixes I was was able to add to the web UI were much more pleasant to do with the help of GopherJS than they would otherwise have been. > 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. Yep, regardless of whether we adopt gRPC-Web, I'm still very interested to hear of how it would integrate with Perkeep, and how it would help us. Any time you want to spend on this and report about it is very welcome. thanks, Mathieu > On Friday, 22 December 2017 16:17:13 UTC, Johan Brandhorst wrote: >> >> Hi! >> >> I'm the author of the GopherJS gRPC-Web bindings. I was introduced to >> Perkeep by Paul Jolly, who is the author of the GopherJS React bindings 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. It >> features support for the Fetch API in supported browsers and automatically >> downgrades to XHR where necessary. It implements the gRPC-Web spec. 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 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. -- 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.
