Long-running processes, concurrent editing, operations requiring user intervention, and integration with unreliable external services present new challenges to building web UIs. Building a pleasurable, robust and reliable user experience is more far more challenging when critical pieces of your workflow are out of your direct control.

We’ll begin by describing what a distributed system is, and highlight the new challenges that it presents, compared to a simple traditional system (i.e., background tasks, mobile web or offline use, hard dependencies on third-party services, etc…). Then, we’ll talk about some UI and system architecture patterns, using an Ember.js/Phoenix system as a case study.

Where possible and appropriate, I'll show parts of a real-time distributed system (ember/phoenix), contrasting what the "non-distributed system" approach would have felt like to users against the "distributed system" approach.

As we go, we’ll begin to build a framework of questions that developers can ask themselves in order to address the challenges of high latency, loss of connectivity, the loss of access to a critical third-party service, and other problems often encountered when working with distributed systems.