Bài này nói về networking frontend mức senior: browser nói chuyện với backend thế nào. Người phỏng vấn không thuê bạn vì “WebSocket is full-duplex”. Bạn ghi điểm khi chọn được REST hay GraphQL hay SSE hay WS, đặt auth đúng transport, và kể được loading, CORS, và abort. Vue 3 / Nuxt ($fetch, useAsyncData) trước; ràng buộc là HTTP và browser, không phải framework.

Đọc 13.1 trước (bảng so sánh và thuế socket). Rồi 13.2–13.3 cho contract và bốn state UI. 13.4 là CORS và cookie từ phía frontend. 13.5 là abort và timeout. Xem JavaScript 1.2.7 cho ví dụ search-race AbortController; topic này không lặp lại. React Query / Next dùng cùng rule HTTP.

Tóm tắt: REST (hoặc RPC-over-HTTP) là request/response. SSE đẩy một chiều. WebSocket hai chiều. GraphQL là query contract trên HTTP, không phải socket. Chọn transport cho sản phẩm, không vì mốt.

Vì sao quan trọng: Người phỏng vấn không thuê bạn vì “WebSocket is full-duplex”. Bạn ghi điểm khi từ chối socket chỉ để né REST, đặt auth trên transport browser hỗ trợ, và kể được chuyện sau khi đóng nắp laptop: reconnect với cursor, không replay toàn bộ.

1. Cách hoạt động: Combo mặc định: REST (hoặc RPC-over-HTTP) cho lệnh và snapshot đầu. Thêm kênh push chỉ khi polling sẽ làm hỏng product, không phải vì “HTTP chậm”.
2. HTTP/1.1 cho khoảng sáu connection mỗi origin và head-of-line blocking. HTTP/2 multiplex nhiều stream trên một TCP connection, nên useAsyncData song song rẻ trên wire. Bạn vẫn trả thời gian server và kích thước payload. HTTP/2 không sửa JSON 2 MB cho table, và TCP HOL vẫn còn (HTTP/3 / QUIC là bước tiếp).
3. GraphQL là contract BFF (Backend for Frontend: một origin gom) ở edge, không phải lớp thay thế hổng cho mọi microservice. Nó thắng ở dashboard mà REST sẽ waterfall 12 call. Trang marketing cache trên CDN vẫn muốn REST/JSON hoặc HTML Nuxt. Persisted query trở thành bắt buộc khi graph public.
4. SSE (Server-Sent Events: một HTTP GET server cứ ghi) đủ cho notification và log. WebSocket hai chiều: chat, collab, stream từ client lên server. Polling (hoặc long-polling khi SSE bị chặn) là fallback thành thật. Đừng thiết kế long-polling trước.
5. Browser new WebSocket(url) không gắn được header Authorization. Gửi cookie trên handshake khi FE và API chung site cha (refresh HttpOnly dùng được; CSRF phải nêu rõ). Token trên ?access_token= rơi vào access log, proxy, và Referer. Ưu tiên connect, rồi message đầu { type: "auth", token }; server từ chối mọi thứ khác đến khi auth xong, và timeout socket chưa auth.
6. Reconnect bằng exponential backoff kèm jitter, chặn trần delay, reset sau lần open ổn định. Heartbeat tầng application nếu nginx proxy_read_timeout là 60s. Resume bằng Last-Event-ID (SSE) hoặc cursor bạn tự tạo (WS). Khi có BFF: browser → BFF → services. Một origin, cookie first-party, gom dữ liệu ở đây. SSR không giữ WS cho user.

