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!
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
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