Clients in control: building demand-driven systems with Om Next
0 likes279 views
The document discusses the development of demand-driven systems using Om Next at the Craft Conf 2016, focusing on RESTful expectations versus reality in client-server interactions. It emphasizes desirable properties of client requests and features like temporary state creation, normalization, and testing methodologies, aiming to simplify UI programming. Additionally, it highlights the project's status nearing beta and the necessity of supporting specific UI properties regardless of the framework used.
![– Roy T. Fielding, PhD
“The REST interface is designed to be efficient
for large-grain hypermedia data transfer, […]
resulting in an interface that is not optimal for
other forms of architectural interaction.”](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-6-320.jpg)
![[:person/name]](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-28-320.jpg)
![(defui Person
static om/IQuery
(query [this]
[:person/name])
Object
(render [this]
...))](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-29-320.jpg)
![Query expressions
:person/name
(:person/friends {:sort :asc})
{:person/address
[:address/street :address/zip]}](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-30-320.jpg)
![Parser
[:person/name]
{:person/name “António”}](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-33-320.jpg)
![[(person/add!
{:person/name “António”
:person/address
{:address/street “Hochschulstraße”
:address/zip “01069”}})]](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-36-320.jpg)
![[(delete/friend! {:me 1
:friend 2})
:friends/list]
Re-read this key](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-37-320.jpg)
![{:people [{:person/name “Alice”
:person/age 25}
{:person/name “Bob”
:person/age 34}]
:favorites [{:person/name “Bob”
:person/age 34}]}](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-44-320.jpg)
![{: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}}}](https://image.slidesharecdn.com/slides-160515120431/85/Clients-in-control-building-demand-driven-systems-with-Om-Next-45-320.jpg)
Clients in control: building demand-driven systems with Om Next
- 1. Clients in control building demand-driven systems with Om Next Craft Conf 2016 @anmonteiro90
- 4. REST: expectations • define logical “resources” • identified by URIs • clients request them
- 5. REST: reality • only able to request trivial data • “joined” resources • bloat endpoint? • multiple requests?
- 6. – Roy T. Fielding, PhD “The REST interface is designed to be efficient for large-grain hypermedia data transfer, […] resulting in an interface that is not optimal for other forms of architectural interaction.”
- 7. REST
- 8. REST
- 9. REST
- 10. REST
- 11. – 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.”
- 12. Luke Wroblewski
- 13. How to write a service that meets the varying demands of heterogeneous clients?
- 19. Desirable properties • clients can request the exact total response they need • clients can communicate novelty atomically • without sacrificing relational queries on the server
- 23. Checkpoint • How to make precise requests? • Client • Server • How do clients communicate novelty? • Communicate identity back to client? • Communication over the wire? • Client-only state • Testing • Caching • Pluggable client / server storage?
- 24. Transit
- 25. Enter Om Next…
- 26. Om Next opinions • Single source of truth • Minimize flushing to DOM • Abstract asynchrony • No (visible) event model
- 28. [:person/name]
- 29. (defui Person static om/IQuery (query [this] [:person/name]) Object (render [this] ...))
- 30. Query expressions :person/name (:person/friends {:sort :asc}) {:person/address [:address/street :address/zip]}
- 31. Query expressions (increment/users!) (delete/friend! {:me 1 :friend 2})
- 32. Parser • Evaluates query expressions • Hydrates queries • no reshaping!
- 34. Parser • Runs on the client and server • Runs reads and mutations
- 35. Demo
- 36. [(person/add! {:person/name “António” :person/address {:address/street “Hochschulstraße” :address/zip “01069”}})]
- 37. [(delete/friend! {:me 1 :friend 2}) :friends/list] Re-read this key
- 38. Creating information • Create temporary information on client • Remote mutation hits server • Server replies with mappings • tempids → real ids
- 40. Client-only state • First-class support • Storage: merged with remote state • Parser distinguishes local / server • knows how to pick remote queries
- 43. Normalization • Also in Relay, Falcor • Om Next can automatically • Normalize • Denormalize
- 44. {:people [{:person/name “Alice” :person/age 25} {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}]}
- 45. {: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}}}
- 47. Testing • global app state + immutability = awesome • Parser abstraction = 1 place • React = pure function • 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 tests • 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. 1. Generate random transactions 2. Shrink failures 3. Use minimal failure to reproduce bugs Testing recap
- 53. More Om Next • Recursive UIs • Heterogeneous UIs • HTTP Caching • Custom client side storage • Streaming
- 54. Server • Clojure preferred / less boilerplate • Other languages need to implement parser logic • easier for languages with Transit implementation • Datomic rocks • some people using other DBs
- 55. Project status • very close to beta • 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 • your system should support these properties
- 57. – Rich Hickey “Programmers know the benefits of everything and the tradeoffs of nothing”
- 59. Questions?