Die bisherige Version links einfügen
Die Prüfung läuft von alt nach neu. Wer die Seiten vertauscht, ändert Entfernen in Hinzufügen und damit auch die Risikoeinstufung. Die Tauschfunktion berechnet den Vergleich neu.
GraphQL-Dokumente
Das veröffentlichte vollständige SDL gehört links, der geplante Stand rechts. Die Richtung entscheidet über Entfernen und Hinzufügen.
Zwei vollständige Schema-SDLs eingeben oder das Beispiel laden.
Beide SDL-Texte werden nur in diesem Browser analysiert. Keine API-Abfrage, kein Upload, kein Verlauf und keine Eingabe in der URL.
GraphQL.js stuft Breaking Changes und potenziell gefährliche Änderungen ein. Weitere Struktur- und Deprecated-Änderungen gelten dadurch nicht automatisch als sicher.
Je SDL höchstens 100.000 Zeichen, 20.000 Tokens und 100 Verschachtelungsebenen. Nach 8 Sekunden endet der Vergleich.
Zwei vollständige Schema-SDLs eingeben oder das Beispiel laden.
Ein GraphQL-Schema-Vergleich hilft, wenn ein Pull Request viele Zeilen durch neue Reihenfolge oder Einrückung verändert. Entscheidend für bestehende Clients sind jedoch Feldnamen, Typen und Argumente, nicht die Position der Definitionen im Text.
Der Bericht trennt die strukturelle Sicht von den Regeln für Breaking Changes. Neue Felder und Deprecated-Markierungen bleiben sichtbar, selbst wenn GraphQL.js dafür keine Gefährdung meldet; eine fehlende Warnung ist kein Beweis für Sicherheit. Diese Schemaänderungen lassen sich so ohne Textdiff-Rauschen lesen.
Änderungen am Vertrag sehen, ohne Formatierung als Risiko zu zählen.
Der GraphQL-Schema-Vergleich baut aus beiden SDL-Texten gültige Schemata und vergleicht Typen, Felder und Argumente nach Pfad. Umgestellte Definitionen lösen keinen Treffer aus; ein entferntes Feld erscheint mit seinem Namen und bisherigen Typ.
Ein neuer Enum-Wert kann Client-Code mit vollständiger Fallunterscheidung überraschen. Ein neues @deprecated-Attribut entfernt dagegen kein Feld. Der GraphQL-Schema-Vergleich führt beide Ereignisse getrennt und nennt unbewertete Ergänzungen nicht pauschal sicher.
Die Prüfung läuft von alt nach neu. Wer die Seiten vertauscht, ändert Entfernen in Hinzufügen und damit auch die Risikoeinstufung. Die Tauschfunktion berechnet den Vergleich neu.
Nach Änderungen wartet die Automatik ungefähr 350 ms. Bei langen SDL-Dateien lässt sie sich abschalten; Vergleichen oder Strg/Cmd+Enter verarbeitet dann erst das aktuelle Paar.
Jede Eingabeänderung macht den bisherigen Bericht ungültig und sperrt Kopieren sowie Download. Eine Fehlermeldung nennt das betroffene SDL und nach Möglichkeit Zeile und Spalte. Der Export enthält alle Einträge, auch wenn zunächst nur 100 angezeigt werden.
Typen, Felder, Argumente, Input-Felder, Enums, Unions und Direktiven werden strukturell verglichen. Leerraum und Definitionsreihenfolge sind keine Vertragsänderung.
Die Bibliothek liefert die Breaking- und Dangerous-Regeln; der Regelcode steht beim Befund. Andere Strukturänderungen bleiben prüfbar, ohne ein unverdientes „sicher“ zu erhalten.
Änderungen am @deprecated-Grund erscheinen gesondert. Wird ein längst veraltetes Feld tatsächlich entfernt, bleibt es nach der Standardregel ein Breaking Change.
Ein zuvor verpflichtendes Mutation-Argument nullable zu machen, erweitert normalerweise die akzeptierten Werte. GraphQL.js bewertet diese Richtung nicht als Breaking Change; die umgekehrte Richtung kann alte Aufrufe ohne Argument zurückweisen.
Ein weiterer Enum-Wert ist ein potenziell gefährlicher Wechsel: Eine bestehende Abfrage bleibt zwar gültig, aber ein Client mit erschöpfender Fallunterscheidung könnte den neuen Wert nicht behandeln.
Zwei SDL-Stände enthalten keine Information, dass eine Umbenennung beabsichtigt war. Der GraphQL-Schema-Vergleich zeigt daher den alten Typ als entfernt und den neuen als hinzugefügt. Eine Übergangsphase muss im API-Design geplant werden.
Eine Mutation ist ein Feld des Mutation-Wurzeltyps und kann @deprecated tragen. Die Kennzeichnung erhält alte Aufrufe; erst das spätere Löschen wird nach den Standardregeln als Breaking Change erfasst.
Wird ein Rückgabefeld von non-null zu nullable geändert, können Annahmen generierter Clients ungültig werden. GraphQL.js stuft das als Breaking Change ein. Auch die Gegenrichtung braucht Resolver-Tests.
Ein konkretes Dokument macht Probleme?
Altes und geplantes SDL nebeneinander prüfen, alle Risikoklassen lesen und den aktuellen Bericht herunterladen.