You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 they're 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.
The text was updated successfully, but these errors were encountered:
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 they're 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.
The text was updated successfully, but these errors were encountered: