On 3 January 2018 at 17:58, Paul Jolly <[email protected]> wrote: >> > 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. > > > Mathieu - apologies, I didn't find time to give that "problem" we discussed > much time.
np, I don't think the map aspect suffers too much from it. yet. > There were two parts to it as I recall (my memory is now somewhat vague): > a better solution to the encoding workaround to pass values back from Go -> > Javascript > the control over concurrency/order of requests/responses yes, these were roughly the 2 problems. > I've not given any thought to point 1, although I suspect that Johan's work > _might_ help here if raw values on the wire can be simply passed back to > Javascript world (hence avoiding the double encode/decode). (The ultimate > solution, as we discussed, is to lose the requirement to return values from > Go -> Javascript at all by converting more components to Go but that's > another thread entirely :). well, as long as we can take the json encoding/decoding cost, it's not terribly urgent to solve. But it is a recurring problem in the UI components. > Regarding point 2, I did give that some thought (indeed there was another > GopherJS thread talking about exactly the same issue, can't recall > when/where hence don't have a link). I'm looking to put together an example > that safely handles ordering of requests and responses in a non-blocking way > that satisfies the GopherJS constraints of things being non-blocking. The particular case of the map aspect was not too hard because there was only one kind of query exchanged between the server and client, and it was acceptable to ensure that only one is in flight at a given moment, which makes the ordering of responses moot. So once I got the "concurrency" right (which you helped me reason about), this was more or less fixed. > Happy New Year all! Happy new year to you! > Paul > > > -- > 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.
