Post on 22-Jan-2018
DELIVERING A BETTER TRANSACTION
EXPERIENCE TO YOUR CUSTOMERS BY USING
REPLICATED DOCUMENT-DRIVEN
TRANSACTIONS
DIGITAL CHECKOUT
EXPERIENCE
THE DUPLICATE TRANSACTION
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
I’LL BE TALKING ABOUT…
▸ What’s wrong with HTTP APIs for performing transactions?
▸ Proposed solution: Replicated Transaction Documents
▸ A Clerk working on the customer behalf
▸ Demo
WHO AM I?
▸ Pedro Teixeira
▸ @pgte
▸ Partner and Chief Futurist @ YLD
▸ Node.js Developer
▸ Offline-first enthusiast
MOBILE NETWORKS SUCK!
Ilya Gregorik
TEXTO
BLAME HTTP
the use of
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
WHAT’S WRONG WITH HTTP APIS?
▸ AJAX and RESTful HTTP services have taken us far
▸ In the context of fulfilling a transaction, what happens when an API call fails?
▸ How to react to timeouts / gateway errors / session is lost?
▸ Client code has to handle all the error and related corner cases, persist session, resume session, etc..
▸ Hard to test
TEXTO
LONG-RUNNING TRANSACTIONS
▸How do we support long-running transactions?
▸ Polling
▸ Push (SSE, websockets, XHR LP, …)
▸ ^^ All these exponentially increase the complexity of the client app (and back-end)
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
WHY?
▸ The proposed solution is nothing new!
▸ But I find that the HTTP API is so ingrained in the developer culture
▸ ^^this, combined with “works fine on my laptop” mentality
▸ Consistently delivers poor customer experience
▸ So I think we need to frame a new abstraction that makes this easier to developers to reason about
A NEW ABSTRACTION
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
STATUS AND GOALS
▸ This is mostly a work-in-progress that I’d like to share with you
▸ Up for discussion and improvement
▸ Set of open-source libraries that can be combined (instead of a framework) to achieve these goals
HIGH-LEVEL ARCHITECTURE
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
ONE DOC PER TRANSACTION
▸ Where you store all the data required to
▸ perform the transaction on the server
▸ render the transaction state on the client
▸ Has a state
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
TRANSACTION FLOW
▸ Document is persisted on the client
▸ Document state is changed on the client or on the clerk
▸ Changes are replicated
▸ Clerk reacts to state transitions, performing back-end actions, which result in a new state
REPLICATED DOCUMENT-DRIVEN TRANSACTIONS
TRANSACTION STATE TRANSITIONS
▸ Transaction state transitions are performed either by the clerk or the client for any given state
▸ Avoiding conflicts
▸ (but conflicts can occur and be resolved)
DEMO!
PROGRAMMING MODEL
OPEN-SOURCE
POUCH-CLERK
▸open-source Node.js package
▸https://github.com/pgte/pouch-clerk
▸Works with CouchDB or PouchDB
PROGRAMMING MODEL
CLERK - HANDLE STATE TRANSITIONS
PROGRAMMING MODEL
CLERK - PERFORM ASYNCHRONOUS UPDATES
SOME OPEN-SOURCE
CLIENT
▸open-source Node.js package
▸https://github.com/pgte/pouch-redux-middleware
▸Syncs (2-way) Redux state with a PouchDB database
READ ON
MORE INFO ON
▸ Authentication
▸ Idem-potency
▸ Scheduling and concurrency
▸ Security
http://bit.ly/29WCmCJ
How to build a reliable transaction experience for your customers
http://bit.ly/29WCmCJ
THANK YOU!