Successfully reported this slideshow.

Demand driven applications with om.next and react native

3

Share

Upcoming SlideShare
Introduction to React Native
Introduction to React Native
Loading in …3
×
1 of 22
1 of 22

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

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?

Editor's Notes

  • 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
  • ×