Entscheide danach, wer die API konsumiert und wie unterschiedlich ihre Datenbedürfnisse sind – nicht nach Hype. GraphQL gewinnt, wenn viele unterschiedliche Clients ihre eigenen Daten formen müssen; REST gewinnt, wenn Anfragen einheitlich, cachebar und einfach sind.
user -> posts -> comments) statt N REST-Round-Trips.GET-Modell von REST cached trivial auf jeder Ebene; GraphQL braucht Persisted Queries, um da heranzukommen.| Aspekt | GraphQL | REST |
|---|---|---|
| Over-/Under-Fetching | Per Design gelöst | Häufiges Problem |
| HTTP-/CDN-Caching | Schwierig (erfordert Arbeit) | Nativ und einfach |
| Query-Cost-/DoS-Kontrolle | Musst du hinzufügen | Von Natur aus begrenzt |
| Client-Flexibilität | Hoch | Niedrig |
| Server-Komplexität | Höher | Niedriger |
Sie schließen sich auch nicht aus – viele Systeme exponieren REST für öffentliche/cachebare Endpunkte und GraphQL für reichhaltige interne Clients.
Senior-Interviewer testen Urteilsvermögen, nicht Gefolgschaft. Die starke Antwort benennt die Achsen – Client-Vielfalt, Caching-Bedarf, Team-Reife, DoS-Angriffsfläche – und gibt die echten Kosten von GraphQL (Caching und Query-Cost-Kontrolle) zu, statt es als universell besser zu verkaufen.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden