# Build a Paginated Provider Search Backend and React Filter UI Implement a small full-stack search feature. A React page displays provider records from PostgreSQL in pages of five. The backend route uses the page number as a path parameter and accepts optional query parameters for an identifier prefix, a taxonomy-code prefix, and a provider-name prefix. A one-word name may match either first or last name; a multi-word name may match the concatenated full name. The UI must fetch and render the current page and prevent navigation to a page number below 1. ### Constraints & Assumptions - Page numbers are one-based and invalid values receive a clear client error. - All user-provided filters are untrusted input and must be parameterized. - Prefix matching is required; name matching is case-insensitive. - Results need a deterministic ordering so pagination does not drift between calls. - Discuss an index for the identifier filter and the implications of prefix and case-insensitive searches. ### Clarifying Questions to Ask - What stable field should define result ordering? - Should an empty result page distinguish “no matches” from “page beyond the end”? - Are first and last names nullable, and how should extra whitespace be normalized? - Does the UI need a total count or only previous/next navigation? ### Part 1: Define the Request and Response Contract Describe the route, parameters, validation, response shape, and error behavior. #### What This Part Should Cover - Clear separation of the path page number from optional query filters. - One-based page validation and a stable JSON schema. - A deterministic ordering and an explicit page size. ### Part 2: Construct and Execute the SQL Safely Explain how to combine only the filters that are present without creating SQL-injection or Boolean-precedence bugs. #### What This Part Should Cover - Placeholder parameters for every value, including `LIMIT` and `OFFSET` where supported. - Parentheses around the first-name/last-name `OR` expression. - Whitespace handling for multi-word names and a stable `ORDER BY` before pagination. - Index trade-offs for prefix searches and case-insensitive expressions. ### Part 3: Wire the React Page Describe the state, fetch behavior, stale-request handling, rendering, and previous-button rule. #### What This Part Should Cover - URL encoding of query parameters and fetching whenever committed filters or the page change. - Loading, empty, and error states. - Disabling or removing Previous when `pageNumber <= 1`. - Avoiding stale responses when users type or navigate quickly. ### What a Strong Answer Covers - A coherent API contract across React, the backend route, and PostgreSQL. - Safe dynamic SQL with correct operator grouping and deterministic pagination. - Practical indexing discussion rather than assuming every `LIKE` or `ILIKE` predicate uses a basic index. - UI behavior that handles race conditions, failures, and navigation boundaries. ### Follow-up Questions - When would cursor pagination be preferable to `LIMIT` and `OFFSET`? - How would you return a total count without doubling database work on every keystroke? - What would you inspect with `curl` and query plans while debugging this feature?