GraphQL schema design కోసం best practices ఏమిటి?

Question

IT Interview Practice · Accepted Answer

మంచి schema అనేది **client-driven, edges వద్ద nullable-by-default, మరియు versions లేకుండా evolvable**. ఇది domain ను మీ database tables పరంగా కాకుండా clients నిజంగా ఉపయోగించే పరంగా model చేస్తుంది.

## Nullability

మీరు దాన్ని *ఎల్లప్పుడూ* తిరిగి ఇవ్వగలిగినప్పుడు మాత్రమే ఒక field ను non-null (`!`) చేయండి. `!` ను అతిగా వాడటం ఒక trap: ఒక non-null field error అయితే, అది తన మొత్తం parent object ను null చేస్తుంది, ఒక చిన్న failure ను పెద్ద blank గా మారుస్తుంది. 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

- స్థిరమైన, వివరణాత్మక names ను ఉపయోగించండి; 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 లేకుండా evolution

GraphQL `/v2` URLs ను నివారిస్తుంది. మీరు **additively** గా evolve అవుతారు: fields ను స్వేచ్ఛగా జోడించండి, మరియు clients migrate అవుతుండగా పాతవాటిని `@deprecated` తో retire చేయండి.

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

ఒక field ను తొలగించడం లేదా పేరు మార్చడం మాత్రమే నిజమైన breaking change, కాబట్టి మీకు అరుదుగా అవసరమయ్యేలా design చేయండి. DB shape ను leak చేయడాన్ని కూడా నివారించండి (clients ఒకే field కావాలనుకుంటే `first_name`/`last_name` కాకుండా `fullName` ను expose చేయండి).

## ఇది ఎందుకు ముఖ్యం

ఈ ఎంపికలే సంవత్సరాలు నిలిచే schema ను clients పోరాడే దాని నుండి వేరు చేస్తాయి. Interviewers దీన్ని **API design maturity** ను అంచనా వేయడానికి ఉపయోగిస్తారు — ముఖ్యంగా nullability/error trade-off మరియు GraphQL కు ప్రత్యేకమైన additive-evolution మనస్తత్వం.

Nullability

Naming & inputs

Versioning లేకుండా evolution

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు