by Garann Means at HTML5 Texas Conference in Austin, TX
Many front-end developers are familiar with MVC, and almost all are familiar with event-driven architectures (even if they call them something else). How do those two philosophies work together? And, more importantly, how can websockets help future applications become more responsive, more consistent, and easier to develop? We’ll reexamine the Controller concept from MVC and figure out how to combine simple browser messaging and websockets to address our application needs and improve our user experiences.
JavaScript
Did well for a while without patterns and frameworks, but once we realized its potential we added everything at once, adding complexity and functionality.
#singlepageappaproblems
Single Page Applications (SPAs) today are everywhere, as well as SPA behavior on static pages, requiring 3rd-party tools and systems of dependencies. It’s easy to set up, but difficult to maintain.
There are some tradeoffs – the first time to render increases; we have SEO issues; issues with multiple HTTP requests and it is difficult to create good packages.
Implementation Issues
- Creating App scaffolding
- how & when to redraw
- where client interaction fit
- and “those darn HTTP requests”
Some approaches
- Twitter – server-rendered HTML (Flight)
- airbnb – Node, full-stack Backbone
- Meteor – (ok, not an implementation) Node
Model-View-*
- circa late 1970’s
- closely tied to OOP (SmallTalk)
- implemented in popular frameworks
- traditionally backend
Model
- aka “object”
View
- presentational part of the app
- draw the interface
- inerpolate data
- (optionally) capture user interaction
MV* in JavaScript
- MV* follows OOP
- mix in a dash of rapid development
Event-Driven Architectures
- less formal than MVC
- suit high-I/O systems
- simple and reactive
- seen more in tools than applications
events and object
- less data persisted overall
- models less bound to data
- natural “model” is a state
events themselves
- user interaction with view
- server itarction wth state
- messaging within the application itself and is highly decoupled
EDA in JavaScript
- is how we do it
- all JS triggered by client-side events
- event handling has evolved over time from inline onclick to event delegation, pub/sub, etc.
- dearth of sophisticated EDA JS frameworks
EDA & MVC need to get together and make it happen
dealing with data
- In MVC, everything is in models
- EDA may be in models or something else
- MVC lends itself to CRUD
- EDA uses ad-hoc updates
the views
- MVC is one-to-one data, while EDA is highly composite view reflecting state
- In MVC the veiew is responsible for interaction, while in EDA the interaction is the first-class component
the action
- In MVC, the action is triad-specific, but in EDA it’s first-class.
- In MVC, object don’t influence controllers and in EDA objects have event awareness
everybody loves MV*
the whole family
- MVC: tight triads, view bubbles up through controller
- MVP: model and view pared, presenter can “float”
- MVVM: model and view super tightly coupled, observerish
the appeal
- the age of OOP
- big teams, separation of concerns
- the age of REST
- easy mapping to server code
- good tools, obvs (awesome tools make people want to use things)
how we do it (now)
- lightweight MVC – controller in router, view, other?
framework choices
- no need for boilerplate
- too much for small apps?
- too little for big apps?
- SoC depends on NoC
a viewmodel
Knocback.js in TodoMVC
No SPA is an Island
- We need someone to talk to
- given: server supplies first render – data, but probably HTML
- server updates
- localstorage
when it’s easy
- CRUD
- REST
- highly automatable
when it’s tricky
- changing multiple models
- lots of quick state changes
- uploading offline data
what is that tho (websockets)
- it has its own protocol – TCP, port 80, ws: and wss:
- server can push data
- replacement for e.g. long-polling
not your mama’s comet
- bi-directional
- no request, no response
- cross-origin support
- dead simple API
available now
- ff 16
- chrome 23
- ie 10
- opera 12
- safari 6
- iffy on mobile
uses
- tickers
- chat
- collaborative editing
- yes, games
- every Node Knockout app ever
getting cozier with the server
EDAing the *s
- controllers/presenters/viewmodels full of events
- free events from triads
- subscribe at application level
- any old event system will do
event piping
- decouple user and server interaction
- provide place for validation
- allow multiple subscribers – pieces of the application from all over the place can listen for what you’re publishing
EDA + WebSockets
- chained like interface events (make sure that all pieces of the event are finished before going to the next one)
- specific controllers can subscribe to global events
- updates can be cached and bundled
realtime talk
DiY WebSockets
- declare a socket with URL and protocol
- listen for open connection – send client messages
- listen for server messages
connecting it
- add messaging anywhere in controller/presenter/etc.
- use it for syncing if rolling your own
- replace framework sync calls in implementation with socket events
- use WebSockets plugin for framework (e.g. backbone.io)
sockets for control
- take action based on server messages (interesting application)
- pipe events
- subscribe on models and views
- very similar to MVP
together at last
a tool to use within your patter
usa a little ad-hoc
What do YOU think? Let me know...