GraphQL Playground Alternativen: GraphiQL 2 vs. Apollo Sandbox

1. Warum GraphQL Playground eingestellt wurde

Das ursprüngliche GraphQL Playground entstand bei Prisma und war jahrelang der De-facto-Standard für interaktive Query-Exploration. Seit 2020 wird es nicht mehr aktiv weiterentwickelt, Prisma hat das Repository offiziell archiviert und empfiehlt selbst den Umstieg auf modernere Tools. Wer heute noch das alte Playground einbindet, verzichtet auf Sicherheitsupdates, neue GraphQL-Spezifikations-Features und aktives Bugfixing. Die Suche nach einer GraphQL Playground Alternative ist deshalb längst keine Kür mehr, sondern für viele Teams überfällig.

Der Umstieg betrifft nicht nur die Optik. GraphQL Playground basierte auf einer älteren React-Version und einem GraphiQL-Fork, der mit neueren Schema-Features wie @oneOf-Input-Objekten oder inkrementeller Auslieferung über @defer und @stream nicht sauber umgehen kann. Eine moderne GraphQL Playground Alternative muss diese Spezifikations-Erweiterungen unterstützen, um für aktuelle Schemas überhaupt brauchbar zu sein.

Zwei Nachfolger haben sich am Markt durchgesetzt: GraphiQL selbst hat mit Version 2 ein umfassendes Redesign erhalten und bringt jetzt viele Playground-Features nativ mit, während Apollo mit der Apollo Sandbox einen eigenen, stärker cloud-integrierten Weg geht. Beide sind valide Antworten auf dieselbe Frage, unterscheiden sich aber deutlich in Architektur und Zielgruppe.

2. GraphiQL 2: Setup, Explorer-Plugin, Auth-Header

GraphiQL 2 ist die offizielle Referenzimplementierung der GraphQL Foundation und wird seit dem großen Rewrite als eigenständige, eingebettete React-Komponente ausgeliefert. Das Setup ist bewusst minimalistisch gehalten, ein einzelner Import reicht für eine funktionierende Instanz, die direkt gegen einen beliebigen GraphQL-Endpunkt spricht.

# Add GraphiQL 2 as a standalone dev tool
npm install graphiql graphql

# Or mount it directly inside an Express/Node backend for local testing
npm install graphql-http

Das Explorer-Plugin ist der größte Fortschritt gegenüber dem alten Playground: Es rendert das komplette Schema als klickbaren Baum, mit dem Nutzer Felder per Checkbox auswählen können, ohne eine einzige Zeile GraphQL-Syntax selbst zu tippen. Für Teams, in denen nicht jeder täglich GraphQL schreibt, etwa Produktmanager oder QA-Mitarbeiter, senkt das die Einstiegshürde erheblich.

// graphiql-setup.js — mounting GraphiQL 2 with the Explorer plugin and auth headers
import { createRoot } from 'react-dom/client'
import { GraphiQL } from 'graphiql'
import { explorerPlugin } from '@graphiql/plugin-explorer'
import 'graphiql/graphiql.css'
import '@graphiql/plugin-explorer/dist/style.css'

const explorer = explorerPlugin()

