ఒక collection endpointకు pagination, filtering, sortingను ఎలా డిజైన్ చేస్తారు?

Question

IT Interview Practice · Accepted Answer

ఒక collectionను తిరిగి ఇచ్చే ఏ endpoint అయినా ఫలితాలను పరిమితం, ఆకృతి చేయాలి. మూడు ఆందోళనలు — pagination, filtering, sorting — అన్నీ query stringలో ఉంటాయి.

Pagination: offset vs cursor

Offset (page-ఆధారిత) — ?page=3&limit=20 లేదా ?offset=40&limit=20.

## Pagination: offset vs cursor

**Offset (page-ఆధారిత)** — `?page=3&limit=20` లేదా `?offset=40&limit=20`.
```http
GET /orders?offset=40&limit=20 HTTP/1.1
```
సరళం, ఏ pageకైనా దూకనిస్తుంది, కానీ స్కేల్‌లో రెండు సమస్యలు: `OFFSET 100000` databaseను 100k rows స్కాన్ చేసి పారవేయమని బలవంతం చేస్తుంది (నెమ్మది), మరియు requestల మధ్య rows చొప్పించబడితే/తొలగించబడితే, items **మారుతాయి**, మీరు నకిలీలు లేదా దాటవేతలను చూస్తారు.

**Cursor (keyset)** — client చివరిగా చూసిన itemకు ఒక opaque pointerను పంపుతుంది.
```http
GET /orders?limit=20&cursor=eyJpZCI6MTAyMH0 HTTP/1.1
```
```http
HTTP/1.1 200 OK

{
  "data": [ /* 20 orders */ ],
  "page": { "next_cursor": "eyJpZCI6MTA0MH0", "has_more": true }
}
```
Server cursorను `WHERE id > 1020 ORDER BY id LIMIT 20`గా అనువదిస్తుంది — ఏ లోతులోనైనా వేగంగా ఉండే, చొప్పింపులకు వ్యతిరేకంగా **స్థిరమైన** indexed lookup. ట్రేడ్-ఆఫ్: "page 500"కు random access లేదు.

```text
Offset  → small datasets, admin UIs, "jump to page N"
Cursor  → large/infinite feeds, real-time data, mobile scroll
```

## Filtering మరియు sorting

```http
GET /orders?status=shipped&min_total=100&sort=-created_at,id HTTP/1.1
```
- field=value query params (`status=shipped`)తో **filter** చేయండి. అనుమతించిన fieldsను whitelist చేయండి.
- ఒక `sort` paramతో **sort** చేయండి; ఒక `-` prefix descending అని అర్థం (`-created_at`). స్థిరమైన క్రమం కోసం multi-key మద్దతు ఇవ్వండి.
- ఎల్లప్పుడూ **`limit`ను పరిమితం చేయండి** (ఉదా. గరిష్ఠం 100), తద్వారా ఒక client లక్షలాది rowsను అభ్యర్థించలేదు.

## ఇది ఎందుకు ముఖ్యం

ఇది అత్యంత ఆచరణాత్మక API-డిజైన్ ప్రశ్నలలో ఒకటి, ఎందుకంటే దాదాపు ప్రతి list endpoint దీన్ని ఎదుర్కొంటుంది, మరియు ఎంపికకు నిజమైన పెర్ఫార్మెన్స్ పరిణామాలు ఉంటాయి. ఇంటర్వ్యూయర్ సాధారణంగా **offset-vs-cursor ట్రేడ్-ఆఫ్**ను పరిశోధిస్తారు: అంతటా offset paginationను ఆశ్రయించే అభ్యర్థి `OFFSET 1000000` table స్కాన్ చేసే బాధను, లేదా ఒక userను infinite feed స్క్రోల్ చేస్తూ ఒక కొత్తది చొప్పించబడటం వల్ల అదే post రెండుసార్లు చూసే "shifting results" బగ్‌ను అనుభవించలేదు. Cursor pagination query‌ను ఒక indexed keyset lookupగా మార్చడం ద్వారా రెండింటినీ సరిచేస్తుంది, అందుకే ప్రతి large-scale API (Twitter, Stripe, Slack) feeds కోసం దాన్ని వాడుతుంది. బలమైన జవాబులు కార్యాచరణ రక్షణలను కూడా ప్రస్తావిస్తాయి — filter/sort fieldsను whitelist చేయడం (unindexed queries మరియు injectionను నివారించడానికి), `limit`ను పరిమితం చేయడం (databaseను రక్షించడానికి) — ఇది ఈ endpointలను productionలో నడిపిన వ్యక్తిని కేవలం వాటి గురించి చదివిన వ్యక్తి నుండి వేరు చేస్తుంది.

Pagination: offset vs cursor

Filtering మరియు sorting

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు