Fun with the BARC stack (FSTO2015)

Quick session on Node.js prototyping for Web browsers that I presented at the FullStack TO 2015 conference.

Transcript

1. Fun with the BARC stack Prototyping with Node.js, virtual DOM, WebSocket RPC and Promises @unframework
2. Hi, I’m Nick Matantsev • @unframework (find me on GitHub!) • product technical lead at Myplanet ◦ past: TMX, health/pharma, large social sites • backend, frontend, server automation • 3D graphics, Android for fun • passionate about: ◦ UX ◦ lean enterprise ◦ empathy-driven engineering @unframework
3. Let’s talk prototyping, quick hacks • engineering family background ◦ learned Assembly before I learned English • how do things work, what makes them tick? • corollary: I bet I could make it too • indulge in tech, but also create value! ◦ startups = tech + marketing/evangelism ◦ sense of purpose, enhanced by empathy • amazing opportunities for hacking app ideas @unframework
4. Prototyping and hacking w/Node • good old JavaScript ◦ but on command-line • 1000s of useful packages ◦ https://www.npmjs.com/ • integrate with Slack, GitHub, Twilio, hardware (Tessel, Raspberry Pi), etc • great for quick hacks and trying integrations ◦ (also see Python, etc, as good alternatives) @unframework
5. Node.js vs browser code • APIs do not trust browsers • can’t move everything onto client code • need shared persistence (e.g. databases) • most hacks start out as command-line runs @unframework
6. Making a prototype Web interface • e.g. grab webcam images from the browser • easily show data output, pictures • WebGL rendering • may deploy on e.g. Heroku, share URL • many hacks still use local hardware ◦ just a convenient output form @unframework
7. Hokay, let’s try it • set up Express • serve the UI to browser ◦ HTML ◦ CSS ◦ JS • define POST routes for interaction ◦ need jQuery to submit AJAX requests ◦ serialize/deserialize param strings • UI layout: Bootstrap? @unframework
8. But I just wanted to show a button • lots of boilerplate to start • hard to modify as the prototype pivots • existing workflow is for websites! ◦ no need to worry about security, scalability, responsive layout, etc • can I haz quick hack pls? @unframework
9. Node to page: main sticking points • server-client interaction ◦ standard AJAX is over-engineered ◦ all we need here is simple function calls • defining the UI itself ◦ ugh, CSS = WTF ◦ need the simplicity of reactive display render ◦ absolute-positioned layouts are OK • client-side URL routes (location hash) ◦ not so common, but still fun to consider! @unframework
10. Server-client: RPC • RPC = remote procedure calls ◦ love/hate, not considered REST-ful ◦ roots in enterprisey SOA blah blah • but we don’t need much • transparently call functions, pass values ◦ HTTP? what’s that? • possibility of two-way communication ◦ aka “server push” @unframework
11. Cheap RPC using remote-control • borne from prototyping “Checklist Hunt” ◦ needed GitHub API token access via server • using WebSockets! • just opens a WS connection and maps server functions to messages ◦ think “tunnel” for function calls @unframework
12. Cheap RPC using remote-control • declare “exported” module/class on server • automagically runs a web server ◦ client code is given a blank page ◦ exported server code is already hooked up ◦ just require(‘__server’) • usually Browserified, but can work as global • network is async: using Promises to remote method responses @unframework
13. Promises • JS is async ◦ disk, network do not block, just invoke callbacks when data is ready ◦ “callback hell” = when several sequential ops, resulting in a nested ladder of callbacks • Promise = immediate placeholder for future value ◦ collect the results by calling “then(callback)” ◦ allows chaining, error handling, ES7 async/await @unframework
14. Client-server link overview • use RPC over WebSocket for quick and flexible communication • remote-control module does the grunt work ◦ serving up blank page with client code ◦ wiring up server methods in browser ◦ wraps every call in a Promise to track async completion @unframework
15. Displaying the UI • just want buttons and simple text ◦ no long-form flowing NYT editorial layouts ◦ no scrolling (99% of cases) • canvas 2D draw? ◦ straightforward… but needs buttons/text-fields • just use absolute CSS layouts ◦ top, left, width, height ◦ inline style because each part is a one-off • code is still kind of verbose @unframework
16. Cheap UI layout with Boxbits • evolved from prototyping HTML5 games ◦ just “cheap” 2D positioning without canvas • basic built-in styling • basic primitives like images, text and buttons • can always add custom HTML ◦ just rely on position:absolute • reactive rendering based on virtual DOM @unframework
17. Reactive UI rendering • React, Meteor, Angular - such popular! wow • coding UI display is hairy ◦ create DOM elements, style them ◦ but, underlying model changes ◦ need to update displayed DOM elements ◦ managing incremental deltas = teh worst • need to simplify (especially for prototypes) @unframework
18. Reactive UI rendering • simple (and classic) idea ◦ make UI display stateless! • game engine analogy ◦ each frame is rendered, then trashed ◦ 16ms later (at 60fps), rinse and repeat ◦ DOM, styling = intermediate steps for browser “final picture” ◦ rebuild DOM tree every time, instead of updating ◦ DOM is slow to just trash, so use virtual DOM @unframework
19. Using virtual DOM • as seen in React • every render = new DOM tree from scratch ◦ actually, lightweight “blueprint” - virtual DOM ◦ the virtual-dom module then translates to “slow” real DOM for display • but when to redraw? ◦ observables? digest loop? ◦ setInterval(render, 10)? ◦ when do interesting things happen? listen to events! @unframework
20. Cheap reactive UI with vdom-live • display can only change when something new happens! ◦ mouse clicks, mouse moves, keyboard, view resize ◦ timer events, AJAX requests ◦ WebSocket traffic (i.e. our RPC) • early versions listened on document events • now using zone.js to intercept everything ◦ when anything happens, just redraw screen! ◦ simple and cheap! (don’t try this in production, yet) @unframework
21. Cheap UI: Boxbits + vdom-live • just give Boxbits your “repaint” callback • use Boxbits chained API to draw boxes, buttons, etc ◦ produces a basic mobile-friendly fixed screen ◦ can still inject custom HTML (e.g. webcam display, etc) • that’s it for UI, can get back to hacking @unframework
22. Client-side routes • change browser location bar without refreshing page ◦ don’t want to lose client state, network connections • not so common for prototype UIs ◦ still nice to have ◦ especially when using as landing page for e.g. OAuth • simplest case: location hash @unframework
23. Cheap routing with atomic-routes • treat part after the “#” as path • routes = simple trackers/listeners for specific path pattern • if path = “#/setup”, then active = true ◦ can check status at any point, even during render ◦ can run callback when path is visited ◦ track when path is no longer active = whenDestroyed Promise • path params, declarative, local @unframework
24. Web as remote interface • use RPC + WebSockets ◦ npm: remote-control • no-CSS + virtual DOM + refresh-on-event ◦ npm: boxbits, vdom-live • routes as simple declarative state ◦ npm: atomic-routes • BARC, huh? ◦ Boxbits, Atomic routes, Remote Control • forget convention, hack it! @unframework
25. Thanks! • I’m Nick Matantsev ◦ @unframework on GitHub, Twitter • Check out myplanet.com - we’re hiring! • BARC stack links: ◦ github.com/unframework/boxbits ◦ github.com/unframework/atomic-routes ◦ github.com/unframework/remote-control @unframework