Q083: Frontend and Backend API Collaboration

What Interviewers Want To Evaluate

This question tests whether you can collaborate across the client-server boundary. Interviewers want API contract thinking, error handling, pagination, latency, auth, versioning, observability, backward compatibility, and how frontend needs shape backend design.

Senior frontend engineers should not treat APIs as something that simply arrives from another team. They help shape contracts that make product experiences reliable.

Short Interview Answer

Good frontend-backend collaboration starts with user flows and data contracts. I would align on required fields, loading model, pagination, filtering, sorting, error shapes, auth behavior, caching, versioning, and observability. I prefer typed contracts and runtime validation at boundaries. The API should support the UI workflow without leaking unnecessary backend complexity, and both sides should agree on backward-compatible changes and failure behavior.

Detailed Interview Answer

APIs are product surfaces. If the contract is unclear, the UI becomes fragile. If the contract is too backend-shaped, the frontend may need expensive transformations or multiple waterfall requests.

Start with the workflow:

What screen or action needs this API?
What data is needed for first render?
What can load later?
How large can the data get?
What errors can happen?
What permissions apply?
What freshness is required?
How will changes be versioned?

Contract Design

A good contract defines required fields, optional fields, nullable fields, IDs, timestamps, pagination, sorting, filters, and error shapes.

Avoid ambiguous values. For example, distinguish between empty data, missing permission, loading failure, and deleted resource.

Error Shapes

Frontend apps need actionable errors. A generic 500 is not enough for user experience. The UI may need to know whether an error is retryable, permission-related, validation-related, or caused by rate limiting.

Error contracts should avoid leaking sensitive backend details.

Pagination and Filtering

Large datasets should not force the frontend to load everything. Agree on server-side pagination, cursor behavior, sorting, filtering, and search semantics.

Cursor pagination is often better for changing datasets. Offset pagination can be simpler but may behave poorly when data changes during pagination.

Performance

The frontend should explain route-level performance needs. First render may need summary data quickly, while detailed panels can load later.

Avoid API waterfalls when the page needs many dependent calls. Consider shaped endpoints, parallel endpoints, batching, or server components depending on the stack.

Auth and Permissions

Permissions must be enforced server-side. The frontend can hide unavailable actions for usability, but it must handle denied responses safely.

Auth failure should have a clear contract: expired session, insufficient permission, missing tenant, or forbidden action.

Versioning

Backward compatibility matters. Removing a field or changing a type can break deployed clients. Even in a web app, users may have old bundles in browser tabs or cached assets.

Safer changes include additive fields, deprecation windows, feature flags, and contract tests.

Common Mistakes

A common mistake is designing APIs around database tables rather than user workflows. Another is ignoring empty and error states until the UI is already built.

Another mistake is assuming TypeScript types generated from an API remove the need for runtime boundary checks.

Senior Trade-Offs

A UI-shaped endpoint can reduce frontend complexity and improve performance, but it may be less reusable for other clients. A generic endpoint is flexible but may force each UI to repeat transformations.

The right contract depends on product complexity, client count, performance needs, and ownership.

Code or Design Example

A clear response contract helps the frontend render states predictably.

type ApiResult<T> =
  | { status: "ok"; data: T; requestId: string }
  | { status: "empty"; message: string; requestId: string }
  | { status: "error"; code: "VALIDATION" | "FORBIDDEN" | "RATE_LIMIT" | "SERVER"; retryable: boolean; requestId: string };

type PageRequest = {
  cursor?: string;
  limit: number;
  sort: "created-desc" | "created-asc";
  filters: Record<string, string[]>;
};

This gives the UI enough information to render without guessing.

Contract Testing

Contract tests catch accidental API changes. They can run against schema definitions, generated clients, mock servers, or integration environments.

For high-risk workflows, frontend and backend should share fixtures that represent success, empty, validation failure, denied access, and server failure.

Production Example

Imagine a dashboard needs user summaries, chart data, table rows, permissions, and feature flags. If each piece requires a sequential request, the page becomes slow.

The teams might agree that route-critical summary data loads together, while heavy table data loads lazily with cursor pagination and server-side filters.

Lead Engineer Perspective

A lead frontend engineer should bring evidence to API conversations: user workflow, performance budgets, error states, data volume, and release constraints.

The goal is not to win against backend. The goal is to create a contract that serves users and remains maintainable for both sides.

Revision Notes

API collaboration is about user flows, contracts, errors, pagination, performance, auth, versioning, and observability.

Key Takeaways

Senior frontend engineers shape API contracts. They do not merely consume them.

Follow-Up Questions

1. What makes an API frontend-friendly?
2. How should error contracts be designed?
3. When would you choose cursor pagination?
4. How do auth failures affect UI?
5. How do you avoid API waterfalls?
6. What changes are backward-compatible?
7. Why are runtime checks still useful?
8. What should contract tests cover?
9. How do you handle optional fields?
10. How do frontend performance needs shape APIs?

How I Would Answer This In A Real Interview

I would start from the user workflow, then discuss required data, loading sequence, error shapes, pagination, auth, caching, versioning, and contract tests. I would emphasize that good API design is shared product architecture across frontend and backend.