کسی collection endpoint کے لیے آپ pagination، filtering، اور sorting کیسے ڈیزائن کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

کوئی بھی endpoint جو کوئی collection واپس کرتا ہے اسے نتائج کو محدود اور تشکیل دینے کی ضرورت ہوتی ہے۔ تین معاملات — pagination، filtering، sorting — سبھی query string میں رہتے ہیں۔

Pagination: offset بمقابلہ cursor

Offset (page پر مبنی) — ?page=3&limit=20 یا ?offset=40&limit=20۔

## Pagination: offset بمقابلہ 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 اسکین کر کے پھینکنے پر مجبور کرتا ہے (سست)، اور اگر requests کے درمیان 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 جو کسی بھی گہرائی پر تیز رہتا ہے اور inserts کے خلاف **مستحکم** ہے۔ trade-off: "page 500" تک random رسائی نہیں۔

```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 کے ساتھ **filter** کریں (`status=shipped`)۔ اجازت شدہ fields کو whitelist کریں۔
- ایک `sort` param کے ساتھ **sort** کریں؛ ایک `-` prefix کا مطلب نزولی ترتیب (`-created_at`)۔ مستحکم ترتیب کے لیے multi-key سپورٹ کریں۔
- ہمیشہ **`limit` کو محدود** کریں (مثلاً زیادہ سے زیادہ 100) تاکہ کوئی client دس لاکھ rows نہ مانگ سکے۔

## یہ کیوں اہم ہے

یہ سب سے عملی API-design سوالات میں سے ایک ہے کیونکہ تقریباً ہر list endpoint اس سے ٹکراتا ہے، اور انتخاب کے حقیقی پرفارمنس نتائج ہوتے ہیں۔ انٹرویو لینے والا عام طور پر **offset-بمقابلہ-cursor trade-off** کھنگالتا ہے: ایک امیدوار جو ہر جگہ offset pagination کی طرف لپکتا ہے اس نے `OFFSET 1000000` کے table اسکین کرنے کا درد محسوس نہیں کیا، یا "کھسکتے نتائج" bug جہاں کوئی صارف کسی infinite feed کو scroll کرتے ہوئے وہی post دو بار دیکھتا ہے کیونکہ ایک نیا داخل ہو گیا تھا۔ Cursor pagination query کو ایک indexed keyset lookup میں بدل کر دونوں ٹھیک کرتی ہے، یہی وجہ ہے کہ ہر بڑے پیمانے کی API (Twitter، Stripe، Slack) اسے feeds کے لیے استعمال کرتی ہے۔ مضبوط جوابات آپریشنل حفاظتی حصار بھی بتاتے ہیں — filter/sort fields کو whitelist کرنا (بغیر index کی queries اور injection سے بچنے کے لیے) اور `limit` کو محدود کرنا (database کی حفاظت کے لیے) — جو کسی ایسے شخص کو جس نے یہ endpoints production میں چلائے ہوں کسی ایسے شخص سے الگ کرتا ہے جس نے صرف ان کے بارے میں پڑھا ہو۔

Pagination: offset بمقابلہ cursor

Filtering اور sorting

یہ کیوں اہم ہے

متعلقہ سوالات