Collection endpoint માટે pagination, filtering, અને sorting કેવી રીતે design કરો છો?

Question

IT Interview Practice · Accepted Answer

Collection પરત કરતો કોઈપણ endpoint results ને મર્યાદિત અને આકાર આપવાની જરૂર છે. ત્રણ ચિંતાઓ — 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 પર કૂદવા દે છે, પણ scale પર બે સમસ્યાઓ છે: `OFFSET 100000` database ને 100k rows scan કરી ને કાઢી નાખવા મજબૂર કરે છે (ધીમું), અને જો requests વચ્ચે rows insert/delete થાય, તો items **shift** થાય છે અને તમને duplicates કે skips દેખાય છે.

**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 જે કોઈપણ ઊંડાણે ઝડપી રહે છે અને inserts સામે **stable** છે. Trade-off: "page 500" પર કોઈ random access નથી.

```text
Offset  → નાના datasets, admin UIs, "page N પર કૂદો"
Cursor  → મોટા/અનંત 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`). સ્થિર ordering માટે multi-key ને support કરો.
- હંમેશા **`limit` ને મર્યાદિત કરો** (દા.ત. મહત્તમ 100) જેથી client દસ લાખ rows માગી ન શકે.

## આ શા માટે મહત્વનું છે

આ સૌથી વ્યવહારુ API-design પ્રશ્નોમાંનો એક છે કારણ કે લગભગ દરેક list endpoint તેને અડે છે, અને પસંદગીના વાસ્તવિક performance પરિણામો છે. Interviewer સામાન્ય રીતે **offset-vs-cursor trade-off** ને દબાવે છે: જે ઉમેદવાર બધે offset pagination તરફ જાય છે તેણે table scan કરતા `OFFSET 1000000` ની પીડા અનુભવી નથી, કે "shifting results" bug જ્યાં અનંત feed scroll કરતો user એ જ post બે વાર જુએ છે કારણ કે નવો insert થયો હતો. Cursor pagination query ને indexed keyset lookup માં ફેરવીને બંને ઠીક કરે છે, એટલે જ દરેક large-scale API (Twitter, Stripe, Slack) તેને feeds માટે વાપરે છે. મજબૂત જવાબો operational guardrails નો પણ ઉલ્લેખ કરે છે — filter/sort fields ને whitelist કરવા (unindexed queries અને injection ટાળવા) અને `limit` ને મર્યાદિત કરવું (database ને સુરક્ષિત કરવા) — જે production માં આ endpoints ચલાવેલ વ્યક્તિને ફક્ત તેમના વિશે વાંચેલ વ્યક્તિથી અલગ પાડે છે.

Pagination: offset vs cursor

Filtering અને sorting

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો