Robust Mobile Clients (v2)

Extended Toaster Edition. State Machine Included.

Crafted for mDevCamp 2014

Transcript

1. ROBUST MOBILE CLIENT Building clients for distributed scalable systems Zdenek Nemec – @zdne Apiary.io Toaster controls that do not break
2. API BLUEPRINT APIARY iOS developer ABOUT ME Zdenek Nemec – @zdne BSG fan
3. DISTRIBUTED SYSTEMS
4. WORLD WIDE WEB
5. INTERNET OF THINGS
6. MY AWESOME SERVICE
7. CLIENTS
8. WORLD WIDE WEB
9. INTERNET OF THINGS INTERNET OF THINGS
10. CLIENT MY AWESOME SERVICE
11. MOBILE
12. MOBILE
13. MOBILE
14. MOBILE “In 2013, the number one reason APIs are deployed, is to support mobile development.” ! – Kin Lane
15. CHALLENGE
16. SERVER EVOLVES INTERFACE CHANGES
17. Interface Changes = Client Breaks SITUATION in 2014
18. REDEPLOY THE CLIENTS!!!
19. • Apple reviews every App submission • It takes time (~1-2 weeks) • Breaking a client = client users are left in the dark for weeks REDEPLOING CLIENT iOS perspective
21. SERVER EVOLUTION vs. CLIENT LONGEVITY
22. SOLUTION in 2014
25. We freeze the evolution so clients can live longer.
26. We can do better.
27. TOGETHER
28. PROMISES
29. • 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* PROMISES * results may vary
31. HOW?
32. DECOUPLE
33. • 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 DECOUPLE
34. DISTRIBUTED HYPERMEDIA SYSTEM
35. HOW DOES IT WORK?
36. SERVER
37. TOASTER AUTOMATON Waiting Holding Bread Cooking Finite State Machine Insert Eject Cook Eject Set Cook Time •cook time •cook time •cook time Set Cook Time Set Cook Time
38. CLIENT
39. • 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
40. ! • 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) TOASTER CLIENT
41. THIS IS HOW WEB WORKS!
42. HOW DO I GET STATES TRANSITIONS? Hint: How does the web work?
43. • Hypermedia Media Type • Representation of a resource • properties • affordances • embed idempotent relation entities • HAL+JSON, Siren, Uber, Cj, Verbose … REPRESENTATIONAL STATE TRANSFER REST Architectural Style
44. TOASTER EVOLUTION Cooking •cook time Set Cook Time • Server stops offering set cook time in the cooking state • Client not following available affordances from server will break • Client following available affordances from server will stop showing the set cook time UI controls
45. TOASTER EVOLUTION Waiting Cooking Insert = Cook Eject •cook time •cook time Set Cook Time Set Cook Time • Toaster now immediately cooks after bread is inserted • Client not following available affordances from server will break • Client following available affordances from server will still be able to make a crispy toast
46. EXAMPLE
47. 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”
48. FIZZBUZZ
49. • Author: Stephen Mizell (@Stephen_Mizell) • 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 FizzBuzz as a Service
50. FizzBuzz FBAAS AUTOMATON API root • Number • Answer First FizzBuzz Last Next
51. 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
52. 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
53. 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
54. DECOUPLED APPROACH • Without redeploying clients • change URLs • change the algorithm • control the number of API calls (through embedding) • add / extend or modify the functionality
55. DEMO iOS Client for FizzBuzz service
57. Everyone has to do his / her part.
60. DEMAND REASONABLE API DESIGN NOW!
61. • http://apiary.io • http://apiblueprint.org • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://apievangelist.com • http://smizell.com • http://smizell.com/weblog/2014/solving-fizzbuzz-with-hypermedia • http://words.steveklabnik.com/hypermedia-fizzbuzz • http://petegamache.com/wsrest2014-gamache-slides.pdf • https://github.com/gamache/hyperresource • http://www.slideshare.net/KevinONeill1/hypermedia-for-the-ios- developer-swipe-2012 • http://www.slideshare.net/royfielding/evolve13-keynote-scrambled- eggs • http://www.mnot.net/blog/2011/10/25/ web_api_versioning_smackdown • http://github.com/zdne/fizzbuzz-client REFERENCE
62. • http://www.flickr.com/photos/polishsausagequeen/2178265710/ • http://www.flickr.com/photos/breannajosephine/5265280328/sizes/l/ • http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ • http://techcrunch.com/2014/04/30/facebook-api-guarantee/ • http://comicbook.com/blog/2013/01/31/the-big-bang-theory-spoiler- does-sheldon-actually-sleep-with-amy/ • http://knowyourmeme.com/memes/shut-up-and-take-my-money • http://www.kitchenaid.com • http://www.hdwallpapersarena.com/wp-content/uploads/2012/12/ Tesla-Model-S-2013-widescreen-15.jpg • http://www.peer1.com/blog/peer-1-hosting-launches-map-of-the- internet-app • http://www.reddit.com/r/geek/comments/mdf63/evolution/ PHOTO CREDITS
63. REST • 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 Architectural Constraints