ROBUST MOBILE CLIENT Building clients for distributed scalable systems Toaster controls that do not break Zdenek Nemec – @zdne Apiary.io
ABOUT ME Zdenek Nemec – @zdne APIARY API BLUEPRINT iOS developer BSG fan
WORLD WIDE WEB
INTERNET OF THINGS
MY AWESOME SERVICE
WORLD WIDE WEB
INTERNET OF F THINGS
MY AWESOME SERVICE CLIENT
MOBILE “In 2013, the number one reason APIs are deployed, is to support mobile development.” ! – Kin Lane
SERVER EVOLVES INTERFACE CHANGES
SITUATION in 2014 Interface Changes = Client Breaks
REDEPLOY THE CLIENTS!!!
REDEPLOING CLIENT iOS perspective • Apple reviews every App submission • It takes time (~1-2 weeks) • Breaking a client = client users are left in the dark for weeks
SERVER EVOLUTION vs. CLIENT LONGEVITY
SOLUTION in 2014
We freeze the evolution so clients can live longer.
We can do better.
PROMISES • Client resilient to API changes • API that can evolve • Tune communication without redeploying clients • Move fast • Less code • Less maintenance • Less worries • Better life and everything* * results may vary
DECOUPLE • Decouple server and client logic • Do ONLY your part • No assumptions about the counterpart’s implementation • No reimplementation of the server logic in client • Server-driven interaction
DISTRIBUTED HYPERMEDIA SYSTEM
HOW DOES IT WORK?
TOASTER AUTOMATON Finite State Machine Set Insert Cook Time Waiting Holding Bread •cook time Set Eject •cook time Cook Time Eject Cook Cooking •cook time Set Cook Time
TOASTER CLIENT • Understands the meanings of • toaster, bread • insert, eject, hold, and set cook time affordances • cook time property • Does not understand how toaster works
TOASTER CLIENT ! • Starts in one of the tree states • Retrieves available state transitions from the toaster server • Decides what of available transitions to take (or none) • Nothing else! (e.g. assuming how cooking works)
THIS IS HOW WEB WORKS!
HOW DO I GET STATES TRANSITIONS? Hint: How does the web work?
REPRESENTATIONAL STATE TRANSFER REST Architectural Style • Hypermedia Media Type • Representation of a resource • properties • affordances • embed idempotent relation entities • HAL+JSON, Siren, Uber, Cj, Verbose …
TOASTER EVOLUTION • Server stops offering set cook time in the cooking state Cooking • Client not following available •cook time affordances from server will break • Client following available Set Cook Time affordances from server will stop showing the set cook time UI controls
TOASTER EVOLUTION • Toaster now immediately cooks after bread is inserted • Client not following available Waiting Insert affordances from server will break •cook time = Cook Set • Cook Time Client following available affordances from server will still be Eject able to make a crispy toast Cooking •cook time Set Cook Time
FIZZBUZZ ! • Print numbers from 1 to 100 but… • Multiplies of 3 print “Fizz” • Multiplies of 5 print “Buzz” • Multiplies of both 3 and 5 print “FizzBuzz”
FBAAS FizzBuzz as a Service • Author: Stephen Mizell (@Stephen_Mizel ) • Server knows how to calculate FizzBuzz for given number • Server knows what is the next FizzBuzz • Clients may decide what is the step and at what number to end
FBAAS AUTOMATON Next First FizzBuzz API root FizzBuzz • Number • Answer Last
COUPLED APPROACH 1: for i in 1..100 2: answer = GET /fizzbuzz?number=i 3: print answer • This coupled: • Tied to a particular URL • Iteration implies assumption about the result
COUPLED APPROACH 1: while i < END 2: answer = GET /fizzbuzz?number=i 3: print answer 4: i = i + STEP • This coupled: • Duplicates the Server logic (addition) • Keeps track of the end
DECOUPLED APPROACH 1: answer = root.follow(“first”) 2: print answer 3: while answer.hasLink(“next”) 4: answer = answer.follow(“next”, step: STEP, end: END) 5: print answer • This decoupled: • No hardcoded URLs • No Server logic on the Client • Completely driven by the Server
DECOUPLED APPROACH • Without redeploying clients • change URLs • change the algorithm • control the number of API calls (through embedding) • add / extend or modify the functionality
REST Architectural Constraints • Client–server • Stateless • Cacheable • Layered system • Code on demand (optional) • Uniform interface • Identification of resources • Manipulation through representations • Self-descriptive messages • Hypermedia as the engine of application state