Event-Driven User Interfaces: Patterns and Trade-Offs

Introduction

• Event-driven architectures (EDA) are popular in cloud-native development, where data changes trigger actions.
• However, there is often a human element in these systems that can be overlooked, such as users constantly refreshing to check on the status of their order or delivery.
• This session explores technical patterns and trade-offs to implement seamless front-end experiences using various AWS services.

Polling vs. Subscription-based Approaches

• Polling: Front-end periodically calls the back-end to check for updates. Can be slower and less efficient.
• Subscription-based: Client asks the server to notify it when something changes. Typically uses WebSockets.

Architectural Overview

• Events from various services are processed through an event bus (EventBridge).
• A "back-end for front-end" (BFF) service is implemented to handle the orchestration, persistence, and aggregation of data needed by each front-end application.

Patterns Discussed

1. Two-way WebSocket Pattern:

   • Uses Amazon API Gateway WebSocket APIs.
   • Clients connect and disconnect, and the server sends updates to each connected client individually.
   • Trade-offs: Connection management is manual, message fan-out is done in the server, supports public WebSockets.

2. AWS AppSync Pattern:

   • Uses AWS AppSync, a managed GraphQL and WebSocket API service.
   • Data mutations trigger subscriptions to send updates to clients.
   • Trade-offs: Requires learning GraphQL, supports private connectivity, can use direct EventBridge integration.

3. Direct to GraphQL Pattern:

   • Directly integrates EventBridge events to AWS AppSync mutations.
   • Persists data directly in AppSync, avoiding the need for a separate event processing step.
   • Trade-offs: One-way subscriptions, requires careful selection set management.

4. No GraphQL Events Pattern:

   • Uses the new AWS AppSync Events feature, a true pub-sub model without requiring GraphQL.
   • Supports flexible channel namespaces and authorization configurations.
   • Trade-offs: One-way WebSocket, requires separate HTTP API for catch-up.

5. MQTT with AWS IoT Core Pattern:

   • Uses MQTT, a lightweight publish-subscribe messaging protocol, through AWS IoT Core.
   • Publishes events to topics, and clients subscribe to the topics they are interested in.
   • Trade-offs: Single endpoint per account/region, IoT-focused authorization modes.

Long-Running Processes

• Subscription-based approaches work well for long-running processes that take more than 30 seconds.
• Example: Flight search that queries multiple inventory providers in parallel and aggregates the results.

Push Notifications

• Functionally similar to real-time updates, but involves third-party notification services (Apple, Google, etc.).
• Requires client subscription management and filtering of updates to avoid overwhelming users.

Conclusion

• The sample code for all the patterns discussed is available on GitHub.
• Other relevant sessions: "Building Event-Driven Architectures" and "Choosing the Right API Gateway: API Gateway, AppSync, or ALB".