Care sunt cele mai bune practici pentru designul unei scheme GraphQL?

Question

IT Interview Practice · Accepted Answer

O schemă bună este **condusă de client, nullable în mod implicit la margini și evoluabilă fără versiuni**. Ea modelează domeniul în termenii pe care clienții îi folosesc efectiv, nu tabelele din baza ta de date.

## Nullability

Marchează un câmp ca non-null (`!`) doar când îl poți returna *întotdeauna*. Supra-utilizarea lui `!` este o capcană: dacă un câmp non-null eșuează, anulează întregul obiect parent, transformând un eșec mic într-un gol mare. Preferă nullable pentru orice depinde de un serviciu din aval.

```graphql
type User {
  id: ID!             # cu adevărat mereu prezent
  email: String!      # obligatoriu în DB -> sigur ca non-null
  avatarUrl: String   # vine de la un serviciu extern -> nullable, deci eșecul său este izolat
}
```

## Denumire și input-uri

- Folosește nume consecvente și descriptive; booleanele se citesc ca predicate (`isPublished`).
- Dă fiecărei mutații un singur tip **`input`** și returnează un tip **payload** — poți adăuga câmpuri ulterior fără a strica semnătura.

```graphql
input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! }  # loc de creștere
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
```

## Evoluție fără versionare

GraphQL evită URL-urile `/v2`. Evoluezi **aditiv**: adaugă câmpuri liber și retrage-le pe cele vechi cu `@deprecated` în timp ce clienții migrează.

```graphql
type User {
  fullName: String!
  name: String! @deprecated(reason: "Use fullName")   # continuă să servești până când clienții renunță
}
```

Eliminarea sau redenumirea unui câmp este singura modificare cu adevărat incompatibilă, așa că proiectează astfel încât să ai rareori nevoie de asta. Evită și scurgerea formei din DB (expune `fullName`, nu `first_name`/`last_name` dacă clienții vor un singur câmp).

## De ce contează

Aceste alegeri sunt cele care separă o schemă care durează ani de una împotriva căreia clienții se luptă. Intervievatorii folosesc asta pentru a evalua **maturitatea în designul de API** — mai ales compromisul nullability/erori și mentalitatea evoluției aditive, care sunt unice pentru GraphQL.

Nullability

Denumire și input-uri

Evoluție fără versionare

De ce contează

Întrebări conexe