export function connectChat(url: string, token: string, lastId: string) {
  const ws = new WebSocket(url) // cookie đi theo handshake; không có header Authorization
  let delayMs = 1000
  let beat: ReturnType<typeof setInterval> | undefined
  ws.addEventListener("open", () => {
    ws.send(JSON.stringify({ type: "auth", token, lastId })) // auth bằng message đầu
    delayMs = 1000
    beat = setInterval(() => ws.send(JSON.stringify({ type: "ping" })), 25_000)
  })
  ws.addEventListener("close", () => {
    clearInterval(beat)
    const jitter = Math.random() * 400
    setTimeout(() => connectChat(url, token, lastId), delayMs + jitter)
    delayMs = Math.min(delayMs * 2, 30_000) // trần; reset sau lần open ổn định
  })
  return ws
}

Điều gì xảy ra: Constructor không gửi được Authorization. Auth là frame JSON đầu; trước khi nó tới, server phải bỏ mọi message khác. Lúc close, delay nhân đôi kèm jitter đến 30s để reconnect hàng loạt không stampede. lastId là cursor resume: SSE thì gửi Last-Event-ID. Ping 25s giữ nginx khỏi giết timeout idle 60s.

Lỗi hay gặp

• Token trên query string WebSocket. Triệu chứng: token trong access log và Referer. Nguyên nhân: constructor không có API header. Sửa: cookie handshake hoặc auth message đầu; đừng log frame.
• “Cần WS vì HTTP chậm”. Triệu chứng: stack chat cho refresh dashboard. Nguyên nhân: folklore HTTP/1. Sửa: đo payload và TTFB; stream HTTP/2 đã multiplex.
• Reconnect không jitter và replay hết. Triệu chứng: thundering herd sau blip; UI trùng hàng. Nguyên nhân: delay = 1000 cho mọi người, không cursor. Sửa: backoff + jitter + lastId.
• Browser nói trực tiếp với farm WS inventory. Triệu chứng: CORS, domain cookie, authz từng service. Nguyên nhân: bỏ BFF. Sửa: một origin; BFF subscribe nội bộ.

Tóm tắt: Từ frontend, REST là contract của màn: id ổn định, filter trên query param share được, error envelope để UI rẽ nhánh, pagination khớp widget, và idempotency key trên tiền.

Vì sao quan trọng: Người phỏng vấn hỏi “nếu đổi được API, bạn nhờ backend điều gì?” Họ muốn màn hình, lỗi, pagination, và double-submit, không phải chuyện danh từ REST cho đúng sách. Browser sẽ retry, double-click, và mất tab.

1. Cách hoạt động: Đặt tên resource bằng id ổn định (ord_1, không phải index hàng). List DTO nên đã join ở BFF để table không bắn ba API mỗi hàng. Luôn trả { items, nextCursor, total? }.
2. Pagination cursor / keyset cho feed và infinite scroll (không skip/trùng khi list đổi). Offset/limit cho bảng admin nhảy trang. total là ước lượng thì đừng render như số chính xác: giấu hoặc gắn nhãn.
3. Error envelope: { error: { code, message, fields } }. Map status cho luồng điều khiển: 401 session, 403 quyền, 404 đã mất khác với chưa từng có, 409/412 conflict, 422 lỗi field, 429 + Retry-After, 5xx chỉ retry nếu idempotent. Đừng parse chuỗi message dành cho người đọc.
4. POST create/pay gửi Idempotency-Key và retry cùng key. disabled={loading} chưa đủ: refresh vẫn double-post. PATCH + If-Match cho conflict optimistic. Version additive; /v2 chỉ khi reshape gãy.
5. Filter nằm trên query string để URL share được. Search phức tạp không thể ngắn và cache được thì thành POST /search. Upload file: URL presigned, không JSON 200 MB xuyên Nuxt. Whitelist sort/filter: không query kiểu SQL từ URL.

type OrdersPage = {
  items: Array<{ id: string; total: number; status: string }>
  nextCursor: string | null
  total: number | null // ước lượng: đừng render như số chính xác
}
type ErrorBody = {
  error: { code: "QUOTE_EXPIRED" | "FORBIDDEN"; message: string; fields?: Record<string, string> }
}
// GET /api/orders?status=open&cursor=abc  filter share được
// POST /api/pay  header Idempotency-Key: <uuid>  retry cùng key
// 422 → vẽ fields.coupon; đừng parse error.message cho luồng điều khiển

