Invoer

Uitvoer

Wat is de GraphQL Viewer?

Als je ooit een stuk GraphQL SDL hebt geplakt dat op één regel terugkwam en het probeerde te lezen, ken je het probleem. Types, velden, argumenten, directives en union members klappen allemaal op elkaar en de structuur is weg. Deze tool fixt dat. Plak je schema in het linkerpaneel en het rechterpaneel rendert het met indentatie van twee spaties, één veld per regel, argumenten inline en block-string-beschrijvingen netjes boven het type of veld dat ze documenteren.

De pretty-printer is zelfgemaakt — geen graphql npm-pakket dat in de pagina wordt geladen, dus de eerste paint blijft klein. Hij tokeniseert de SDL, loopt door de accolade-structuur en geeft het opnieuw uit met consistente spacing volgens de GraphQL-spec van oktober 2021. Hij kan elke SDL-constructie die je in de praktijk tegenkomt: type, interface, union, enum, input, scalar, extend, schema, list- en non-null-modifiers ([Foo!]!), default values, directives en triple-quote beschrijvingen. Al-mooi-opgemaakte invoer komt onveranderd terug.

Alles draait in je browser. Geen upload, geen schema dat ergens wordt opgeslagen. Plakken, lezen, kopiëren.

De GraphQL Viewer gebruiken

Drie snelle stappen. De buttons hieronder zijn de echte buttons op deze pagina.

Plakken, uploaden of een voorbeeld laden

Plak een GraphQL-schema in het linker Invoer-paneel. Klik op Uploaden voor een .graphql-, .graphqls- of .gql-bestand, of druk op Voorbeeld om een realistisch e-commerce-schema te laden. Snel voorbeeld van hoe geminifieerd SDL eruitziet:

type Order{id:ID! placedAt:DateTime! customer:Customer! items:[OrderItem!]! total:Money! status:OrderStatus!} type OrderItem{sku:String! name:String! quantity:Int! unitPrice:Money!}

Zowel server-stijl schemas (met extend type Query) als losstaande type-definities werken. De geaccepteerde vormen komen overeen met wat tools als Apollo Server parsen.

Lees de geformatteerde uitvoer

Het rechter Uitvoer-paneel rendert de geparseerde SDL met indentatie van twee spaties. Elk veld, elke enum-waarde en elke union member krijgt zijn eigen regel. Argumenten blijven inline op de veld-regel, dus signatures lezen natuurlijk. Beschrijvingen geschreven als block-strings ("""...""") blijven boven het type of veld dat ze beschrijven, wat de manier is die de Relay GraphQL-specificatie aanbeveelt om een schema te documenteren. Als de SDL onbalanced accolades of andere parse-fouten heeft, laat de viewer een vriendelijke melding zien in plaats van te crashen.

Kopiëren of downloaden

Druk op Kopiëren om het geformatteerde schema mee te nemen voor een pull request, doc of chat. Druk op Downloaden om het op te slaan als .graphql. De clear-button op het invoerpaneel zet je terug naar leeg. Het parsen gebeurt volledig client-side — je schema verlaat de pagina nooit.

Wanneer je dit echt zal gebruiken

Schema pull request reviews

Aan het reviewen van een schema-PR en de diff is moeilijk te lezen omdat het bestand door een code generator is gegaan die de opmaak heeft gestript? Plak de nieuwe versie hier, scan de structuur even, en ga dan terug naar de diff met een helderder mentaal model van wat er is veranderd. Vooral handig wanneer het team aan het itereren is op wat telt als goed schema-ontwerp.

Federation- en subgraph-debugging

Aan het debuggen van een Apollo-federation-gateway en het samengestelde supergraph-schema komt terug als één enorme blob? Plak de gemergede SDL erin, vind het type dat zich vreemd gedraagt, zie welke subgraph welk veld heeft bijgedragen. De federation-directives die in de uitvoer verschijnen worden samen met de rest van de schema-syntax getoond.

Een API documenteren

Publieke docs aan het schrijven voor een GraphQL-API die jouw team beheert? Drop het schema in de viewer, kopieer de geformatteerde versie naar de wiki of README. De boomvorm van types, interfaces en unions leest natuurlijk zodra hij is uitgelegd met één veld per regel.

Onboarden van nieuwe engineers

Een nieuw teamlid probeert de vorm van jouw GraphQL-API te leren. Een geformatteerd schema met de beschrijvingen zichtbaar boven elk type is een veel vriendelijker startpunt dan de niet-geformatteerde blob uit de codegen-output.

Veelgestelde vragen

Valideert het mijn schema, of formatteert het alleen?

Alleen formatteren. De viewer controleert balans van accolades en quotes net genoeg om te kunnen pretty-printen, maar verifieert niet of Query bestaat, of gerefereerde types gedefinieerd zijn, of dat directive-argumenten met hun definitie matchen. Voor volledige validatie gebruik je de referentie-implementatie graphql-js of haal je het door de startup-checks van je server.

Wordt mijn schema naar een server gestuurd?

Nee. De pretty-printer draait volledig in je browser. Niets wordt geüpload, niets wordt gelogd. Veilig om interne of niet-uitgebrachte schemas in te plakken.

Verwerkt het block-string-beschrijvingen?

Ja. Triple-quote-beschrijvingen ("""Een door een klant geplaatste bestelling.""") blijven behouden en worden uitgegeven op de regel boven het type of veld dat ze documenteren. Dit is de canonieke manier om SDL-documentatie te schrijven volgens de GraphQL-spec.

En directives en custom scalars?

Beide blijven behouden. @deprecated, @key en elke custom directive blijven inline op het veld. Custom scalars zoals scalar DateTime krijgen een eigen regel. De viewer probeert directive-semantiek niet te interpreteren — dat is aan jouw server.

Wordt al-geformatteerd SDL opnieuw geformatteerd?

Het is idempotent — pretty-printen van al-mooi-opgemaakt SDL geeft dezelfde uitvoer. Dus je kunt de viewer gerust draaien in een CI-check of een paste-and-compare-workflow zonder je zorgen te maken over whitespace-drift.

Hoe groot mag een schema zijn dat ik plak?

Alles wat je browser comfortabel kan renderen. Schemas met een paar honderd types zijn geen probleem. Boven de 5 MB begint de Ace-editor zelf trager te worden — dat is de bottleneck, niet de parser.

Andere GraphQL-tools

Bekijken is één deel van het werken met GraphQL. Deze tools doen de rest: