Demand driven applications with om.next and react native

1. Demand-driven architecture
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
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
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

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

You are reading a preview.

Demand driven applications with om.next and react native

More Related Content

Viewers also liked

Similar to Demand driven applications with om.next and react native

Featured

Related Books

Related Audiobooks