Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Robust Mobile Clients (v2)

Z
May 31, 2014

Robust Mobile Clients (v2)

Extended Toaster Edition. State Machine Included.

Crafted for mDevCamp 2014

Z

May 31, 2014
Tweet

More Decks by Z

Other Decks in Programming

Transcript

  1. ROBUST MOBILE CLIENT
    Building clients for distributed scalable systems
    Zdenek Nemec – @zdne

    Apiary.io
    Toaster controls that do not break

    View full-size slide

  2. API BLUEPRINT
    APIARY
    iOS developer
    ABOUT ME
    Zdenek Nemec – @zdne
    BSG fan

    View full-size slide

  3. DISTRIBUTED SYSTEMS

    View full-size slide

  4. WORLD

    WIDE

    WEB

    View full-size slide

  5. INTERNET

    OF

    THINGS

    View full-size slide

  6. MY

    AWESOME

    SERVICE

    View full-size slide

  7. WORLD

    WIDE

    WEB

    View full-size slide

  8. INTERNET

    OF

    THINGS

    INTERNET

    OF

    THINGS

    View full-size slide

  9. CLIENT
    MY

    AWESOME

    SERVICE

    View full-size slide

  10. MOBILE
    “In 2013, the number one reason APIs are
    deployed, is to support mobile development.”

    !
    – Kin Lane

    View full-size slide

  11. SERVER

    EVOLVES

    INTERFACE

    CHANGES

    View full-size slide

  12. Interface Changes

    =

    Client Breaks
    SITUATION in 2014

    View full-size slide

  13. REDEPLOY THE CLIENTS!!!

    View full-size slide

  14. • 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

    View full-size slide

  15. SERVER EVOLUTION

    vs.

    CLIENT LONGEVITY

    View full-size slide

  16. SOLUTION in 2014

    View full-size slide

  17. We freeze the evolution so
    clients can live longer.

    View full-size slide

  18. We can do better.

    View full-size slide

  19. • 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

    View full-size slide

  20. • 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

    View full-size slide

  21. DISTRIBUTED

    HYPERMEDIA
    SYSTEM

    View full-size slide

  22. HOW DOES IT WORK?

    View full-size slide

  23. 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

    View full-size slide

  24. • 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

    View full-size slide

  25. !
    • 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

    View full-size slide

  26. THIS IS HOW WEB WORKS!

    View full-size slide

  27. HOW DO I GET

    STATES TRANSITIONS?
    Hint: How does the web work?

    View full-size slide

  28. • 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

    View full-size slide

  29. 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

    View full-size slide

  30. 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

    View full-size slide

  31. 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”

    View full-size slide

  32. • 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

    View full-size slide

  33. FizzBuzz
    FBAAS AUTOMATON
    API root
    • Number

    • Answer
    First FizzBuzz
    Last
    Next

    View full-size slide

  34. 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

    View full-size slide

  35. 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

    View full-size slide

  36. 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

    View full-size slide

  37. DECOUPLED APPROACH
    • Without redeploying clients
    • change URLs

    • change the algorithm

    • control the number of API calls (through
    embedding)

    • add / extend or modify the functionality

    View full-size slide

  38. DEMO
    iOS Client for FizzBuzz service

    View full-size slide

  39. Everyone has to do

    his / her

    part.

    View full-size slide

  40. DEMAND REASONABLE

    API DESIGN

    NOW!

    View full-size slide

  41. • 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

    View full-size slide

  42. • 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

    View full-size slide

  43. 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

    View full-size slide