Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Demand driven applications with om.next and react native
Similar to Demand driven applications with om.next and react native (20)
Recently uploaded
Recently uploaded (20)
Demand driven applications with om.next and react native
- 2. Problems of the current architecture
- 3. = REST?
- 4. Let’s do some REST!
- 5. Let’s build an app - post things - comment on things - … profit? Posts Users Comments
- 6. Let’s build an app
- 7. Let’s build an app
- 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. Let’s build an app
- 10. Let’s build an app
- 11. Problems? - duplication of data - maintenance - cascading changes through the entire app - one part always waits for the other
- 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. om
- 14. Disclaimer - Examples are in clojure
- 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. “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. “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. “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. DEMO
- 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. Talks - “om next” by David Nolen - “Why Falcor?” by Jafar Husain - “Relay: An application framework for React” by Josep Savona
- 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