Thinking asynchronously: events on the realtime web
27
Thinking asynchronously Sherwood McGraw des. rep. Peer Anarchy, es262 librarians’ syndic, zone TC39
-
Upload
forrest-norvell -
Category
Technology
-
view
337 -
download
0
description
My presentation (speaking as Sherwood McGraw) at the most recent, best, and final RealtimeConf. To really understand the implications of asynchronous distributed systems, it's helpful to think about things from the point of view of the data, and to get as explicit as possible about how your data models and flows bind time and space together.
Transcript of Thinking asynchronously: events on the realtime web
Thinking asynchronouslySherwood McGraw
des. rep. Peer Anarchy, es262 librarians’ syndic, zone TC39
HARD REALTIME
> system-centric
> cybernetics & control systems
> trading & arbitrage
> fixed time budgets
SOFT REALTIME
> person-centric
> chat, commerce & social media
> games
> must be “fast”
REALTIME
CONCURRENCY ASYNCHRONY DISTRIBUTION
CONCURRENCY ASYNCHRONY DISTRIBUTION
CONCURRENCY
ASYNCHRONY
DISTRIBUTION
ASYNCHRONY
ASYNCHRONYtime space
VERTICAL
> lockstep> control flow is imposed> independent> PUSH
HORIZONTAL
> fire and forget> control flow is emergent> interdependent> PULL
> browsers & mobile are increasingly peers rather than clients
> the horizontal model maps well to peer-to-peer architectures
> the network becomes an event bus connecting agents, rather than a pipe pushing data
p2p
but
HORIZONTAL
“this happened and then this happened and then this happened and then this happened”
synchronous story
asynchronous story
“This happened. That happened. This other thing happened. You tell me what it all means.”
> self-contained (or isolated)
> each piece self-contained
> or only knows what’s next
asynchronous data
the difference
> in one, the structure of computation determines the sequence of events
> in the other, that structure is relaxed or absent, and the underlying structure is simpler
example: promises
> promises abstract over not just time but space
> each step processes 1 thing & returns 1 thing
> can be composed, which reintroduces dependencies
> most frequently a simple pipeline
async ⊃ sync
> async is more general than sync
> async data have fewer dependencies
> sync data fits in an async frame, but not vice versa
> callbacks & observables are simple and composable
> callbacks & observables are confusing and hard to reason about
simpler != easier
so
> the results can be simpler, more efficient distributed systems
> but, designers & developers of async systems have more work to do
> and to use it effectively you must change your frame of reference
how
> basic principles of software engineering:
> loose coupling
> stratification
> smallest useful units of modularity
why
> smaller, more composable designs
> does less computation because you’ve done more work up front
> matching the native model of the realtime web
