Clients in control building demand-driven systems with Om Next

Slide 1

Slide 1 text

Full Stack Fest - 2016 @anmonteiro90 Clients in control building demand-driven systems with Om Next

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

REST: expectations • deﬁne logical “resources” • identiﬁed by URIs • clients request them

Slide 4

Slide 4 text

REST: reality • can only request / create trivial data • “joined” resources • bloat endpoint? • multiple requests?

Slide 5

Slide 5 text

– Roy T. Fielding, PhD “The trade-off, though, is that a uniform interface degrades efﬁciency, since information is transferred in a standardized form rather than one which is speciﬁc to an application's needs.”

Slide 6

Slide 6 text

Luke Wroblewski

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

“Demand-driven” architecture

Slide 10

Slide 10 text

1. Demand

Slide 11

Slide 11 text

2. Composition

Slide 12

Slide 12 text

3. Interpretation

Slide 13

Slide 13 text

“[…] 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)

Slide 14

Slide 14 text

Demo

Slide 15

Slide 15 text

https://facebook.github.io/react/

Slide 16

Slide 16 text

https://facebook.github.io/relay/ http://graphql.org/

Slide 17

Slide 17 text

“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

Slide 18

Slide 18 text

https://netﬂix.github.io/falcor/

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Transit http://clojurescript.org/ https://github.com/cognitect/transit-format http://clojure.org/ http://www.datomic.com/

Slide 21

Slide 21 text

om.next https://github.com/omcljs/om

Slide 22

Slide 22 text

1. clients can request the exact total response they need 2. clients can communicate novelty atomically • without sacriﬁcing relational queries on the server

Slide 23

Slide 23 text

Om Next opinions • Single source of truth • Minimize ﬂushing to DOM • No (visible) • asynchrony • event model

Slide 24

Slide 24 text

Checkpoint • Precise requests? • Client • Server • Communicate novelty? • Communicate identity back? • Data over the wire? • Client-only state • Testing • Caching • Pluggable client / server storage?

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

[:person/name]

Slide 27

Slide 27 text

(defui Person static om/IQuery (query [this] [:person/name]) Object (render [this] ...))

Slide 28

Slide 28 text

Query expressions

Slide 29

Slide 29 text

:person/name ‘(:person/friends {:sort :asc}) {:person/address [:address/street :address/zip]}

Slide 30

Slide 30 text

(increment/users!) (delete/friend! {:me 1 :friend 2})

Slide 31

Slide 31 text

Parser • f (query) = data [:person/name] {:person/name “António”}

Slide 32

Slide 32 text

Parser • reads & mutations • Runs on front- & backend • Hydrate queries • no reshaping! • Edge of the system

Slide 33

Slide 33 text

[(person/add! {:person/name “António” :person/address {:address/street “Hochschulstraße” :address/zip “01069”}})]

Slide 34

Slide 34 text

[(delete/friend! {:me 1 :friend 2}) :friends/list] Re-read this key

Slide 35

Slide 35 text

Creating information • Create temporary information on client • Remote mutation hits server • Server replies with mappings • tempids → real ids

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Client-only state • First-class support • Storage: merged with remote state • Parser distinguishes local / server • able to pick remote queries

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

Normalization

Slide 40

Slide 40 text

Normalization • Also in Relay, Falcor • Om Next can automatically • Normalize • Denormalize

Slide 41

Slide 41 text

{:people [{:person/name “Alice” :person/age 25} {:person/name “Bob” :person/age 34}] :favorites [{:person/name “Bob” :person/age 34}]}

Slide 42

Slide 42 text

{: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}}}

Slide 43

Slide 43 text

{: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}}}

Slide 44

Slide 44 text

React render Transaction Re-render

Slide 45

Slide 45 text

Incremental rendering (Om Next) Transaction Re-render

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

Testing • global state + parser = awesome • Pure components • f (data) = UI • We can just test the UI data tree!

Slide 48

Slide 48 text

Property-based testing • example-based • specify input / output pairs • property-based • write invariants • generate random input • attempt to falsify invariants, shrinking

Slide 49

Slide 49 text

Om Next + test.check • queries / mutations are data • generate transactions • run against the parser • check invariants in resulting state

Slide 50

Slide 50 text

Demo

Slide 51

Slide 51 text

Testing recap 1. Generate random transactions 2. Shrink failures 3. Use minimal failure to reproduce bugs

Slide 52

Slide 52 text

Testing recap 1. Generate random transactions 2. Shrink failures 3. Use minimal failure to reproduce bugs

Slide 53

Slide 53 text

More Om Next • Recursive UIs • Heterogeneous UIs • HTTP Caching • Custom storage • Streaming • Server-side rendering

Slide 54

Slide 54 text

Server • Clojure preferred / less boilerplate • Other languages -> implement parser logic • easier for languages with Transit • Datomic supported by default • other DBs work as well

Slide 55

Slide 55 text

Project status • Beta next week • documentation • github.com/omcljs/om/wiki • awkay.github.io/om-tutorial/ • anmonteiro.com

Slide 56

Slide 56 text

Takeaways • we can radically simplify UI programming • regardless of library / framework • strive for simple systems • with these 2 properties