function fetcher(graphQLParams, opts) {
  return fetch('/graphql', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${localStorage.getItem('devToken')}`,
      ...opts.headers,
    },
    body: JSON.stringify(graphQLParams),
  }).then((res) => res.json())
}

createRoot(document.getElementById('graphiql')).render(
  <GraphiQL fetcher={fetcher} plugins={[explorer]} />
)

Auth-Header lassen sich sowohl über die eingebaute Headers-Editor-Leiste als auch, wie im Beispiel gezeigt, fest im Fetcher hinterlegen. Für lokale Entwicklung ist letzteres praktisch, für gemeinsam genutzte Instanzen sollte jedoch die Headers-Leiste bevorzugt werden, damit nicht jeder Entwickler denselben Token im Client-Code sieht.

3. Apollo Sandbox: Cloud-Variante vs. eingebettete Sandbox

Apollo Sandbox existiert in zwei Formen: als gehostete Web-App unter studio.apollographql.com/sandbox, die gegen jeden beliebigen erreichbaren GraphQL-Endpunkt spricht, und als eingebettete React-Komponente über @apollo/sandbox, die sich wie GraphiQL direkt in eine eigene Seite integrieren lässt. Diese zweigleisige Verfügbarkeit ist ein zentraler Unterschied zu GraphiQL 2, das grundsätzlich immer selbst gehostet wird.

// embedded-sandbox.js — mounting Apollo Sandbox with a fixed endpoint and headers
import { ApolloSandbox } from '@apollo/sandbox/react'

function DevPortal() {
  return (
    <ApolloSandbox
      initialEndpoint="https://api.internal.example.com/graphql"
      initialState={{
        document: 'query GetOrders { orders { id status } }',
        headers: { Authorization: 'Bearer <paste-token-here>' },
      }}
      className="sandbox-frame"
    />
  )
}

Die gehostete Variante ist besonders für schnelles, spontanes Debugging praktisch, weil kein lokales Setup nötig ist. Ein Entwickler kann die URL des Endpunkts einfach in die Cloud-Sandbox einfügen und sofort loslegen, sofern der Endpunkt öffentlich oder zumindest über eine erreichbare URL angesprochen werden kann. Für interne, nur im VPN erreichbare APIs ist dagegen ausschließlich die eingebettete Variante praktikabel.

4. Schema-Introspection und Docs-Explorer im Vergleich

Beide Tools nutzen Standard-Introspection, um Typen, Felder und Argumente automatisch zu dokumentieren, unterscheiden sich aber in der Darstellung. GraphiQL 2 zeigt Dokumentation in einer klassischen Seitenleiste mit Suchfunktion, die bei sehr großen Schemas mit hunderten Typen manchmal unübersichtlich wird. Apollo Sandbox strukturiert denselben Inhalt zusätzlich nach Query-Root-Feldern gruppiert und hebt häufig genutzte Operationen optisch stärker hervor.

Ein Detail, das in der Praxis oft übersehen wird: Beide Tools zeigen Deprecation-Warnungen für als @deprecated markierte Felder direkt im Docs-Explorer an, inklusive des im Schema hinterlegten Grundes. Das ist besonders wertvoll bei API-Evolution, weil Konsumenten sofort sehen, welches Feld sie meiden sollten, ohne im Changelog nachzuschauen.

5. Auth-Handling: Header-Presets, Cookies, OAuth-Flows

Beim Testen authentifizierter Queries zeigen sich die größten praktischen Unterschiede. GraphiQL 2 bietet eine simple Headers-Textarea, in der beliebige JSON-Header eingetragen werden, plus die Möglichkeit, per shouldPersistHeaders diese Werte im LocalStorage zwischen Sessions zu behalten. Für OAuth-Flows mit kurzlebigen Tokens bedeutet das manuelles Kopieren nach jedem Refresh, es sei denn, ein Team baut sich ein eigenes Browser-Plugin oder Skript, das den Header automatisch aktualisiert.

// graphiql-persist-auth.js — persisting the auth header across sessions
<GraphiQL
  fetcher={fetcher}
  shouldPersistHeaders={true}
  headers={JSON.stringify({ Authorization: 'Bearer <token>' }, null, 2)}
/>

Apollo Sandbox unterstützt zusätzlich benannte "Header-Presets" innerhalb eines Workspace, sodass ein Team mehrere Auth-Konfigurationen (etwa "Staging Admin", "Production Read-Only") anlegen und per Klick wechseln kann, statt Header-Werte jedes Mal neu einzutippen. Cookie-basierte Auth funktioniert bei beiden Tools nur zuverlässig, wenn Same-Origin-Regeln eingehalten werden oder CORS-Header credentials: include explizit erlauben.

6. Collaboration-Features: Sharing, History, Workspaces

Hier trennt sich die Philosophie beider Tools am deutlichsten. GraphiQL 2 speichert Query-History rein lokal im Browser, ein geteiltes Team-Postfach für Queries existiert nicht nativ, wer Queries teilen will, kopiert den Text manuell in Slack oder ein Wiki. Apollo Sandbox dagegen ist an Apollo Studio angebunden, sobald ein Nutzer eingeloggt ist: Queries lassen sich als Link teilen, in Ordnern organisieren und als Team-Workspace mit Kollegen synchronisieren.

Für kleine Teams ohne Apollo-Studio-Abo ist dieser Unterschied meist zweitrangig, für größere Organisationen mit mehreren API-Konsumenten-Teams kann die zentrale Query-Bibliothek von Apollo Sandbox jedoch erheblich Zeit sparen, weil bewährte Queries nicht ständig neu geschrieben werden müssen.

7. Selbst hosten vs. Cloud: Datenschutz und Firmennetz

GraphiQL 2 läuft ausschließlich lokal oder selbst gehostet, es gibt keine Cloud-Variante und damit auch keine Abhängigkeit von einem externen Dienst. Für Unternehmen mit strikten Datenschutzanforderungen oder Compliance-Vorgaben, die keine internen API-Strukturen an Drittanbieter senden dürfen, ist das oft der ausschlaggebende Punkt für GraphiQL 2 als GraphQL Playground Alternative.

Die gehostete Apollo Sandbox sendet Query-Text und Schema-Introspection-Daten an Apollo-Server, auch wenn der eigentliche GraphQL-Request direkt vom Browser zum eigenen Backend geht. Für rein interne, sicherheitskritische APIs sollte deshalb konsequent die eingebettete @apollo/sandbox-Variante hinter dem eigenen Auth-Layer verwendet werden, nicht die gehostete Studio-Version.

8. Integration in eigene Docs-Seiten und interne Portale

Beide Tools lassen sich als eingebettete Komponente in ein bestehendes Entwicklerportal integrieren, etwa neben handgeschriebener API-Dokumentation oder einem internen Wiki. GraphiQL 2 fügt sich durch sein React-Komponenten-Modell nahtlos in bestehende React-Anwendungen ein und lässt sich per CSS-Variablen an das eigene Farbschema anpassen. Apollo Sandbox bietet über embeddedSandboxConfig ähnliche Anpassungsmöglichkeiten inklusive Standard-Query und initialem Endpunkt.

Für Teams, die eine GraphQL Playground Alternative direkt neben ihrer öffentlichen API-Referenz anzeigen wollen, ist das ein entscheidender Faktor: Ein isoliertes Tool in einem separaten Tab wird seltener genutzt als eine Explorer-Instanz, die direkt in der Dokumentation eingebettet ist und mit einem Klick aus einem Codebeispiel heraus vorausgefüllt startet.

9. GraphiQL 2 vs. Apollo Sandbox im direkten Vergleich

Die Wahl zwischen beiden GraphQL Playground Alternativen hängt stark davon ab, ob bereits Apollo-Tooling im Unternehmen genutzt wird und wie wichtig Team-Collaboration-Features gegenüber vollständiger Datenhoheit gewichtet werden.

Für Teams mit hohen Datenschutzanforderungen und ohne Bedarf an Team-übergreifendem Query-Sharing ist GraphiQL 2 die klarere Wahl unter den GraphQL Playground Alternativen. Wer bereits Apollo Studio für Schema-Registry und Monitoring nutzt, profitiert dagegen von der nahtlosen Integration der Apollo Sandbox und den zusätzlichen Collaboration-Features.

10. Zusammenfassung

Beide vorgestellten GraphQL Playground Alternativen lösen die Aufgabe des eingestellten Prisma-Tools zuverlässig, unterscheiden sich aber im Detail deutlich. GraphiQL 2 punktet mit voller Datenhoheit, keiner Drittanbieter-Abhängigkeit und einem starken Explorer-Plugin für Nutzer ohne GraphQL-Erfahrung. Apollo Sandbox punktet mit Team-Collaboration, benannten Header-Presets und einer gehosteten Variante für spontanes Debugging ohne lokales Setup.

Die Entscheidung sollte nicht allein an der Optik festgemacht werden, sondern an konkreten Anforderungen: Wie streng sind Datenschutzvorgaben, wie wichtig ist Query-Sharing im Team, und wird bereits Apollo-Tooling für Schema-Registry oder Monitoring eingesetzt. Wer diese Fragen klar beantwortet, findet unter den GraphQL Playground Alternativen schnell die passende Lösung.

11. FAQ: GraphQL Playground Alternativen