Add update for 2018-03-19

[nathansobo]

Rendered

This update mostly links out to other material, so even though it looks small I actually put a lot of effort into explaining where we are at this week. I just opted to put my efforts into a more permanent document that we can hopefully maintain on an ongoing basis.

Gonna let this bake over the weekend and merge it on Monday. Comments and questions are welcome and may help improve the update.

/cc @ashumz

[breezykermo]

@nathansobo and @as-cii, thank you for your hard work on this. I'm tracking the project eagerly! (And once I come to terms with Rust's more esoteric features I'll do my best to help out.)

I like the switch to a client/server architecture. With respect to the communicating Workspace state between the client and server, I wonder if a GraphQL-like query language might make sense for relaying changes. Not only would it provide a concise syntax for changes in the updates() stream, it would also set the stage for a more granular render() response from the server down the line.

Starting with sending the whole state on render() would still make sense; my suggestion is that the GraphQL semantics might allow for a thinner layer of data being passed on render() at some point in the future.

The decision to use React on the client makes sense to me, for the context feature as noted, but also because it would potentially enable the facile development of clients on other platforms through 'React Native' libraries. GraphQL as a query language makes further sense to me here: different clients might require slightly different states, and GraphQL's syntax would accommodate and document attributes of the state that are added as the platform grows.

Cons of adding GraphQL or a GraphQL-ish query language for client/server communication: cognitive burden for developers?

Maybe you've already thought of this and reasoned against it: I'd be interested to hear your thoughts!

[nathansobo]

@breezykermo Thanks for your support! GraphQL crossed my mind early on in the process of designing what we're implementing here, so I can definitely see why you're bringing it up. Ultimately, though, I don't think it's a good fit.

What we're implementing here is pretty different from the typical architecture of a web application, because most web apps need to assume non-trivial and unpredictable latency between the client in the server. The typical web front-end manages its own internal state and processes all user interactions locally to minimize the impact of latency. It then pulls the data that it needs to support those interactions from the server, and this is where GraphQL is really useful. It allows the client to formulate a query that expresses its exact data needs.

In our case, the window is connected to the server over a local socket, meaning that latency is effectively zero. This allows us to invert the typical design. We don't even really process user interactions on the client at all, and instead forward them directly to the server. This allows us to maintain an abstract server-side representation of the entire user interface. Whenever the UI needs to change, we push data to the view. The view is never in a position to make a request. It only handles incoming data and updates to reflect the latest state.

I hope this clarifies why something like GraphQL doesn't quite fit into the model. It might make more sense when communicating between two servers, but even there we may want to implement a more custom protocol.

[breezykermo]

@nathansobo, makes sense! Thank you for taking the time to respond so thoughtfully and comprehensively. :)