← All articles
Jul 24, 2026 · 6 min read

Event-driven mobile: beyond the REST call

Every screen shouldn't have to ask

A typical mobile screen loads data with a GET, shows it, and moves on. That works fine for "what's my balance". It breaks down for "tell me the moment my balance changes" — the kind of requirement that shows up constantly in banking, mobility, and fleet-management apps.

The naive fix is polling: hit the endpoint every few seconds and diff the result. It's simple, and it's also how you turn a calm backend into a denial-of-service target the moment your user base doubles.

Borrowing from event-driven backends

On the backend, this problem was solved years ago with message brokers — RabbitMQ, Kafka — where services publish events instead of waiting to be asked. Mobile can borrow the same mental model without needing a broker client in the app itself:

  • A BFF (Backend for Frontend) subscribes to the domain events that matter to a given app.
  • It exposes a single WebSocket or Server-Sent Events channel to the client.
  • The client subscribes once, and reacts to events as they arrive — no polling loop, no wasted battery.
class BalanceUpdates {
  final EventChannel channel;
  BalanceUpdates(this.channel);

  Stream<Balance> listen() => channel
      .receiveBroadcastStream()
      .map((event) => Balance.fromJson(event));
}

What changes architecturally

Once part of your app thinks in events instead of requests, a few things follow:

  • Screens become reactive, not imperative — they render whatever state the stream currently holds, the same discipline you'd apply to a StreamBuilder anywhere else in Flutter.
  • Offline and reconnection handling becomes a first-class concern, not an edge case bolted on later.
  • Testing gets easier, not harder — you can replay a recorded sequence of events into a fake channel and assert on the resulting UI state, without mocking a dozen REST endpoints.

None of this replaces REST — most reads are still a simple GET. It's a second tool for the specific problem REST was never meant to solve: telling a client something it didn't ask for, the moment it happens.