Apa wae praktik paling apik kanggo desain schema GraphQL?

Question

IT Interview Practice · Accepted Answer

Schema sing apik iku **disetir klien, nullable-by-default ing pinggiran, lan bisa berkembang tanpa versi**. Iki nggambarake domain nganggo istilah sing pancen dienggo klien, dudu tabel database-mu.

## Nullability

Gawe field non-null (`!`) mung yen kowe *tansah* bisa mbalekake. Kakehan nganggo `!` iku jebakan: yen field non-null error, iku nge-null kabeh object parent-e, ngowahi kegagalan cilik dadi kothong gedhe. Luwih becik nullable kanggo apa wae sing gumantung ing layanan downstream.

```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
}
```

## Penamaan & input

- Nganggo jeneng sing konsisten lan deskriptif; boolean diwaca minangka predikat (`isPublished`).
- Wenehi saben mutation siji type **`input`** lan mbalekake type **payload** — kowe bisa nambah field mengko tanpa ngrusak signature.

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

## Evolusi tanpa versi

GraphQL ngindhari URL `/v2`. Kowe berkembang kanthi **aditif**: nambah field kanthi bebas, lan mènsiunake sing lawas nganggo `@deprecated` nalika klien migrasi.

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

Mbusak utawa ngganti jeneng field iku siji-sijine owah-owahan sing bener-bener ngrusak, mula desainen supaya kowe arang mbutuhake iku. Uga ngindhari mbocorake wangun DB (tampilake `fullName`, dudu `first_name`/`last_name` yen klien pengin siji field).

## Kenapa iki penting

Pilihan-pilihan iki sing mbedakake schema sing tahan pirang-pirang taun karo schema sing dilawan klien. Pewawancara nganggo iki kanggo ngukur **kadewasan desain API** — utamane trade-off nullability/error lan pola pikir evolusi aditif, sing khas kanggo GraphQL.

Nullability

Penamaan & input

Evolusi tanpa versi

Kenapa iki penting

Pitakon sing gegandhengan