რა არის GraphQL schema-ს დიზაინის საუკეთესო პრაქტიკები?

Question

IT Interview Practice · Accepted Answer

კარგი schema არის **კლიენტზე ორიენტირებული, კიდეებზე ნაგულისხმევად nullable და ვერსიების გარეშე განვითარებადი**. ის დომენს იმ ტერმინებით მოდელირებს, რომლებსაც კლიენტები რეალურად იყენებენ და არა შენი database-ის ცხრილებით.

## Nullability

ველი non-null (`!`) გახადე მხოლოდ მაშინ, როცა *ყოველთვის* შეგიძლია მისი დაბრუნება. `!`-ის ჭარბად გამოყენება ხაფანგია: თუ non-null ველი შეცდომას იძლევა, ის მთელ თავის parent ობიექტს გახდის null-ს, პატარა ჩავარდნას დიდ ცარიელ ადგილად აქცევს. ყველაფრისთვის, რაც downstream სერვისზეა დამოკიდებული, 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
}
```

## დასახელება და input-ები

- გამოიყენე თანმიმდევრული, აღწერითი სახელები; ბულეანები პრედიკატებად იკითხება (`isPublished`).
- ყოველ mutation-ს მიეცი ერთი **`input`** ტიპი და დააბრუნე **payload** ტიპი — მოგვიანებით ველების დამატება ხელმოწერის დამტვრევის გარეშე შეგეძლება.

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

## განვითარება ვერსიების გარეშე

GraphQL `/v2` URL-ებს ერიდება. განვითარებას **დამატებით** ახდენ: ველებს თავისუფლად ამატებ, ხოლო ძველებს `@deprecated`-ით ხსნი, სანამ კლიენტები გადავლენ.

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

ველის წაშლა ან გადარქმევა ერთადერთი ნამდვილი breaking ცვლილებაა, ამიტომ ისე დააპროექტე, რომ ეს იშვიათად დაგჭირდეს. ასევე ერიდე DB-ის ფორმის გაჟონვას (გამოაჩინე `fullName` და არა `first_name`/`last_name`, თუ კლიენტებს ერთი ველი უნდათ).

## რატომ არის ეს მნიშვნელოვანი

სწორედ ეს არჩევანი განასხვავებს schema-ს, რომელიც წლებს ძლებს, იმისგან, რომელსაც კლიენტები ებრძვიან. ინტერვიუერები ამით ზომავენ **API დიზაინის სიმწიფეს** — განსაკუთრებით nullability/error trade-off-ს და დამატებით-განვითარების აზროვნებას, რაც GraphQL-ისთვის უნიკალურია.

Nullability

დასახელება და input-ები

განვითარება ვერსიების გარეშე

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები