Event-Driven Architecture for PWA

Publication date: 2021-12-30

When exploring Server-Sent Events, sooner or later one reaches Event-Driven Architecture (EDA). In fact, EDA is native to web applications. We use it almost without noticing whenever we put JavaScript behavior into HTML:

<button onclick="myFunction()">Click me</button>

Browser and user interaction is event-based, so event-driven thinking is intuitive to almost every web developer.

Browser-server interaction is equally familiar: the browser sends a request and receives the result of the requested action.

That is the essence of HTTP: send a request, receive a result.

In 2004, Ian Hickson proposed stretching the server response over time, creating a stream and processing its result in parts as information arrives. That idea became the Web API called Server-Sent Events.

The server can now stream information to the client and reflect processes taking place on the server. Seen through EDA, the server is an event producer, the browser is a subscriber, and the HTTP connection plus code at both ends is the event-processing mechanism or queue.

This design requires asynchronous data handling and resilience to losing individual events. It naturally suggests a return stream of browser requests confirming that corresponding server events were received.

A browser can send receipt confirmations with ordinary POST requests to one service for all events, including the event ID. But confirmation alone does not solve delivery loss: the confirmation can also disappear. The application must tolerate a lost message. If an expected reaction does not occur within an acceptable interval, it sends the event again; subscribers decide whether they already handled it or missed it.

The more interesting step is to treat that confirmation channel as an inverted SSE stream and send browser-to-server messages asynchronously too. Rather than many synchronous web services for different actions, the application has two channels: a forward channel receiving messages from the browser and a return channel sending server events to the browser.

This model suits mobile PWAs that must work offline. They keep working data on the client in localStorage or indexedDb and exchange data with the server whenever possible. The entire Web API can then be reduced to two services: open the server-event channel and report a browser event to the server.

For applications built this way, synchronous request-response technologies such as REST, GraphQL, and gRPC become less central. I do not claim that EDA replaces them. For mobile PWAs that repeatedly move between offline and online states, event streams can fit better; for ordinary web applications with stable internet, established request-response technologies remain more predictable.