Pourquoi n’y a-t-il pas de type `Query` ?

Parce qu’un échantillon décrit des données, pas un point d’entrée. La sortie est la partie « types » d’un schéma ; un serveur a aussi besoin d’un `Query` (souvent d’un `Mutation`) nommant les champs qu’il expose. Ajoutez `type Query { root: Root! }` et le schéma devient servable — ce qu’on y met est une décision d’API, pas un fait de la charge.

Mon identifiant à onze chiffres est sorti en `BigInt`, pas en `Int`. Pourquoi ?

Parce que l’`Int` de GraphQL est un entier signé 32 bits, et que votre valeur n’y tient pas. Il sortait `Int!` quand même, ce qui rendait le schéma faux pour l’échantillon dont il venait — graphql-js lève à la sérialisation. Hors plage 32 bits, le champ passe par un scalaire `BigInt`, déclaré en tête et implémenté par vous.

Pourquoi tout est-il suivi d’un `!` ?

Parce que l’échantillon avait une valeur pour chaque champ, et que `!` est l’écriture SDL de « il y a une valeur ici ». C’est l’affirmation que le document permet. Savoir si un champ peut être nul en général est une décision d’API : retirez le `!` là où c’est le cas.

JSON en GraphQL — du SDL pour votre schéma

Transformez un échantillon JSON en types SDL GraphQL. Les objets imbriqués deviennent leurs propres types, à coller dans schema.graphql et à interroger.

Instantané Privé Zéro cookie

Nom racine

Entrée JSON

Sortie GraphQL

Ce que fait cet outil

Un échantillon JSON devient des types GraphQL SDL, un par objet.

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

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

type Address {
  city: String!
}

[String!]! se lit de l’extérieur vers l’intérieur : la liste n’est jamais nulle, et aucun élément ne l’est non plus. Les deux moitiés viennent de l’échantillon, qui avait une liste et des chaînes dedans.

Des types seulement — ce n’est pas encore un schéma

Pas de Query, pas de Mutation, pas de directives. Une charge JSON dit à quoi ressemblent les données, pas quels champs un serveur expose ni comment ils s’appellent. Ajoutez le point d’entrée vous-même :

type Query {
  root: Root!
}

Sans lui, le fichier décrit des types qu’on ne peut demander à personne.

Ce que le SDL ne sait pas dire est nommé, pas feint

null et les valeurs inconnues deviennent un scalaire JSON custom, déclaré en tête et laissé à votre implémentation. Le SDL n’a pas de type « n’importe quoi ».
Un tableau hétérogène devient [JSON]! pour la même raison : une liste de formes mêlées n’est pas un type liste GraphQL.
Un entier hors 32 bits devient BigInt, un autre scalaire custom. L’Int de GraphQL est signé sur 32 bits : un identifiant à onze chiffres n’y est pas représentable, et un serveur qui le renvoie lève à la sérialisation. Il sortait Int! malgré tout ; c’était un vrai défaut, trouvé en écrivant cette page et corrigé.
Un objet vide est refusé. type A {} n’est pas du SDL valide — un type doit définir au moins un champ — donc la conversion s’arrête et nomme le type plutôt que de vous rendre un schéma qu’aucun serveur n’analysera. Trouvé et corrigé ici également.

Les noms sont réparés, les collisions séparées

Un nom GraphQL n’admet que lettres, chiffres et _, et ne commence pas par un chiffre. content-type devient content_type, 2fa devient _2fa. Quand deux noms réparés se rencontrent dans un même type, le second est suffixé : rien n’est fondu en silence.

Un scalaire à la racine — 42, "texte" — est refusé : le SDL décrit des types objets, et il n’y a rien à décrire.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

Pourquoi n’y a-t-il pas de type `Query` ?: Parce qu’un échantillon décrit des données, pas un point d’entrée. La sortie est la partie « types » d’un schéma ; un serveur a aussi besoin d’un `Query` (souvent d’un `Mutation`) nommant les champs qu’il expose. Ajoutez `type Query { root: Root! }` et le schéma devient servable — ce qu’on y met est une décision d’API, pas un fait de la charge.
Mon identifiant à onze chiffres est sorti en `BigInt`, pas en `Int`. Pourquoi ?: Parce que l’`Int` de GraphQL est un entier signé 32 bits, et que votre valeur n’y tient pas. Il sortait `Int!` quand même, ce qui rendait le schéma faux pour l’échantillon dont il venait — graphql-js lève à la sérialisation. Hors plage 32 bits, le champ passe par un scalaire `BigInt`, déclaré en tête et implémenté par vous.
Pourquoi tout est-il suivi d’un `!` ?: Parce que l’échantillon avait une valeur pour chaque champ, et que `!` est l’écriture SDL de « il y a une valeur ici ». C’est l’affirmation que le document permet. Savoir si un champ peut être nul en général est une décision d’API : retirez le `!` là où c’est le cas.