GraphQL schema design ਲਈ best practices ਕੀ ਹਨ?

Question

IT Interview Practice · Accepted Answer

ਇੱਕ ਵਧੀਆ schema **client-driven, edges 'ਤੇ nullable-by-default, ਅਤੇ versions ਤੋਂ ਬਿਨਾਂ evolvable** ਹੁੰਦਾ ਹੈ। ਇਹ domain ਨੂੰ ਉਹਨਾਂ ਸ਼ਬਦਾਂ ਵਿੱਚ model ਕਰਦਾ ਹੈ ਜੋ 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

- ਇਕਸਾਰ, descriptive names ਵਰਤੋ; booleans predicates ਵਾਂਗ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ (`isPublished`)।
- ਹਰ mutation ਨੂੰ ਇੱਕ single **`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 ਆਜ਼ਾਦੀ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਪੁਰਾਣੀਆਂ ਨੂੰ `@deprecated` ਨਾਲ retire ਕਰੋ ਜਦੋਂ ਤੱਕ clients migrate ਕਰਦੇ ਹਨ।

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

ਇੱਕ field ਨੂੰ ਹਟਾਉਣਾ ਜਾਂ rename ਕਰਨਾ ਹੀ ਇਕਲੌਤਾ ਸੱਚਾ breaking change ਹੈ, ਇਸ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਘੱਟ ਹੀ ਲੋੜ ਪਵੇ। DB shape leak ਕਰਨ ਤੋਂ ਵੀ ਬਚੋ (`fullName` ਪ੍ਰਗਟ ਕਰੋ, `first_name`/`last_name` ਨਹੀਂ ਜੇ clients ਇੱਕ field ਚਾਹੁੰਦੇ ਹਨ)।

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

ਇਹ ਚੋਣਾਂ ਹੀ ਉਸ schema ਨੂੰ ਵੱਖ ਕਰਦੀਆਂ ਹਨ ਜੋ ਸਾਲਾਂ ਤੱਕ ਚੱਲਦਾ ਹੈ ਉਸ ਤੋਂ ਜਿਸ ਵਿਰੁੱਧ clients ਲੜਦੇ ਹਨ। Interviewer ਇਸਨੂੰ **API design maturity** ਮਾਪਣ ਲਈ ਵਰਤਦੇ ਹਨ — ਖਾਸ ਕਰਕੇ nullability/error trade-off ਅਤੇ additive-evolution ਸੋਚ, ਜੋ GraphQL ਲਈ ਵਿਲੱਖਣ ਹਨ।

Nullability

Naming & inputs

Versioning ਤੋਂ ਬਿਨਾਂ evolution

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

ਸੰਬੰਧਿਤ ਸਵਾਲ