Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clients in control building demand-driven systems with Om Next

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.

António Monteiro

September 08, 2016

More Decks by António Monteiro

Other Decks in Programming


  1. REST: reality • can only request / create trivial data

    • “joined” resources • bloat endpoint? • multiple requests?
  2. – 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.”
  3. “[…] 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)
  4. “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
  5. 1. clients can request the exact total response they need

    2. clients can communicate novelty atomically • without sacrificing relational queries on the server
  6. Om Next opinions • Single source of truth • Minimize

    flushing to DOM • No (visible) • asynchrony • event model
  7. Checkpoint • Precise requests? • Client • Server • Communicate

    novelty? • Communicate identity back? • Data over the wire? • Client-only state • Testing • Caching • Pluggable client / server storage?
  8. Parser • reads & mutations • Runs on front- &

    backend • Hydrate queries • no reshaping! • Edge of the system
  9. Creating information • Create temporary information on client • Remote

    mutation hits server • Server replies with mappings • tempids → real ids
  10. Client-only state • First-class support • Storage: merged with remote

    state • Parser distinguishes local / server • able to pick remote queries
  11. Normalization • Also in Relay, Falcor • Om Next can

    automatically • Normalize • Denormalize
  12. {: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}}}
  13. {: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}}}
  14. Testing • global state + parser = awesome • Pure

    components • f (data) = UI • We can just test the UI data tree!
  15. Property-based testing • example-based • specify input / output pairs

    • property-based • write invariants • generate random input • attempt to falsify invariants, shrinking
  16. Om Next + test.check • queries / mutations are data

    • generate transactions • run against the parser • check invariants in resulting state
  17. More Om Next • Recursive UIs • Heterogeneous UIs •

    HTTP Caching • Custom storage • Streaming • Server-side rendering
  18. Server • Clojure preferred / less boilerplate • Other languages

    -> implement parser logic • easier for languages with Transit • Datomic supported by default • other DBs work as well
  19. Project status • Beta next week • documentation • github.com/omcljs/om/wiki

    • awkay.github.io/om-tutorial/ • anmonteiro.com
  20. Takeaways • we can radically simplify UI programming • regardless

    of library / framework • strive for simple systems • with these 2 properties