# Compatibility Layers और क्रमिक Migration — API Design और Versioning

Source: https://www.geekswithgeeks.com/hi/api-design/dep-compat-shims

> Adapters, feature flags और client SDK updates से migration आसान बनाएँ।

## नया रास्ता आसान रास्ता बनाएँ

Migration तब सफल होते हैं जब आगे बढ़ना सस्ता हो। Server पर **अनुवाद परतें** दें ताकि पुराने अनुरोध नए मॉडल पर map हों, **अद्यतन SDKs** और यांत्रिक नाम-बदलाव के लिए **codemod** या script प्रकाशित करें, clients को सब कुछ एक साथ पलटने की जगह **प्रति feature या प्रति अनुरोध opt-in** करने दें (header, flag या तारीख़ version से), और **दोनों versions एक ही test suite में** रखें ताकि बहाव दिखे। तोड़ने वाले व्यवहारगत बदलावों के लिए पुराने और नए को **shadow mode** में साथ चलाएँ (users को प्रभावित किए बिना responses की तुलना)। पहले अपनी सेवाएँ deprecated versions से हटाएँ; API टीम v2 उपयोग न करे तो कोई उस पर भरोसा नहीं करेगा।

## v2 मॉडल के ऊपर v1 adapter (उदाहरण)

v1 responses उसी record से बनते हैं, बँटे fields को वापस एक `name` में जोड़कर, इसलिए सँभालने के लिए कोई दूसरा डेटा रास्ता नहीं।

```python
def to_v2(item):
    return {"id": item.id, "first_name": item.first_name,
            "last_name": item.last_name, "plan": item.plan}

def to_v1(item):                       # adapter: same data, old shape
    v2 = to_v2(item)
    return {"id": v2["id"], "name": f"{v2['first_name']} {v2['last_name']}", "plan": v2["plan"]}
```

**Quiz:** Shadow mode में पुराने और नए responses की तुलना क्यों करें?

- [ ] डेटा हटाने के लिए
- [ ] बिल दोगुना करने के लिए
- [ ] testing से बचने के लिए
- [x] users के प्रभावित होने से पहले अंतर पकड़ने के लिए

*Answer:* users के प्रभावित होने से पहले अंतर पकड़ने के लिए. Shadow traffic production users को जोखिम में डाले बिना व्यवहार के बेमेल दिखाता है।