Điều gì xảy ra: List có shape của màn: id, cursor, total tùy chọn. Quote hết hạn là QUOTE_EXPIRED, không phải toast câu tiếng Anh. Pay retry cùng Idempotency-Key nên 200 bị mất không charge hai lần. Filter trên query string để PM dán được URL.

Lỗi hay gặp

• Ghép ba API mỗi hàng table. Triệu chứng: waterfall, N+1. Nguyên nhân: bám resource thuần REST. Sửa: list DTO ở BFF đã join.
• Offset pagination trên feed live. Triệu chứng: hàng bị skip hoặc trùng. Nguyên nhân: insert dịch offset. Sửa: cursor/keyset; giữ offset chỉ cho nhảy trang.
• Retry POST lúc 500 không key. Triệu chứng: charge hai lần. Nguyên nhân: “retry 5xx”. Sửa: Idempotency-Key; chỉ retry đúng key.
• Nhánh UI theo message tiếng Anh. Triệu chứng: i18n và highlight field chết sau lần sửa copy. Nguyên nhân: không code. Sửa: envelope có code.

Tóm tắt: Mọi view async là một state machine nhỏ: loading, error, empty, success. Thêm stale khi refetch vẫn giữ hàng cũ, và optimistic khi bạn đoán trước. Encode state tường minh. Đừng trộn data && !error && !pending thành một súp boolean.

Vì sao quan trọng: “API chậm / flaky, UI chạy thế nào?” là câu hỏi product mặc áo networking. Spinner 150 ms còn tệ hơn không hiện gì. Hàng optimistic sai mà không rollback được còn tệ hơn chờ 300 ms. Empty không phải error, cũng không phải filter ra zero hàng.

1. Cách hoạt động: Load lần đầu: skeleton khớp layout để CLS (Cumulative Layout Shift) thấp. Trễ spinner ~200 ms. Refetch: giữ hàng cũ kèm indicator nhẹ. Đó là stale-while-revalidate trên UI, không phải màn trống.
2. Bỏ response thua race bằng AbortController (xem 13.5 và JavaScript 1.2.7). Retry 5xx và lỗi mạng với backoff; đừng retry 4xx trừ 429. Lỗi cấp widget kèm nút retry; đừng làm trắng shell.
3. Copy empty (“chưa có đơn”), copy error (“không tải được đơn”), và copy zero-filter (“không đơn nào khớp”) là ba chuỗi. if (!data) mà coi [] là error là chỗ sai kinh điển.
4. Optimistic UI chỉ khi rollback rẻ (toggle, rename). Thanh toán thì pessimistic. Snapshot cache, mutate, roll back lúc 409/5xx, toast sự thật. Nhiều tab cần BroadcastChannel hoặc query broadcast. Key cache theo user/tenant, không thì quyền stale sau login.

async function onToggleDone(id: string) {
  const key = ["orders", userId] // key theo user, không thì quyền stale
  const snapshot = queryClient.getQueryData(key)
  queryClient.setQueryData(key, optimisticToggle(snapshot, id)) // đoán
  try {
    await $fetch(`/api/orders/${id}`, { method: "PATCH", body: { done: true } })
  } catch (err) {
    queryClient.setQueryData(key, snapshot) // rollback
    toast.error("Could not update — still not marked done")
    throw err
  }
}
// thanh toán thì pessimistic: await POST /pay, rồi invalidate, không đoán

Điều gì xảy ra: Toggle vẽ ngay từ snapshot. 409 hoặc 5xx khôi phục snapshot và nói sự thật. Cache key gồm userId nên login bằng role khác không giữ được bộ quyền trước đó. Pay không nằm trong hàm này. Tiền phải chờ server.

