The checkout experience is usually the one part of the application that delivers the most value, but unfortunately, it's the one that usually contains the most friction. We've all been victims of this: a checkout experience that has spinner that spins indefinitely, or one that warns you to not move a muscle while the next page is loading, or even one that makes a double reservation. Now that you have your shiny new micro-services architecture running and you're able to deploy new features and fixes several times a day, how do you deliver complex transactions to your customers? How do you deliver payments, trip reservations or purchasing an entire shopping cart with a good user experience? HTTP has taken us far, but it's probably not the best transport to deliver complex transactions like these, specially when these transactions are performed over flaky mobile networks. A lot of error-handling logic must fall on the client: How does the client react to timeouts? Or gateway problems? Can it assume the transaction failed with no fear of duplication? Can the transaction survive client crashes? Can the client solve all these existing edge cases without making it overly complex and bug-prone? This talk proposes an original architecture style that will sit in front of your micro-service stack and that you can attach to any existing service back-end. The author will show an implementation of this architecture pattern: a proof-of-concept application and a set of client and server open-source libraries built on top of PouchDB, and Node.js.

1. HI!

2. WHO AM I?
▸Pedro Teixeira
▸@pgte
▸Partner and Chief Futurist @ YLD
▸Node.js Developer
▸Offline-first enthusiast

5. HOW TO BUILD A
RELIABLE CHECKOUT
EXPERIENCE

6. …USING NODE.JS,
POUCHDB AND
REPLICATED TRANSACTION
DOCUMENTS

7. E-COMMERCE

8. THE CHECKOUT
EXPERIENCE

9. IS A JOURNEY THAT BEGINS
WITH THE OPTIMISTIC
CHECKOUT BUTTON

10. BUT ONLY REALLY
BEGINS WITH THE
CONFIRMATION BUTTON

11. BEHIND THE
SCENES…

12. WHICH
EVENTUALLY END
IN SUCCESS

13. AND A
CONFIRMATION
E-MAIL

14. WHAT
CAN GO
WRONG?

15. DUPLICATE
TRANSACTIONS

16. UNDEFINED
STATE

17. CLIENT
CRASHES

18. LET’S TALK
ABOUT
MOBILE

20. https://youtu.be/aqvz5Oqs238
(LAST SLIDE TAKEN FROM
ILYA GRIGORIK’S GOOGLE
IO TALK)

21. MAIN TAKEAWAY IS
DEVELOPING RELIABLE
MOBILE APPS IS
PARTICULARLY DIFFICULT

22. SOLUTION?

23. HELLO
OFFLINE-
FIRST!

24. SERVICE
WORKERS

25. HTTPS://WWW.YOUTUBE.COM/WATCH?V=CMGR0RSZHC8

26. DATA
AND
TRANSACTIONS

27. LET’S GRADE
HOW APPS DEAL WITH
NETWORKING FAILURES

28. E
NO ERROR
HANDLING

30. D
CUSTOMER IS NOTIFIED
OF THE ERROR

31. C
CUSTOMER CAN RECOVER
FROM ERROR

32. B
APP CAN RECOVER FROM
SOME SYSTEM ERRORS

33. A
APP CAN RECOVER FROM SOME
SYSTEM AND USER ERRORS

35. LAST STAGE IS
PARTICULARLY
EXPENSIVE

36. WHY?

37. LET’S LOOK AT
SYSTEMS
ARCHITECTURE

42. TOO MUCH
RESPONSIBILITY

43. HTTP
IS THE WRONG LEVEL
OF ABSTRACTION

44. “WORKS ON MY LAPTOP”

45. BUT
WAIT…

46. ALL WE NEED IS
SYNC

48. WHICH
SYNC
PROTOCOL?

51. ‣OPEN-SOURCE
‣DOC-ORIENTED
‣MVCC
‣CHANGES FEED
‣REPLICATION
PROTOCOL

58. ONE DATABASE
PER CUSTOMER

59. ONE DOCUMENT PER
TRANSACTION

60. SYNC PROTOCOL REPLICATES
TRANSACTION DOC
(BI-DIRECTIONAL)
= OFFLINE TOLERANCE

61. THE CLERK
[MISSING IMAGE]

62. CLERK REACTS TO
TRANSACTION
STATE CHANGES

64. CLERK INJECTS
TRANSACTION STATE
CHANGES
(WHEN BACK-END EVENT OCCURS)

65. SHOW ME
THE CODE!

66. UI

67. POUCH-REDUX-MIDDLEWARE

69. BACK-END

70. POUCH-CLERK

71. CLERK
1. STATE TRANSITIONS
2. ASYNC UPDATERS

72. STATE
TRANSITIONS

74. ASYNC
UPDATERS

76. QUICK
DEMO

77. DEMO IS ALSO OPEN SOURCE
https://github.com/
pgte/pouch-clerk-example-app

78. FUTURE?

79. ‣ LONG-RUNNING TRANSACTIONS
‣ COLLABORATIVE GAMES
‣ …
SUPPORT FOR

80. SLIDES
http://www.slideshare.net/pgte/how-to-build-a-reliable-checkout-
experience-66857209

81. THANK
YOU!

82. QS?