ਤੁਸੀਂ ਇੱਕ collection endpoint ਲਈ pagination, filtering, ਅਤੇ sorting ਕਿਵੇਂ design ਕਰਦੇ ਹੋ?

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 scan ਕਰਕੇ ਸੁੱਟਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ (ਹੌਲੀ), ਅਤੇ ਜੇ requests ਵਿਚਕਾਰ rows insert/delete ਹੁੰਦੀਆਂ ਹਨ, items **ਖਿਸਕ** ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ 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 ਦੇ ਵਿਰੁੱਧ **ਸਥਿਰ** ਹੈ। Trade-off: "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`)। ਸਥਿਰ ordering ਲਈ multi-key ਸਹਾਇਤਾ ਦਿਓ।
- ਹਮੇਸ਼ਾ **`limit` ਨੂੰ ਸੀਮਿਤ ਕਰੋ** (ਜਿਵੇਂ ਵੱਧ ਤੋਂ ਵੱਧ 100) ਤਾਂ ਜੋ ਇੱਕ client ਇੱਕ ਮਿਲੀਅਨ rows ਨਾ ਮੰਗ ਸਕੇ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇਹ ਸਭ ਤੋਂ ਵਿਹਾਰਕ API-design ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਕਿਉਂਕਿ ਲਗਭਗ ਹਰ list endpoint ਇਸ ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ, ਅਤੇ ਚੋਣ ਦੇ ਅਸਲੀ performance ਨਤੀਜੇ ਹਨ। ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲਾ ਆਮ ਤੌਰ 'ਤੇ **offset-ਬਨਾਮ-cursor trade-off** ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਉਮੀਦਵਾਰ ਜੋ ਹਰ ਥਾਂ offset pagination ਲਈ ਪਹੁੰਚਦਾ ਹੈ, ਉਸਨੇ `OFFSET 1000000` ਦੁਆਰਾ table scan ਕਰਨ ਦਾ ਦਰਦ ਨਹੀਂ ਮਹਿਸੂਸ ਕੀਤਾ, ਜਾਂ "ਖਿਸਕਦੇ ਨਤੀਜੇ" bug ਜਿੱਥੇ ਇੱਕ infinite feed scroll ਕਰ ਰਿਹਾ user ਇੱਕੋ post ਦੋ ਵਾਰ ਦੇਖਦਾ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਨਵੀਂ insert ਹੋਈ ਸੀ। Cursor pagination query ਨੂੰ ਇੱਕ indexed keyset lookup ਵਿੱਚ ਬਦਲ ਕੇ ਦੋਵੇਂ ਠੀਕ ਕਰਦੀ ਹੈ, ਇਸੇ ਲਈ ਹਰ ਵੱਡੇ ਪੈਮਾਨੇ ਦਾ API (Twitter, Stripe, Slack) feeds ਲਈ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ। ਮਜ਼ਬੂਤ ਜਵਾਬ ਸੰਚਾਲਨ ਸੁਰੱਖਿਆ-ਰੇਲਿੰਗ ਦਾ ਵੀ ਜ਼ਿਕਰ ਕਰਦੇ ਹਨ — filter/sort fields ਨੂੰ whitelist ਕਰਨਾ (unindexed queries ਅਤੇ injection ਤੋਂ ਬਚਣ ਲਈ) ਅਤੇ `limit` ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ (database ਦੀ ਰੱਖਿਆ ਲਈ) — ਜੋ ਇੱਕ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਜਿਸਨੇ ਇਹ endpoints production ਵਿੱਚ ਚਲਾਏ ਹਨ, ਸਿਰਫ਼ ਇਹਨਾਂ ਬਾਰੇ ਪੜ੍ਹਨ ਵਾਲੇ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

Pagination: offset ਬਨਾਮ cursor

Filtering ਅਤੇ sorting

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