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

54 practiced

Design a client-side strategy in JavaScript to prevent multiple simultaneous refresh-token calls when several API requests receive 401 at the same time. Describe the algorithm, how pending requests are queued and retried after refresh, and show pseudocode for implementing this with an axios interceptor or a fetch wrapper.

Sample Answer

**Approach (brief)** Prevent a refresh storm by centralizing refresh into a single in-flight promise. When a 401 occurs, requests subscribe to that promise; the first caller triggers the refresh, others wait. After refresh succeeds, queued requests retry with new token; if refresh fails, they fail or trigger logout.

**Algorithm & queueing**- Maintain: let refreshPromise = null; and a queue of retry resolvers.- On 401: - If no refreshPromise: start refresh, set refreshPromise = doRefresh() - Return a promise that waits on refreshPromise, then retries original request with new token.- After refresh resolves: clear refreshPromise and resolve queued retries.- On refresh failure: reject all queued requests and clear state.

**Axios interceptor (pseudocode)**

javascript

// axios-interceptor.js
let refreshPromise = null;

axios.interceptors.response.use(null, error => {
  const { config, response } = error;
  if (!response || response.status !== 401) return Promise.reject(error);

  if (!refreshPromise) {
    refreshPromise = refreshToken() // returns promise that resolves new token
      .then(token => { setAuthToken(token); return token; })
      .catch(err => { handleLogout(); throw err; })
      .finally(() => { refreshPromise = null; });
  }

  return refreshPromise.then(() => {
    config.headers['Authorization'] = 'Bearer ' + getToken();
    return axios(config); // retry original
  });
});

**Fetch wrapper (pseudocode)**

javascript

let refreshPromise = null;

async function fetchWithAuth(input, init = {}) {
  init.headers = { ...init.headers, Authorization: 'Bearer ' + getToken() };
  let res = await fetch(input, init);
  if (res.status !== 401) return res;

  if (!refreshPromise) {
    refreshPromise = refreshToken()
      .then(token => { setAuthToken(token); return token; })
      .catch(err => { handleLogout(); throw err; })
      .finally(() => { refreshPromise = null; });
  }

  await refreshPromise;
  init.headers.Authorization = 'Bearer ' + getToken();
  return fetch(input, init); // retry
}

**Notes / Edge cases**- Protect against infinite retry loops (mark retried requests). - Ensure thread-safety in environments with workers. - Handle concurrent logout/refresh failures gracefully.

EasyTechnical

60 practiced

Explain Cross-Origin Resource Sharing (CORS) from a frontend perspective. Cover:- what causes a preflight request and the difference between simple vs preflighted requests- the Access-Control-* response headers a server must send to allow calls- how to configure fetch to include credentials (cookies)- common debugging approaches in the browser devtools.

Sample Answer

**Brief definition (frontend view)**CORS is a browser-enforced policy that restricts JS on a page from making requests to a different origin unless the server explicitly allows it. From the frontend you trigger requests; the browser enforces CORS and may send a preflight OPTIONS request first.

**Simple vs preflighted requests**- Simple requests: GET, HEAD, POST with Content-Type of text/plain, multipart/form-data, or application/x-www-form-urlencoded and no custom headers. Browser directly sends the request.- Preflighted requests: any request using methods like PUT, DELETE, PATCH, or custom headers (e.g., X-My-Header) or a non-simple Content-Type. Browser first sends an OPTIONS request to ask the server which methods/headers are allowed.

**Required Access-Control-* response headers**Server should respond (as appropriate) with:- Access-Control-Allow-Origin: <origin> or * - Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS - Access-Control-Allow-Headers: list of allowed headers (e.g., Content-Type, X-Auth) - Access-Control-Allow-Credentials: true (when cookies/credentials are allowed) - Access-Control-Max-Age: seconds (optional, caches preflight)

**Including credentials with fetch**Set credentials and ensure server sets Allow-Credentials and a non-* origin:

javascript

fetch('https://api.example.com/data', {
  method: 'GET',
  credentials: 'include' // 'same-origin' for same-site only, 'include' for cross-site
})

**Debugging in DevTools**- Network tab: inspect the OPTIONS preflight and the actual request; look at request/response headers.- Console: CORS errors show origin/blocked-by-message; read which header is missing.- Confirm server responses: check Access-Control-* values and that Access-Control-Allow-Origin is not * when credentials are used.- Reproduce with curl to isolate browser vs server behavior:

bash

curl -i -X OPTIONS https://api.example.com/resource -H "Origin: https://app.example.com"

I would describe the exact missing header when diagnosing and coordinate with backend to correct headers or adjust client request to be "simple" if appropriate.

HardSystem Design

54 practiced

Design a TypeScript client SDK generated from OpenAPI to be consumed across multiple frontend apps. Specify package structure, build & publish pipeline, required features (typed models, auth middleware, request batching, retry policies, telemetry hooks), versioning strategy, and how you'd test and roll out breaking changes to clients.

Sample Answer

**Clarify goals & constraints**- Single TS SDK produced from OpenAPI v3 used by multiple frontend apps (React/Vue), must be tree-shakeable, typed, small, support auth, batching, retries, telemetry, and semantic versioning.

**Package structure**- mono-repo (pnpm/workspaces) - packages/ - sdk-core/ (generated models + typed clients) - sdk-middleware/ (auth, retry, batching, telemetry hooks) - sdk-react-hooks/ (optional React wrappers/useApi) - cli/ (generator + codegen configs) - examples/ (sample apps)- each package has package.json, types, README, tests, build config

