Perché non c’è un tipo `Query`?

Perché un campione descrive dati, non un punto d’ingresso. L’uscita è la parte «tipi» di uno schema; un server ha bisogno anche di un `Query` (spesso di un `Mutation`) che nomini i campi esposti. Aggiungi `type Query { root: Root! }` e lo schema diventa servibile — ciò che ci metti è una decisione d’API, non un fatto del carico.

Il mio identificatore di undici cifre è uscito `BigInt` e non `Int`. Perché?

Perché l’`Int` di GraphQL è un intero con segno a 32 bit e il tuo valore non ci sta. Prima usciva `Int!` lo stesso, il che rendeva lo schema falso proprio per il campione da cui veniva — graphql-js solleva in serializzazione. Fuori dalla portata dei 32 bit il campo passa per uno scalare `BigInt`, dichiarato in cima e implementato da te.

Perché tutto è seguito da `!`?

Perché il campione aveva un valore per ogni campo, e `!` è come l’SDL scrive «qui c’è un valore». È l’affermazione che il documento sostiene. Se un campo possa essere nullo in generale è una decisione d’API: togli il `!` dove serve.

JSON in GraphQL — SDL per il tuo file schema

Trasforma un campione JSON in tipi SDL GraphQL. Gli oggetti annidati diventano tipi propri, pronti da incollare in schema.graphql e da interrogare.

Istantaneo Privato Zero cookie

Nome radice

Input JSON

Output GraphQL

Che cosa fa questo strumento

Un campione JSON diventa tipi SDL di GraphQL, uno per oggetto.

{ "id": 1, "name": "Ada", "tags": ["admin"], "address": { "city": "Paris" } }

type Root {
  id: Int!
  name: String!
  tags: [String!]!
  address: Address!
}

type Address {
  city: String!
}

[String!]! si legge dall’esterno verso l’interno: la lista non è mai nulla, e nessun elemento lo è. Entrambe le metà vengono dal campione, che aveva una lista e stringhe dentro.

Solo tipi — questo non è ancora uno schema

Niente Query, niente Mutation, niente direttive. Un carico JSON dice come sono fatti i dati, non quali campi un server espone né come si chiamano. Aggiungi tu il punto d’ingresso:

type Query {
  root: Root!
}

Senza, il file descrive tipi che non si possono chiedere a nessuno.

Ciò che l’SDL non sa dire è nominato, non finto

null e i valori ignoti diventano uno scalare JSON personalizzato, dichiarato in cima e lasciato alla tua implementazione. L’SDL non ha un tipo «qualsiasi cosa».
Un array eterogeneo diventa [JSON]! per lo stesso motivo: una lista di forme miste non è un tipo lista di GraphQL.
Un intero fuori dai 32 bit diventa BigInt, un altro scalare personalizzato. L’Int di GraphQL è a 32 bit con segno: un identificatore di undici cifre non è rappresentabile, e un server che lo restituisce solleva in serializzazione. Usciva Int! lo stesso; era un difetto vero, trovato scrivendo questa pagina e corretto.
Un oggetto vuoto è rifiutato. type A {} non è SDL valido — un tipo deve definire almeno un campo — quindi la conversione si ferma e nomina il tipo invece di consegnarti uno schema che nessun server analizzerà. Anche questo è stato trovato e corretto qui.

I nomi sono riparati, le collisioni tenute distinte

Un nome GraphQL ammette solo lettere, cifre e _, e non comincia con una cifra. content-type diventa content_type, 2fa diventa _2fa. Quando due nomi riparati si incontrano in uno stesso tipo, il secondo prende un suffisso: nulla viene fuso in silenzio.

Uno scalare alla radice — 42, "testo" — è rifiutato: l’SDL descrive tipi oggetto, e lì non c’è nulla da descrivere.

Privato per progettazione

Tutto viene eseguito localmente nel browser con JavaScript. I tuoi dati non vengono mai caricati, quindi lo strumento è sicuro per contenuti sensibili e funziona anche offline.

Domande frequenti

Perché non c’è un tipo `Query`?: Perché un campione descrive dati, non un punto d’ingresso. L’uscita è la parte «tipi» di uno schema; un server ha bisogno anche di un `Query` (spesso di un `Mutation`) che nomini i campi esposti. Aggiungi `type Query { root: Root! }` e lo schema diventa servibile — ciò che ci metti è una decisione d’API, non un fatto del carico.
Il mio identificatore di undici cifre è uscito `BigInt` e non `Int`. Perché?: Perché l’`Int` di GraphQL è un intero con segno a 32 bit e il tuo valore non ci sta. Prima usciva `Int!` lo stesso, il che rendeva lo schema falso proprio per il campione da cui veniva — graphql-js solleva in serializzazione. Fuori dalla portata dei 32 bit il campo passa per uno scalare `BigInt`, dichiarato in cima e implementato da te.
Perché tutto è seguito da `!`?: Perché il campione aveva un valore per ogni campo, e `!` è come l’SDL scrive «qui c’è un valore». È l’affermazione che il documento sostiene. Se un campo possa essere nullo in generale è una decisione d’API: togli il `!` dove serve.