Lỗi hay gặp

• if (!data) lúc success mà empty. Triệu chứng: “không tải được” trên account mới. Nguyên nhân: nghĩ [] gần falsy. Sửa: pending, data, error là ba field riêng.
• Optimistic Pay. Triệu chứng: charge hai lần hoặc success giả. Nguyên nhân: rollback không rẻ. Sửa: chờ 2xx; idempotency key; rồi invalidate.
• Cache không key theo user. Triệu chứng: sau login, hàng tenant trước nháy lên. Nguyên nhân: ["orders"]. Sửa: ["orders", userId].
• Lỗi cả shell. Triệu chứng: header và nav chết cùng widget. Nguyên nhân: một pending cho cả trang. Sửa: lỗi tại widget; retry tại đó.

Tóm tắt: CORS (Cross-Origin Resource Sharing) là rule của browser: JavaScript trên origin A chỉ đọc được response từ origin B khi B opt-in. Ưu tiên browser → BFF cùng site để CORS và cookie third-party biến mất. CORS không chặn curl.

Vì sao quan trọng: “Chạy được trên Postman mà gãy trên Chrome” là topic này. “Vì sao cookie không được gửi?” cũng vậy. Gán Access-Control-Allow-Origin: * kèm cookie là bất hợp pháp trên browser và không phải authorization. Preview deploy làm nổ origin.

1. Cách hoạt động: Origin là scheme + host + port. localhost và 127.0.0.1 khác nhau. Một GET/POST simple với Content-Type trong safelist và không custom header thì bỏ qua preflight. Authorization, Content-Type: application/json, hoặc credentials: "include" kích OPTIONS preflight.
2. Preflight hỏi Access-Control-Request-Method và Access-Control-Request-Headers. API phải trả một Access-Control-Allow-Origin cụ thể (không * nếu có cookie), Allow-Credentials: true khi bạn gửi cookie, và Allow-Headers liệt kê header của bạn. Browser rồi mới gửi GET thật.
3. Frontend: fetch(..., { credentials: "include" }) hoặc axios withCredentials. Cờ cookie: Secure, HttpOnly cho session, SameSite=Lax mặc định; SameSite=None; Secure chỉ cho case cross-site thật bạn không BFF được. Cookie third-party đang chết. Đừng thiết kế sản phẩm mới dựa vào chúng.
4. BFF cùng site (Nuxt/Nitro) để browser nói với một origin. Cookie vẫn first-party. Gom dữ liệu và auth cookie-sang-service nằm trên server. Proxy Vite giấu CORS lúc dev rồi bất ngờ lúc preview. Hãy test origin thật.

export async function loadMe() {
  const res = await fetch("https://api.internal.example/me", {
    method: "GET",
    credentials: "include", // gửi cookie first-party
    headers: { "X-Requested-With": "app" }, // custom header → preflight
  })
  if (!res.ok) throw new Error(String(res.status))
  return res.json()
}
// Network: OPTIONS, rồi GET. Allow-Origin phải khớp, không phải *
// Allow-Credentials: true. CORS không chặn curl hoặc WebView mobile.

Điều gì xảy ra: Custom header buộc OPTIONS. Nếu API trả * kèm credentials, Chrome chặn còn Postman vẫn trông ổn. credentials: "include" là cách cookie rời browser. BFF cùng site sẽ biến đây thành fetch("/api/me") và cuộc nói chuyện này kết thúc.

Lỗi hay gặp

• Proxy Vite lúc dev, preview gãy. Triệu chứng: “CORS chỉ trên staging”. Nguyên nhân: proxy giấu preflight. Sửa: gọi origin API thật trên preview.
• Cookie Domain=.example.com rò preview ↔ prod. Triệu chứng: lẫn session. Nguyên nhân: một domain cha. Sửa: cookie host-only; OAuth client tách riêng.
• Quên credentials: "include". Triệu chứng: 401 sau login “chạy được” trên Postman. Nguyên nhân: browser không gửi cookie. Sửa: include + SameSite khớp navigation.
• Coi CORS là tường lửa API. Triệu chứng: không CSRF, không authz, * trên prod. Nguyên nhân: nhầm rule đọc của browser với bảo mật. Sửa: BFF + CSRF + authz thật.

