Frontend Backend Integration Through APIs Questions

Understanding how frontend components interact with backend APIs using HTTP requests (fetch, axios, etc.), handling asynchronous responses and errors, managing data flow from API responses to UI updates. Ability to design APIs that frontend needs and implement corresponding client-side code to consume them properly.

MediumTechnical

53 practiced

Design and describe both backend API and frontend behavior to implement optimistic UI updates for a 'like' toggle on posts. The client should immediately reflect the new state, send the API request to /api/posts/:id/like, handle rollback if the request fails, and the backend must be idempotent and return the canonical like count. Show endpoint design (method, body, response) and client pseudocode that handles optimistic state, temporary IDs, and reconciliation.

Sample Answer

**Backend: API design (idempotent, returns canonical count)**

- Endpoint: POST /api/posts/:id/like- Purpose: Toggle like for authenticated user; idempotent per user action using explicit "action" field or idempotency-key

Request:

json

POST /api/posts/123/like
{
  "action": "like"    // or "unlike"
}

Response (200):

json

{
  "postId": "123",
  "liked": true,           // canonical boolean for this user
  "likeCount": 42,         // canonical count after operation
  "timestamp": "2026-03-02T12:00:00Z"
}

Server rules:- Use upsert on likes table (user_id, post_id) with unique constraint to ensure idempotency.- Compute likeCount with a fast aggregate (cached counter or DB increment/decrement in transaction).- Return canonical liked state and count.

**Client: React pseudocode (optimistic update, temp id, rollback & reconciliation)**

javascript

// state: posts map { id, liked, likeCount, pendingId }
function toggleLike(postId, action) {
  const tempId = generateTempId(); // e.g., client side UUID
  // Snapshot
  const prev = { liked: posts[postId].liked, likeCount: posts[postId].likeCount };
  // Optimistic update
  const optimistic = action === 'like' ? 1 : -1;
  updatePost(postId, {
    liked: action === 'like',
    likeCount: posts[postId].likeCount + optimistic,
    pendingId: tempId
  });

  fetch(`/api/posts/${postId}/like`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ action })
  })
  .then(res => res.json())
  .then(data => {
    // Reconcile with canonical server state
    updatePost(postId, {
      liked: data.liked,
      likeCount: data.likeCount,
      pendingId: null
    });
  })
  .catch(err => {
    // Rollback to snapshot on failure
    updatePost(postId, { ...prev, pendingId: null });
    showToast('Unable to update like. Try again.');
  });
}

Notes:- Use pendingId to ignore out-of-order responses: only reconcile if response corresponds to latest pending action (compare tempId if returned).- For concurrency, server authoritative state wins; client always accepts canonical response to correct drift.

EasyTechnical

52 practiced

As a full-stack developer, design a minimal REST API contract for a Todo application. Provide endpoints, HTTP methods, example request and response JSON for creating a todo, listing todos with pagination parameters, partially updating a todo, and deleting a todo. Include validation rules (required fields, field formats), example status codes, and a small JSON schema snippet for create/update so frontend and backend can align on the contract.

Sample Answer

**API Summary**- Base: /api/v1/todos- Auth: Bearer token (optional for sample)- Content-Type: application/json

**Endpoints**1) Create TodoPOST /api/v1/todosRequest:

json

{
  "title": "Buy milk",
  "description": "2 liters, low-fat",
  "dueDate": "2026-03-10T12:00:00Z",
  "priority": "medium"
}

Response 201 Created:

json

{
  "id": "c9f1a8",
  "title": "Buy milk",
  "description": "2 liters, low-fat",
  "dueDate": "2026-03-10T12:00:00Z",
  "priority": "medium",
  "done": false,
  "createdAt": "2026-03-01T09:00:00Z"
}

2) List Todos (with pagination)GET /api/v1/todos?page=1&perPage=20&done=falseResponse 200 OK:

json

{
  "items": [ { "id":"c9f1a8", "title":"Buy milk", "done":false } ],
  "page": 1,
  "perPage": 20,
  "total": 123
}

3) Partial updatePATCH /api/v1/todos/{id}Request:

json

{ "done": true, "title": "Buy milk and eggs" }

Response 200 OK: returns updated resource.

4) DeleteDELETE /api/v1/todos/{id}Response 204 No Content

**Validation rules**- title: required, string, 1–200 chars- description: optional, string, max 2000 chars- dueDate: optional, ISO 8601 datetime- priority: optional, enum ["low","medium","high"]- done: boolean