**Build & publish pipeline**- CI (GitHub Actions) - On push to main: run tests, lint, typecheck, build (tsc + rollup/tsup producing ESM/CJS + types) - generate SDK from OpenAPI source (openapi-generator or custom TS generator using openapi-typescript-codegen) - produce tarballs and publish to npm with tags (canary, latest, next) via semantic-release - create changelog via conventional commits

**Required features / design**- Typed models: generated interfaces/types, strict null checks, DTO mappers for dates- Auth middleware: pluggable pipeline (compose middleware) supporting OAuth, API key, cookie; token refresh hook- Request batching: opt-in batch adapter that groups requests by endpoint/time window; returns typed responses- Retry policies: configurable exponential backoff, jitter, idempotency checks; pluggable policy per operation- Telemetry hooks: request/response interceptors emitting events (timings, status, size) for analytics and Sentry- Middleware pattern: RequestContext -> middleware[] -> fetch adapter; default fetch adapter uses global fetch with AbortSignal

**Versioning strategy**- Semantic Versioning (semver) per package- Non-breaking changes: patch/minor- Breaking changes: major version bump; publish behind major-scoped package (e.g., @org/sdk-core@2) and maintain previous majors for migration- Use feature flags & "next" release channel for preview

**Testing**- Unit tests for generator output, middleware, adapters (Jest + msw)- Contract tests: use recorded responses (VCR) and schema validation against OpenAPI- Integration tests in example apps in CI against staging API- Performance tests for batching and retries

**Rolling out breaking changes**- Dual-publish strategy: - Release major as alpha/next with migration guide and codemods - Provide compatibility layer in minor releases where feasible - Deprecation warnings at runtime and compile-time (deprecated JSDoc) - Coordinate with consumers: announce roadmap, create migration PRs in consuming repos, offer a migration window (>=2 release cycles)- Provide automated codemods (jscodeshift/ts-morph) and sample upgrade guide

**Why this works**- Generator keeps types in sync, middleware composition gives flexibility, semantic-release + channels minimize disruption, tests + examples ensure confidence, and migration tooling speeds consumer upgrades.

EasyTechnical

44 practiced

In JavaScript (ES2018), write an async function using fetch to GET /api/users. The function should:- check response.ok and throw a descriptive error for non-2xx responses- parse and return the JSON body- catch network errors and rethrow as an ApiError with status (if available) and messageProvide the implementation for apiGetUsers().

Sample Answer

**Answer (approach)**Use fetch with async/await, check response.ok, parse JSON, and wrap errors in a custom ApiError that includes status when available.

**Code**

javascript

// Custom error for API failures
class ApiError extends Error {
  constructor(message, status = null) {
    super(message);
    this.name = 'ApiError';
    this.status = status;
  }
}

async function apiGetUsers() {
  try {
    const res = await fetch('/api/users', { method: 'GET' });

    // Non-2xx responses
    if (!res.ok) {
      // try to get error details from body, fallback to statusText
      let errBody;
      try {
        errBody = await res.json();
      } catch {
        errBody = null;
      }
      const msg = errBody && errBody.message
        ? `Request failed: ${errBody.message}`
        : `Request failed: ${res.status} ${res.statusText}`;
      throw new ApiError(msg, res.status);
    }

    // Parse and return JSON body
    return await res.json();
  } catch (err) {
    // Network errors (TypeError from fetch) or rethrown ApiError
    if (err instanceof ApiError) throw err;
    const status = err && err.status ? err.status : null;
    throw new ApiError(`Network or parsing error: ${err.message}`, status);
  }
}

**Notes**- Parses error body if available to provide descriptive messages.- Rethrows ApiError so callers can handle based on status.

EasyTechnical

49 practiced

Design a JSON API response schema for field-level validation errors returned after submitting a complex form. Provide an example response containing two field errors and one global (form-level) error, state the HTTP status code you'd return, and explain how the frontend should map the response to form fields and display messages.

Sample Answer

**Schema (high level)**

- status: string (e.g., "error")- code: integer (HTTP-like application code)- message: optional global human message- errors: object with: - fields: array of field error objects { name, code, message, meta? } - global: array of form-level error objects { code, message }

**Example response (HTTP 422 Unprocessable Entity)**

json

{
  "status": "error",
  "code": 422,
  "message": "Validation failed",
  "errors": {
    "fields": [
      {
        "name": "email",
        "code": "invalid_format",
        "message": "Email must be a valid address"
      },
      {
        "name": "billing.address.postalCode",
        "code": "invalid_length",
        "message": "Postal code must be 5 digits"
      }
    ],
    "global": [
      {
        "code": "inconsistent_billing",
        "message": "Billing address country must match shipping country"
      }
    ]
  }
}

**HTTP status code**- 422 Unprocessable Entity — indicates semantic validation errors while request syntax was correct.

**How frontend should map & display (React-focused)**- Parse response.errors.fields and convert to a map by `name` (support nested names like "billing.address.postalCode").- For controlled inputs (e.g., react-hook-form): call setError("email", { type: "server", message: ... }).- For nested keys, resolve path (split by ".") or use lodash.set to attach error to form state.- Show field-level message under the input; set aria-invalid and aria-describedby for accessibility.- Display global errors in a banner/toast at top of form with actions if needed.- Optionally surface error.code to trigger specific UI (focus field, highlight, or show help link).

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.