Question presented to candidate: "You own the chat UI for our assistant. Walk me through how the model's tokens get from the provider to the user's screen: the transport you would use, how you parse it safely, what happens when the user hits Stop, and what happens when their connection drops halfway through an answer."
What a strong answer should cover:
- The path is browser โ your server โ provider (keys never reach the browser); your server re-streams rather than accumulating, usually as SSE over a
fetchPOST read with a stream reader, since the browserEventSourceAPI only does GET with no custom headers or body - Three different "chunks": network reads, SSE events and tokens; a correct client keeps a carry-over buffer, dispatches events on the blank line, and decodes UTF-8 with a streaming decoder so a character split across reads is not corrupted
- Abort as a chain:
AbortControllerin the browser, the request signal on the server, and the provider SDK's abort or signal option, so a Stop actually stops generation and billing - Resume needs two things: event ids the client can echo back (
Last-Event-IDor a sequence number) and generation decoupled from the request, writing to a store such as Redis that a reconnecting client can replay; client-side dedupe by id - The tension between abort and resume: once generation outlives the connection, a client abort is just a disconnect, so Stop needs its own server endpoint; plus rendering concerns (batching updates, tolerant markdown) and persisting partial answers
Clarifying questions expected:
- Must an answer survive a page reload or a phone switching networks, or is "show an error and let them retry" acceptable?
- Where does this run: a long-lived Node server, serverless functions with time limits, behind which proxies or CDN?
- Are answers long (minutes of agent work) or short chat turns, and do we pay for abandoned generations?
Code / implementation expected: Yes โ an SSE parser that handles split chunks, plus an abort path; a sketch of the resume endpoint is a plus.