**Status codes**- 201 Created, 200 OK, 204 No Content, 400 Bad Request (validation), 404 Not Found, 401 Unauthorized

**Shared JSON Schema (create / update)**

json

{
  "type": "object",
  "properties": {
    "title": { "type": "string", "minLength": 1, "maxLength": 200 },
    "description": { "type": "string", "maxLength": 2000 },
    "dueDate": { "type": "string", "format": "date-time" },
    "priority": { "type": "string", "enum": ["low","medium","high"] },
    "done": { "type": "boolean" }
  },
  "required": ["title"]
}

Notes: Use ETags or updatedAt for concurrency; return Link headers for pagination when necessary.

HardTechnical

55 practiced

Design a machine- and human-friendly API error format that includes correlation IDs, machine-readable error codes, user-facing messages, and optional developer debug info controlled by environment. Describe how you propagate a correlation ID from the browser through backend services and external calls, how you index logs and traces to find root causes, and how you expose errors to SREs without leaking sensitive data to users.

Sample Answer

**Design (error schema)**

I propose a JSON error envelope used by all services and the frontend:

json

{
  "error": {
    "code": "USER_NOT_FOUND",          // machine-readable
    "message": "We couldn't find that user.", // user-facing (localized)
    "correlation_id": "7f8e9a-1234",  // propagated trace/correlation id
    "status": 404,
    "debug": {                         // optional, included only in non-prod
      "stack": "com.example.Service:line 42",
      "internal_code": "DB_READ_TIMEOUT"
    }
  }
}

**Why this shape**- Separate machine code and user message for UIs and automation.- correlation_id ties client request to backend logs/traces.- debug field enabled by environment flag (e.g., NODE_ENV !== "production") or feature-flag per request.

**Propagation of correlation ID**- Browser: on initial page load or SPA navigation, generate UUID if none and attach header "X-Correlation-ID" to all fetch/XHR and WebSocket open. - Example (frontend):

javascript

const cid = getOrCreateCID(); // from cookie/localStorage
fetch('/api/users', { headers: { 'X-Correlation-ID': cid }});

- Backend middleware (Node/Express example): read incoming X-Correlation-ID or generate one, set it on request context, include in response header and logger/tracer context.

javascript

app.use((req,res,next)=>{
  req.correlationId = req.header('X-Correlation-ID') || uuid();
  res.set('X-Correlation-ID', req.correlationId);
  next();
});

- Pass correlation_id to downstream services and external HTTP calls via same header; include it in queued messages/async jobs as metadata.

**Indexing logs & traces**- Ensure structured logs (JSON) with fields: timestamp, service, level, correlation_id, trace_id, span_id, error.code.- Send logs to centralized store (ELK/Datadog/CloudWatch). Create indices and dashboards keyed by correlation_id and error.code.- Integrate distributed tracing (OpenTelemetry). Correlation_id stored as baggage/trace tag to link traces and logs.- Incident workflow: search by correlation_id -> view trace -> identify failing span and root cause.

**Expose errors to SREs without leaking secrets**- User responses: return only error.code, message, correlation_id, status.- SRE/Debug UI: show full debug details and request/response bodies, but behind RBAC and accessible only in staging or to on-call with justification. Mask sensitive fields (PII, tokens) using sanitize middleware before storing.- Retain raw traces/logs for limited TTL; redact known patterns at ingestion; use encryption-at-rest and audit access.

**Operational notes & trade-offs**- Correlation_id vs trace_id: keep both; correlation_id is stable across browser sessions for user troubleshooting; trace_id is per-request distributed-tracing id.- Performance: structured logging + tracing adds overhead—sample traces in high-volume paths.- Rollout: start by passing header, enable structured logs, then tracing, then SRE UI access.

EasyTechnical

44 practiced

Explain how Cross-Origin Resource Sharing (CORS) works when your frontend served from https://app.example.com calls a backend API at https://api.example.com. Describe what triggers a preflight (OPTIONS) request, which response headers the server must return to permit the request (including credentialed requests), and step-by-step debugging techniques you would use when the browser reports CORS errors in the console.

Sample Answer

**Overview — how CORS works (app.example.com → api.example.com)** Browser enforces same-origin policy. When frontend JS at https://app.example.com issues a cross-origin request to https://api.example.com, the browser adds an Origin header and decides whether the request is "simple" or needs a preflight.

**What triggers a preflight (OPTIONS)** Preflight is sent when the request:- Uses methods other than GET, HEAD, POST (e.g., PUT, DELETE, PATCH) - Uses POST with non-simple Content-Type (not application/x-www-form-urlencoded, multipart/form-data, text/plain) - Includes custom headers (e.g., X-Auth-Token) - Requests credentials with certain conditions

