Demand-driven architecture
Problems of the current
architecture
= REST?
Let’s do some REST!
Let’s build an app
- post things
- comment on things
- … profit?
Posts
Users
Comments
Let’s build an app
Let’s build an app
Problems?
- unnecessary complex ajax orchestration
- edge cases
- many points of failure
- a lot of data to download
- one...
Let’s build an app
Let’s build an app
Problems?
- duplication of data
- maintenance
- cascading changes through the entire app
- one part always waits for the o...
The solution
- Stop endpoint overload
- Shift ownership over data to client
- Server returns exactly what the client needs...
om
Disclaimer
- Examples are in clojure
“Client describes data it needs”
(defui Post
Object
(render [this]
(view nil
(text nil (get (om/props this) :username))
(t...
“Client describes data it needs”
(defui Post
static om/IQuery
(query [this]
'[{:user [:username]} :content])
Object
(rende...
“Client describes data it needs”
(defui Post
static om/Ident
(ident [this {:keys [id]}]
[:post/by-id id])
static om/IQuery...
“Client describes data it needs”
(defui TimelineComponent
static om/IQuery
(query [this]
(let [subquery (om/get-query Post...
DEMO
Advantages?
- server API doesn’t need updates
- downloaded data is as small as possible
- no ajax coordination
- focus is ...
Talks
- “om next” by David Nolen
- “Why Falcor?” by Jafar Husain
- “Relay: An application framework for React” by Josep Sa...
Questions?
Upcoming SlideShare
Loading in …5
×

Demand driven applications with om.next and react native

1,025 views

Published on

My talk about om next and react native from the Tokyo iOS meetup November 13th

Published in: Engineering
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,025
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
2
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Todays topic: Demand driven applications
    Anyone experience with it?
    Tries to solve specific problem
    Before going into details, let’s talk about the problems of the current architecture
  • “current” usually means “server client architecture”
    endpoint for user, endpoint for timeline, endpoint for list entries
    client consumes that data
    how to summarize?
    most people use REST
  • Why? REST Worked great so far!
    Works when the app is small scale
    Works when you distribute big chunks of data to external
    Problem is, we want small chunks of data and a lot
    Structure data in small blocks
    Think of it as a relational database
    to actually show what I mean, let’s do some REST
  • to actually show what I mean, let’s do some REST
  • “DaveBook”
    we can post things, comment on things, and somehow make money
    deconstruct: posts, users, comments
    design as endpoints
  • start with a timeline. Contains posts or reference to post
    post belongs to users. Could put username inside /posts/
    post can have comments
    since comments are made by users, needs users too
    everything well designed
    because speed, let’s do ajax
  • start with a loading indicator
    timeline data comes back, show loading indicator for each post or data
    suddenly request 4 is faster than request 2
    at some point all data is present

    edge cases:
    what if user looses connection in between
    what if post 3 gets an error
    what if some of our comments didn’t load
  • big amount of ajax coordination
    care about all these edge cases. One error = don’t load anything?
    many points of failure
    data is verbose and needs to get downloaded
    new feature requires server guys, or feature already there and not used
    we need new solution…
  • design endpoints around app
    merge all data into 1 big endpoint. Contains everything we need
    same thing for /search/
    let’s look how this will do
  • start with loading indicator
    since we don’t break data into pieces, we have to wait
    and wait
    at some point: hey, there’s an app!
  • a lot of endpoints, a lot of duplicated data
    high maintenance
    one change requires all endpoints that contain the data to change
    new feature requires server guys, or feature already there and not used
  • reduce endpoints to a minimum with little maintenance
    let the client decide what data it wants
    downgrade server: instead of pre-providing, If client wants only username, it gets it
    netflix and facebook came independently to same solution

    relay:
    react components query graph same way server did
    falcor does same thing
    another solution: om
  • brings me to om
    clojurescript wrapper for react
    react can go native, so can om
    hybrid solution between falcor and GraphQL. Unified best practices
  • for people never used lisp
    vector = list
    map = map / dictionary
  • generates react class
    uses username and content
    doesn’t care where the data comes from

    describe data as query fragments.
    want content and user, but only username
    static method! Meaning we can call without instance

    because many posts, need identification
    another static method that is used to identify

    doesn’t make sense without timline
  • generates react class
    uses username and content
    doesn’t care where the data comes from

    describe data as query fragments.
    want content and user, but only username
    static method! Meaning we can call without instance

    because many posts, need identification
    another static method that is used to identify

    doesn’t make sense without timline
  • generates react class
    uses username and content
    doesn’t care where the data comes from

    describe data as query fragments.
    want content and user, but only username
    static method! Meaning we can call without instance

    because many posts, need identification
    another static method that is used to identify

    doesn’t make sense without timline
  • queries static method in Post
    filter this list :app/posts with this query. Give me all posts but only these fields
    map post list into post object and put it into view
  • no updates, no new endpoints, one parser should be sufficient
    only get what we want and nothing else. Focus on working on a component
    no ajax coordination. Either data is here or not. Reactive approach updates components when data is there.
    focus on client
    re-use components anywhere, just plug in and data will get fetched
    still alpha but usable today
    clojurescript is awesome
  • Demand driven applications with om.next and react native

    1. 1. Demand-driven architecture
    2. 2. Problems of the current architecture
    3. 3. = REST?
    4. 4. Let’s do some REST!
    5. 5. Let’s build an app - post things - comment on things - … profit? Posts Users Comments
    6. 6. Let’s build an app
    7. 7. Let’s build an app
    8. 8. Problems? - unnecessary complex ajax orchestration - edge cases - many points of failure - a lot of data to download - one part always waits for the other
    9. 9. Let’s build an app
    10. 10. Let’s build an app
    11. 11. Problems? - duplication of data - maintenance - cascading changes through the entire app - one part always waits for the other
    12. 12. The solution - Stop endpoint overload - Shift ownership over data to client - Server returns exactly what the client needs - Exactly what netflix and facebook independently did!
    13. 13. om
    14. 14. Disclaimer - Examples are in clojure
    15. 15. “Client describes data it needs” (defui Post Object (render [this] (view nil (text nil (get (om/props this) :username)) (text nil (get (om/props this) :content)))))
    16. 16. “Client describes data it needs” (defui Post static om/IQuery (query [this] '[{:user [:username]} :content]) Object (render [this] (view nil (text nil (get (get (om/props this) :user) :username)) (text nil (get (om/props this) :content)))))
    17. 17. “Client describes data it needs” (defui Post static om/Ident (ident [this {:keys [id]}] [:post/by-id id]) static om/IQuery (query [this] '[{:user [:username]} :content :id]) Object (render [this] (view nil (text nil (get (get (om/props this) :user) :username)) (text nil (get (om/props this) :content)))))
    18. 18. “Client describes data it needs” (defui TimelineComponent static om/IQuery (query [this] (let [subquery (om/get-query Post)] `[{:app/posts ~subquery}])) Object (render [this] (let [{:keys [app/posts]} (om/props this)] (view nil (apply view nil (map post posts))))))
    19. 19. DEMO
    20. 20. Advantages? - server API doesn’t need updates - downloaded data is as small as possible - no ajax coordination - focus is on client and components - component re-usability - usable today
    21. 21. Talks - “om next” by David Nolen - “Why Falcor?” by Jafar Husain - “Relay: An application framework for React” by Josep Savona
    22. 22. Questions?

    ×