Question 1

What is async* and how does it differ from a StreamController?

Accepted Answer

async is a generator function returning a Stream: each yield is an event, the body may await, and yield delegates to another stream. Build the difference on backpressure — that is what separates this answer from an average one: In an async, when the listener calls pause() the body stops at the next yield, and cancel() stops it entirely. Production rate adapts to consumption rate. A StreamController slows nothing: add calls pile into a buffer and memory grows. You have to implement backpressure yourself. The second difference is resource cleanup: a try/finally in an async runs its finally even when the subscription is cancelled — the reliable way to close a file or a socket. With a controller you write the same thing by hand in onCancel. Wrap up with the selection rule: *if my code produces the values, async; if events arrive from outside (a callback API, a platform channel, an event bus), StreamController.** That single sentence signals real experience.

Question 2

What is the difference between map and asyncMap?

Accepted Answer

map performs a synchronous transform. Give it an async function and the result is a Stream> — the events are Future objects and nobody awaits them. That is a real bug: the code compiles, but you get Instance of Future instead of values. asyncMap awaits the result for each event and emits the plain value. Then state the critical detail that many candidates miss: asyncMap is not parallel and preserves order. An event arrives, the function is awaited, the result is emitted, and only then is the next event processed. So 3 events × 200 ms is 600 ms, not 200 ms. Often that is exactly what you want (when order matters), but it can also surface as a performance problem. If you need parallelism, list the options: collect with toList() and Future.wait; rxdart's flatMap (parallel, but order is not preserved); or asyncExpand. The choice comes down to "does order matter?". Add one more point: if the asyncMap function throws, the error is forwarded into the stream as an error event and, by default, the subscription is not cancelled — you handle that with handleError.

Question 3

How would you build debounce for a search field, and how does it differ from throttle?

Accepted Answer

Start from the problem: the user types "flutter" — that is 7 events and, in naive code, 7 network requests. The results can also arrive out of order: the "flu" request may return after the "flutter" one and repaint the screen with stale results. The debounce solution: on each event I cancel the previous timer and start a new one; when the timer fires (i.e. the user has not typed for 300 ms) the last value is emitted. One request. In Dart you write it with StreamTransformer.fromHandlers plus a Timer, or take rxdart's debounceTime. Throttle is a different rule: at most one value per interval, with the ones in between dropped. That is bad for search (requests still fire for intermediate values) but right for scroll position, sensors or progress updates — there you want to cap the frequency, not wait for a pause. To complete the answer, mention the two problems that remain after debounce: Stale responses (races). Debounce reduces the number of requests but does not eliminate them. So I validate the result against a request id, or use switchMap so a new request cancels the previous one. Empty and very short queries. where((q) => q.trim().length >= 2) and distinct() — both cheap and very effective. Showing all three layers moves the answer from "I know the pattern" to "I have built this in production".

Question 4

What is backpressure and how does it work in Dart streams?

Accepted Answer

Definition: backpressure is how a system protects itself when the producer outruns the consumer. Without it, events pile up in a buffer and memory grows without bound. In Dart it depends on the source — making that distinction is the core of the answer: *Single-subscription stream + async generator: genuine backpressure. When subscription.pause() is called (or while the body of an await for loop is still running), the generator suspends at its next yield. File and socket reads behave the same way — reading stops. This is one of the nicest details in the language. StreamController: no backpressure. add always succeeds and events go into an internal buffer. Fast producer plus slow consumer means growing memory. Using controller.sink.addStream(...) helps partly, since it awaits completion. Broadcast stream:* the source never pauses; pause only means buffering for that one listener. List the practical remedies: move to an async generator (simplest and most correct); reduce event frequency with throttle/sample; batch with buffer/bufferTime and process in groups; a conflate-style rule that drops older values and keeps only the latest (ideal for UI updates); and, as a last resort, deliberately dropping events. Finish with a real example: an accelerometer emits 200 events per second while the UI runs at 60 fps — processing every event is pointless, and sample(Duration(milliseconds: 16)) is the right answer. Speaking in concrete numbers lands very well on this question.

Question 5

When do you write a StreamTransformer, and why are the built-in operators not enough?

Accepted Answer

First draw the boundary: map, where, take, expand, asyncMap are event-by-event, stateless (or barely stateful) transforms. They fall short when you need: Time-based logic: debounce, throttle, sample, timeout-with-fallback. These require a Timer and internal state. Grouping events: buffer (by count or by duration), window, pairwise. Re-shaping one event into several or vice versa — assembling bytes into lines, for instance. Dart's own utf8.decoder and LineSplitter are exactly StreamTransformers; citing that grounds the answer nicely. Error handling woven into the event flow — logic more complex than handleError. Show the two ways to write one: StreamTransformer.fromHandlers(handleData:, handleError:, handleDone:) — quick, for simple cases. StreamTransformer.fromBind((stream) async* { ... }) — a full generator inside; more readable for complex state and it brings backpressure for free. Add an important warning: in a fromHandlers transformer, forgetting sink.close() in handleDone means the stream never ends, and a pending Timer must be cancelled there too or it leaks. Close with a practical stance: in a real project I look at rxdart first — debounceTime, throttleTime, switchMap and bufferTime are already written and well tested. I write my own transformer only for domain-specific logic. That sounds more mature than "I would write everything myself".

Operator	What it does	Watch out
`map(f)`	Transforms each event synchronously	If `f` is async you get a stream of `Future`s — use `asyncMap`
`where(test)`	Drops events failing the test	Fewer events, but `done` still arrives
`take(n)` / `skip(n)`	Takes / skips the first `n` events	`take` cancels upstream once the count is reached
`distinct()`	Drops consecutive duplicates	It remembers no history — `a, b, a` passes all three
`asyncMap(f)`	Awaits `f` for each event and preserves order	Not parallel — a slow `f` throttles the whole stream
`expand(f)`	Expands one event into many	Synchronous; if you need async, write an `async*`
`transform(t)`	Applies a fully controlled `StreamTransformer`	For time-based logic such as debounce, throttle, buffer

async*, yield and transformations

📚 Sources and documentation