**Server response headers required** Example minimal response allowing origin and methods:

http

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Max-Age: 3600

For credentialed requests (cookies, Authorization with fetch credentials: 'include'):

http

Access-Control-Allow-Origin: https://app.example.com   <-- NOT '*'
Access-Control-Allow-Credentials: true

Also ensure actual responses include the same Access-Control-Allow-Origin and Access-Control-Allow-Credentials when credentials are used.

**Debugging steps I use when browser shows CORS errors**1. Reproduce and read exact console error; it usually names the missing header or blocked reason. 2. Check request in Network tab: confirm Origin header, request method, and whether browser sent OPTIONS preflight. 3. Inspect OPTIONS response headers for Access-Control-Allow-* presence and exact Origin value (should match origin or be allowed). 4. Ensure server does not return Access-Control-Allow-Origin: * when credentials are sent. 5. Verify server handles OPTIONS at that route (framework/router may not). Return 200 with headers and no auth required. 6. Temporarily test with curl to see server response (curl won't enforce CORS but shows headers):

bash

curl -i -X OPTIONS https://api.example.com/endpoint -H "Origin: https://app.example.com" -H "Access-Control-Request-Method: PUT"

7. If still failing, check proxies/load-balancers for header stripping and confirm frontend fetch settings (credentials: 'include' only when needed). 8. Fix, redeploy, and re-test.

This approach shows both understanding and practical steps I’d take as a full‑stack developer to resolve CORS issues.

EasyTechnical

51 practiced

Write JavaScript code (browser environment) that performs a GET request to /api/resource using fetch, implements up to 3 retries with exponential backoff (e.g., 500ms, 1000ms, 2000ms), does not retry on 4xx responses, and supports cancellation via AbortController. Show the retry logic and how errors are surfaced to the caller.

Sample Answer

**Approach (brief)**

- Use fetch with an external AbortController so caller can cancel.- Retry up to 3 times on network errors or 5xx responses, with exponential backoff 500ms, 1000ms, 2000ms.- Do not retry on 4xx; surface the response error to caller.- Throw clear errors including attempt count and original response when applicable.

**Code**

javascript

// fetchWithRetries.js
async function fetchWithRetries(url, options = {}, maxRetries = 3) {
  const baseDelay = 500; // ms
  const controller = options.signal ? null : new AbortController();
  if (controller) options.signal = controller.signal;

  let attempt = 0;
  let lastError = null;

  while (attempt <= maxRetries) {
    try {
      attempt++;
      const res = await fetch(url, options);

      // Do not retry on client errors (4xx)
      if (res.status >= 400 && res.status < 500) {
        const body = await res.text();
        const err = new Error(`Request failed ${res.status}`);
        err.status = res.status;
        err.body = body;
        throw err;
      }

      // Retry for 5xx or return successful response
      if (res.ok) return res;
      lastError = new Error(`Server error ${res.status}`);
      lastError.status = res.status;
      // fall through to retry logic
    } catch (err) {
      if (err.name === 'AbortError') throw err; // surface cancellation immediately
      lastError = err;
    }

    if (attempt > maxRetries) break;

    // exponential backoff: 500, 1000, 2000
    const delay = baseDelay * Math.pow(2, attempt - 1);
    await new Promise((resolve, reject) => {
      const timeout = setTimeout(resolve, delay);
      // If caller provided an external signal, abort the wait when signaled
      const signal = options.signal;
      if (signal) signal.addEventListener('abort', () => {
        clearTimeout(timeout);
        reject(new DOMException('Aborted during backoff', 'AbortError'));
      }, { once: true });
    });
  }

  // After retries exhausted
  const finalErr = new Error(`Failed after ${attempt} attempt(s)`);
  finalErr.cause = lastError;
  throw finalErr;
}

// Usage:
const ac = new AbortController();
fetchWithRetries('/api/resource', { method: 'GET', signal: ac.signal })
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => {
    if (err.name === 'AbortError') console.log('Request canceled');
    else console.error('Fetch failed:', err);
  });

// To cancel:
// ac.abort();

**Notes**- Caller can pass their AbortController.signal to cancel immediately.- 4xx responses are thrown immediately with status/body for caller handling.- Errors include cause/attempt info so callers can log or surface appropriate UI messages.

Unlock Full Question Bank

Get access to hundreds of Frontend Backend Integration Through APIs interview questions and detailed answers.

Join thousands of developers preparing for their dream job.