GraphQL SDL

TypeScript

Wat deze converter doet

Je hebt een GraphQL-schema. Je frontend is TypeScript. Ergens daartussen heb je een set types nodig die veld voor veld matcht met het schema, en je wil ze nu — niet na een codegen-build van vijf minuten, niet nadat je graphql-code-generator aan een vers project hebt gehangen, niet nadat je aan een junior hebt uitgelegd welke plugin geïnstalleerd moet worden. Plak de GraphQL SDL in het linkerpaneel en het rechterpaneel geeft idiomatische TypeScript terug: interface voor object- en input-types, enum voor enums, gewone type-aliases voor unions en scalars.

De mapping volgt de regels die de meeste TypeScript-code verwacht. Ingebouwde scalars liggen op hun TypeScript primitive equivalents: String en ID worden string, Int en Float worden number, Boolean wordt boolean. Custom scalars zoals DateTime vallen standaard op string met een // custom scalar-marker zodat je eraan denkt ze later te verbreden. Non-null-velden (name: String!) komen eruit als verplichte properties; nullable velden krijgen de ?-modifier. List-types [Order!]! worden Order[]. type Order implements Node wordt interface Order extends Node — de interface-relatie in GraphQL mapt netjes op TS structurele extensie.

Geen upload, geen netwerk, geen AI. De conversie gebeurt client-side in een handgeschreven SDL-tokenizer — je schema verlaat de pagina nooit, wat je precies wil als het schema intern of pre-release is.

Hoe gebruik je het

Drie stappen. De conversie is automatisch — geen Convert-knop.

Plakken, uploaden of voorbeeld laden

Drop je SDL in het linker GraphQL SDL-paneel. Zodra je stopt met typen, ververst het rechterpaneel. Klik Uploaden voor een .graphql / .graphqls / .gql-bestand, of Voorbeeld om een realistisch e-commerce schema te laden. Een stukje SDL ziet er zo uit:

type Order implements Node { id: ID! placedAt: DateTime! status: OrderStatus! items: [OrderItem!]! } enum OrderStatus { PENDING PAID SHIPPED DELIVERED CANCELLED }

Zowel server-stijl schemas (met extend type Query) als losse type-definities werken. Block-string descriptions ("""...""") worden opgepikt en als JSDoc-commentaar boven het gegenereerde type gezet, wat de conventie is die de GraphQL-referentie-implementatie documenteert.

Lees de gegenereerde TypeScript

Het rechterpaneel zet types per soort gegroepeerd: eerst scalars, dan enums, unions, interfaces, input-types, en als laatste object-types. Binnen elke groep blijven de definities in source-volgorde zodat de diff tegen je handgeschreven types zo klein mogelijk is. Heeft het SDL een parse-fout (ongebalanceerde accolades, een niet-afgesloten block-string, etc.) dan toont het output-paneel één commentaar // Invalid GraphQL: ... in plaats van te crashen — hetzelfde patroon dat Apollo Server gebruikt als zijn startup-parse faalt.

Kopiëren of downloaden

Klik Kopiëren om de types direct in een schema.types.ts-bestand in je project te plakken. Klik Downloaden om ze als .ts-bestand op te slaan. Output is platte tekst — geen module-imports, geen runtime-code — dus past in elk TS-project, frontend of backend.

Wanneer je dit echt zou gebruiken

Snel types zonder codegen op te zetten

Je prototypeert een frontend tegen een bestaand GraphQL-endpoint en hebt geen zin om een complete codegen-pipeline op te zetten alleen om types voor drie queries te krijgen. Plak het schema, kopieer de output in types.ts, ship het prototype. Een echte codegen-pipeline kun je later prikken als het project serieus wordt.

Sanity-check wat codegen gaat opleveren

Voordat je een nieuw type aan het schema toevoegt, plak je voorgestelde SDL hier om te zien welke vorm je TypeScript-callers gaan krijgen. Soms levert een veld dat in SDL prima leest een onhandige TS op — een optionele lijst van nullables, een enum met een waarde die botst met een TS reserved word — en het is veel goedkoper om dat hier te ontdekken dan na het mergen van de PR.

Een schema documenteren voor een TypeScript-team

Een TS-first team aan het onboarden op een GraphQL API? Plak het schema, kopieer de gegenereerde types naar de wiki. Engineers die in TS-interfaces denken pakken het schema sneller op via een TS-view dan via ruwe SDL — de datavormen zijn hetzelfde, de syntaxis is alleen wat ze elke dag vlot lezen.

Wegwerpscripts die een GraphQL-endpoint aanroepen

Een eenmalige CLI-tool, een Node-script, een admin-taak — alles waar je types rondom de respons wil zonder je vast te leggen op een complete codegen-setup. Plakken, kopiëren, respons typen, script draaien. Wegwerp, maar net genoeg type-veilig om jezelf niet voor schut te zetten.

Veelgestelde vragen

Genereert het operatie-types (Query- / Mutation-resulttypes), of alleen schema-types?

Alleen schema-types — de types die in het SDL staan. Operatie-resultaattypes hangen af van de specifieke query of mutation die een client uitvoert, en daar is graphql-code-generator met de typed-document-node-plugin precies voor gebouwd. Deze pagina dekt de schema-helft: elke type, interface, enum, input, union en scalar in je SDL wordt een TS-declaratie.

Hoe worden nullable vs non-null velden afgehandeld?

Non-null-velden (name: String!) komen eruit als verplichte, niet-optionele TS-properties: name: string;. Nullable velden (name: String) komen er optioneel uit: name?: string;. De output blijft schoon — geen | null-unions overal — wat de meeste consumers willen. Wil je liever strict null checks, draai dan een find-and-replace over de output.

En list-types zoals [Order] of [Order!]!?

Lists worden TS-arrays. [Order!]! komt op een verplicht veld eruit als Order[]. [Order] komt op een optioneel veld eruit als Order[]. De element-nullability wordt voor de leesbaarheid platgeslagen — moet je het bewaren, dan kun je een gegenereerde T[] met de hand naar (T | null)[] omzetten, maar in de praktijk leest bijna geen enkele echte codebase de inner-nullability apart.

Hoe worden custom scalars afgehandeld?

Custom scalars (alles wat geen ID, String, Int, Float of Boolean is) vallen standaard op string met een // custom scalar-marker, zodat ze makkelijk te vinden en te verbreden zijn. Voor een DateTime-scalar zou je kunnen verbreden naar string | Date; voor een JSON-scalar naar unknown of een getypeerde vorm. De default string matcht wat de meeste servers via JSON over de lijn sturen.

Wordt mijn schema naar een server gestuurd?

Nee. De conversie draait volledig in je browser — het SDL wordt client-side getokenized en de TypeScript-output wordt direct in het rechterpaneel gerenderd. Niets wordt geüpload, niets gelogd. Veilig om interne of nog niet vrijgegeven schemas te plakken.

Doet de output round-trip terug naar hetzelfde SDL?

Nee — en dat is ook niet de bedoeling. De output is TypeScript, een andere taal. De TS-output terug in het SDL-paneel plakken levert een parse-fout op. Wil je je GraphQL SDL zelf formatteren, gebruik dan de hieronder gelinkte GraphQL Formatter; die is daarvoor gemaakt.

Andere GraphQL-tools

Types genereren is één onderdeel. Deze tools dekken de rest van de GraphQL-workflow:

GraphQL Schema naar TypeScript