GraphQL schema ڈیزائن کے best practices کیا ہیں؟

Question

IT Interview Practice · Accepted Answer

ایک اچھی schema **client-driven، edges پر nullable-by-default، اور versions کے بغیر قابلِ ارتقا** ہوتی ہے۔ یہ domain کو ان اصطلاحات میں ماڈل کرتی ہے جو clients واقعی استعمال کرتے ہیں، نہ کہ آپ کے database tables میں۔

## Nullability

کسی field کو non-null (`!`) صرف تب بنائیں جب آپ اسے *ہمیشہ* واپس کر سکیں۔ `!` کا حد سے زیادہ استعمال ایک جال ہے: اگر کوئی non-null field error دے، تو وہ اپنے پورے parent object کو null کر دیتی ہے، اور ایک چھوٹی ناکامی ایک بڑے خلا میں بدل جاتی ہے۔ کسی بھی ایسی چیز کے لیے جو کسی downstream service پر منحصر ہو، nullable کو ترجیح دیں۔

```graphql
type User {
  id: ID!             # truly always present
  email: String!      # required in your DB -> safe as non-null
  avatarUrl: String   # comes from an external service -> nullable, so its failure is isolated
}
```

## Naming اور inputs

- مستقل، وضاحتی نام استعمال کریں؛ booleans predicates کی طرح پڑھی جائیں (`isPublished`)۔
- ہر mutation کو ایک واحد **`input`** type دیں اور ایک **payload** type واپس کریں — آپ بعد میں signature توڑے بغیر fields شامل کر سکتے ہیں۔

```graphql
input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! }  # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
```

## Versioning کے بغیر ارتقا

GraphQL `/v2` URLs سے بچتا ہے۔ آپ **اضافی طور پر (additively)** ارتقا کرتے ہیں: آزادانہ fields شامل کریں، اور پرانی fields کو `@deprecated` کے ساتھ ریٹائر کریں جبکہ clients منتقل ہوتے ہیں۔

```graphql
type User {
  fullName: String!
  name: String! @deprecated(reason: "Use fullName")   # keep serving until clients move off
}
```

کسی field کو ہٹانا یا اس کا نام بدلنا واحد حقیقی breaking change ہے، اس لیے ایسا ڈیزائن کریں کہ آپ کو شاذ و نادر ہی اس کی ضرورت ہو۔ نیز DB shape کو leak کرنے سے بچیں (اگر clients کو ایک ہی field چاہیے تو `fullName` ظاہر کریں، `first_name`/`last_name` نہیں)۔

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

یہی انتخاب ایک ایسی schema کو جو برسوں چلے اس سے الگ کرتے ہیں جس سے clients لڑتے رہتے ہیں۔ Interviewers اس سے **API ڈیزائن کی پختگی** جانچتے ہیں — خاص طور پر nullability/error trade-off اور additive-evolution کی سوچ، جو GraphQL کے لیے منفرد ہیں۔

Nullability

Naming اور inputs

Versioning کے بغیر ارتقا

یہ کیوں اہم ہے

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