Tóm tắt: AbortController hủy fetch đang bay (và mọi thứ nhận signal). Abort GET đã hết liên quan. Timeout mọi request, kể cả mutation, bằng AbortSignal.timeout. Đừng abort Pay lúc unmount: giữ idempotency key.

Vì sao quan trọng: User gõ nhanh hoặc rời trang. 200 muộn từ query #1 ghi đè query #2. fetch không timeout mặc định, nên TCP treo thành spinner vô hạn. Abort mù Pay lúc unmount là cách bị charge mà không còn UI. JavaScript 1.2.7 đã hiện race typeahead; topic này không lặp component đó.

1. Cách hoạt động: Tạo controller, đưa signal vào $fetch / fetch. Abort trong cleanup watch hoặc lúc rời route cho search và filter. Ghép signal: AbortSignal.any([routeSignal, AbortSignal.timeout(8_000)]) để route hoặc timer thắng. (AbortSignal.any có trên Chromium / Firefox / Safari 17.4+ hiện đại; polyfill hoặc nối AbortController nếu phải hỗ trợ bản cũ.)
2. AbortSignal.timeout(ms) abort với TimeoutError (một DOMException). Nuốt AbortError / TimeoutError cho search; hiện 5xx thật. Adapter axios không chuyển signal sẽ im lặng bỏ abort. Hãy kiểm chứng một lần.
3. Đừng abort POST /pay /save lúc unmount. Giữ Idempotency-Key và để request chạy xong; reconcile khi view mount lại. Optimistic UI kèm abort: nếu đã đoán rồi abort, bạn phải rollback, không thì là dối.
4. Timeout WebSocket là heartbeat, không phải AbortController. Promise.race với timer mà không abort fetch vẫn tốn connection và vẫn áp 200 muộn trừ khi bạn bỏ qua. Hãy abort signal.

export async function searchOrders(q: string, routeSignal: AbortSignal) {
  const signal = AbortSignal.any([routeSignal, AbortSignal.timeout(8_000)])
  try {
    return await $fetch("/api/orders", { query: { q }, signal })
  } catch (err) {
    const name = (err as DOMException).name
    if (name === "AbortError" || name === "TimeoutError") return null
    throw err
  }
}
// JavaScript 1.2.7 hiện watch() abort typeahead lần trước.
// Đừng abort POST /pay lúc unmount: hãy giữ Idempotency-Key.

Điều gì xảy ra: Hoặc rời route hoặc timer 8s abort GET. AbortError / TimeoutError thành null để caller giữ lại các hàng tốt lần trước. 500 vẫn throw. Pay không nằm trong helper này: unmount không được hủy tiền. Pattern watch typeahead nằm ở JavaScript 1.2.7.

Lỗi hay gặp

• Abort Pay lúc unmount. Triệu chứng: đã charge, UI nghĩ đã hủy. Nguyên nhân: onBeforeUnmount(ac.abort) dùng chung. Sửa: abort đọc, không phải tiền; giữ key.
• Timeout Promise.race không abort. Triệu chứng: spinner dừng, 200 muộn vẫn ghi. Nguyên nhân: fetch còn sống. Sửa: đưa signal.
• Axios không chuyển signal. Triệu chứng: abort “không làm gì”. Nguyên nhân: adapter. Sửa: signal trên request; chứng minh trên Network.
• Copy watch search 1.2.7 vào đây và gọi là chuyện timeout. Triệu chứng: hai ví dụ giống nhau. Nguyên nhân: topic chồng. Sửa: topic này là timeout + ghép + đừng-abort-Pay.