Clients in control building demand-driven systems with Om Next

Traditional architectures are no longer suitable for the increasing needs of today's applications. The price is often paid in high bandwidth and reduced performance. Demand-driven design enables clients to request arbitrary data on demand. Companies like Facebook and Netflix have switched to demand-driven architectures to better embrace a great variety of continuously changing clients. Solutions like Relay and Falcor/JSONGraph distill such ideas. Om Next builds on, and extends these concepts further, to provide a Clojure(Script) based solution. In this talk, I present the motivation for a demand-driven approach and explore the benefits and tradeoffs that Om Next brings to the table.

1. Full Stack Fest - 2016 @anmonteiro90 Clients in control building demand-driven systems with Om Next
3. REST: expectations • define logical “resources” • identified by URIs • clients request them
4. REST: reality • can only request / create trivial data • “joined” resources • bloat endpoint? • multiple requests?
5. – Roy T. Fielding, PhD “The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs.”
6. Luke Wroblewski
9. “Demand-driven” architecture
10. 1. Demand
11. 2. Composition
12. 3. Interpretation
13. “[…] GraphQL is a “query language” just like URLs are the “query language” of REST—it’s a contract that describes how to tell the API server what you’re looking for.” – Sashko Stubailo, Meteor http://goo.gl/qR9szX (Medium)
14. Demo
15. https://facebook.github.io/react/
16. https://facebook.github.io/relay/ http://graphql.org/
17. “used to hit a RESTful API server at Facebook […]. In transitioning to GraphQL, we deleted tons of code. […] it ended up being dramatically simpler from the client's point of view.” – Lee Byron, GraphQL Engineer https://javascriptair.com/episodes/2016-05-18
18. https://netflix.github.io/falcor/
20. Transit http://clojurescript.org/ https://github.com/cognitect/transit-format http://clojure.org/ http://www.datomic.com/
21. om.next https://github.com/omcljs/om
22. 1. clients can request the exact total response they need 2. clients can communicate novelty atomically • without sacrificing relational queries on the server
23. Om Next opinions • Single source of truth • Minimize flushing to DOM • No (visible) • asynchrony • event model
24. Checkpoint • Precise requests? • Client • Server • Communicate novelty? • Communicate identity back? • Data over the wire? • Client-only state • Testing • Caching • Pluggable client / server storage?
26. [:person/name]
27. (defui Person static om/IQuery (query [this] [:person/name]) Object (render [this] ...))
28. Query expressions
29. :person/name ‘(:person/friends {:sort :asc}) {:person/address [:address/street :address/zip]}
30. (increment/users!) (delete/friend! {:me 1 :friend 2})
31. Parser • f (query) = data [:person/name] {:person/name “António”}
32. Parser • reads & mutations • Runs on front- & backend • Hydrate queries • no reshaping! • Edge of the system
33. [(person/add! {:person/name “António” :person/address {:address/street “Hochschulstraße” :address/zip “01069”}})]
34. [(delete/friend! {:me 1 :friend 2}) :friends/list] Re-read this key
35. Creating information • Create temporary information on client • Remote mutation hits server • Server replies with mappings • tempids → real ids
37. Client-only state • First-class support • Storage: merged with remote state • Parser distinguishes local / server • able to pick remote queries
39. Normalization
40. Normalization • Also in Relay, Falcor • Om Next can automatically • Normalize • Denormalize
41. {:people [{:person/name “Alice” :person/age 25} {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}]}
42. {:people [[:person/by-name “Alice”] {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}] :person/by-name {“Alice” {:person/name “Alice” :person/age 25}}}
43. {:people [[:person/by-name “Alice”] [:person/by-name “Bob”]] :favorites [[:person/by-name “Bob”]] :person/by-name {“Alice” {:person/name “Alice” :person/age 25} “Bob” {:person/name “Bob” :person/age 34}}}
44. React render Transaction Re-render
45. Incremental rendering (Om Next) Transaction Re-render
47. Testing • global state + parser = awesome • Pure components • f (data) = UI • We can just test the UI data tree!
48. Property-based testing • example-based • specify input / output pairs • property-based • write invariants • generate random input • attempt to falsify invariants, shrinking
49. Om Next + test.check • queries / mutations are data • generate transactions • run against the parser • check invariants in resulting state
50. Demo
51. Testing recap 1. Generate random transactions 2. Shrink failures 3. Use minimal failure to reproduce bugs
52. Testing recap 1. Generate random transactions 2. Shrink failures 3. Use minimal failure to reproduce bugs
53. More Om Next • Recursive UIs • Heterogeneous UIs • HTTP Caching • Custom storage • Streaming • Server-side rendering
54. Server • Clojure preferred / less boilerplate • Other languages -> implement parser logic • easier for languages with Transit • Datomic supported by default • other DBs work as well
55. Project status • Beta next week • documentation • github.com/omcljs/om/wiki • awkay.github.io/om-tutorial/ • anmonteiro.com
56. Takeaways • we can radically simplify UI programming • regardless of library / framework • strive for simple systems • with these 2 properties
57. github.com/anmonteiro/talks
58. Questions?