Nimm GraphQL, wenn mehrere verschiedene Clients unterschiedliche Formen derselben verknüpften Daten brauchen und du keine Lust mehr auf Overfetching oder einen Endpoint pro Screen hast. Nimm REST, wenn die Oberfläche klein ist, HTTP-Caching zählt oder die Konsumenten Maschinen statt Screens sind. GraphQL beseitigt keine Komplexität; es verschiebt sie von Endpoint-Wildwuchs zu Resolver-Tiefe, Query-Kostenlimits und Caching, das jetzt dir gehört.
Warum Interviewer das fragen
Das prüft, ob du Technologie aus Randbedingungen wählst oder aus Mode. Der Interviewer will eine echte Abwägung hören, besonders zu Caching und Query-Kosten, weil GraphQL-Teams genau dort nach einem halben Jahr Schmerzen bekommen. Wer beide Seiten argumentieren und sich dann festlegen kann, wirkt wie jemand, dem man Architekturentscheidungen geben kann; wer nur GraphQL-Vorteile aufzählt, nicht.
So baust du deine Antwort auf
- Nenn die Bedingung, die GraphQL lohnenswert macht.
- Nenn die Bedingung, die REST zur besseren Voreinstellung macht.
- Nenn die operativen Kosten, die GraphQL hinzufügt.
- Lande bei einer Empfehlung für den gegebenen Kontext.
Beispielantwort
Mein Entscheidungsfaktor ist die Vielfalt der Clients. Gibt es einen Web-Client und bilden die Endpoints sauber die Screens ab, ist REST weniger Maschinerie, und du bekommst HTTP-Caching, CDN-Verhalten und Debugbarkeit mit curl gratis. Sobald du eine Web-App, eine Mobile-App und eine Partner-Integration hast, die alle unterschiedliche Ausschnitte desselben Graphen wollen, wird REST entweder zu fünfzig maßgeschneiderten Endpoints oder zu fetten Antworten, die Mobilnutzer im Mobilfunk bezahlen. Dann zahlt sich GraphQL aus. Was ich das Team vorher wissen lasse, ist, was mitkommt. Du brauchst Tiefen- und Kostenlimits für Queries, sonst hämmert eine einzige verschachtelte Query die Datenbank, du brauchst Batching nach Dataloader-Art, sonst produzieren Resolver standardmäßig N-plus-eins-Queries, und HTTP-Caching funktioniert größtenteils nicht mehr, weil alles ein POST auf eine URL ist, du cachest also stattdessen auf Resolver- oder Entitätsebene. Bei einem mittelgroßen Produkt würde ich ehrlich gesagt mit REST starten und GraphQL erst ergänzen, wenn ein zweiter, sehr anderer Client auftaucht.
Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.
So funktioniert esNachfragen, mit denen du rechnen solltest
- Wie würdest du eine bösartige, tief verschachtelte Query stoppen?
- Wie löst du Caching in GraphQL, wenn alles über einen Endpoint läuft?
- Wie versionierst du ein GraphQL-Schema, ohne Clients zu brechen?
Weitere Fragen für Full-Stack-Entwickler
Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.
Meine Fragen vorhersagen