GraphQL schema design का लागि best practices के हुन्?

Question

IT Interview Practice · Accepted Answer

राम्रो schema **client-driven, edge हरूमा default रूपमा nullable, र version बिना नै विकसित हुन सक्ने** हुन्छ। यसले domain लाई तपाईंको database tables को होइन, client हरूले वास्तवमा प्रयोग गर्ने शब्दहरूमा model गर्छ।

## Nullability

कुनै field लाई non-null (`!`) तब मात्र बनाउनुहोस् जब तपाईंले त्यसलाई *सधैँ* फर्काउन सक्नुहुन्छ। `!` को अत्यधिक प्रयोग एउटा जाल हो: non-null field मा error आयो भने, यसले आफ्नो सम्पूर्ण parent object लाई null गर्छ, सानो असफलतालाई ठूलो 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

- एकरूप, वर्णनात्मक नामहरू प्रयोग गर्नुहोस्; boolean हरू predicate जस्तै पढिन्छन् (`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! }
```

## Version बिना evolution

GraphQL ले `/v2` URL हरूलाई बेवास्ता गर्छ। तपाईं **थप्ने रूपमा** विकसित हुनुहुन्छ: fields स्वतन्त्र रूपमा थप्नुहोस्, र client हरू migrate हुँदै गर्दा पुरानालाई `@deprecated` सँग सेवानिवृत्त गर्नुहोस्।

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

कुनै field हटाउनु वा नाम बदल्नु मात्र साँचो breaking change हो, त्यसैले तपाईंलाई विरलै त्यसो गर्नुपर्ने गरी design गर्नुहोस्। DB आकार leak गर्नबाट पनि जोगिनुहोस् (client हरूलाई एउटा field चाहिन्छ भने `first_name`/`last_name` होइन, `fullName` expose गर्नुहोस्)।

## यो किन महत्त्वपूर्ण छ

यी छनोटहरूले वर्षौं टिक्ने schema लाई client हरू लड्ने schema बाट छुट्याउँछन्। Interviewer हरूले यसलाई **API design परिपक्वता** मापन गर्न प्रयोग गर्छन् — विशेष गरी nullability/error trade-off र additive-evolution सोच, जुन GraphQL का लागि अद्वितीय छन्।

Nullability

Naming र inputs

Version बिना evolution

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू