GraphQL vs REST: Ein Duell, das man gestern hätte beginnen sollen
\n\nEine vertraute Situation: Sie schreiben ein neues Projekt in JavaScript (oder Node.js), und plötzlich stellt sich die Frage – was soll für die Kommunikation zwischen Frontend und Backend verwendet werden? Das klassische REST oder das moderne GraphQL? Die Debatten zu diesem Thema reißen nicht ab, und jeder Entwickler hat seine eigene „stahlharte“ Meinung.
\n\nSeien wir ehrlich: REST ist der altbewährte Freund, der einen nie im Stich lässt. GraphQL ist der kühne Neuling, der verspricht, all Ihre Probleme zu lösen. Aber wie wählt man aus? Ich zeige Ihnen nicht nur trockene Vergleichstabellen, sondern echte praxisnahe Beispiele in JavaScript. Sie werden sehen, wie der Code aussieht, wo Fallstricke lauern und – am wichtigsten – wann man was verwendet.
\n\nÜbrigens, wenn Sie in Python entwickeln (und diese Seite handelt von Python, nicht vergessen), dann sind die Prinzipien der Auswahl zwischen diesen Technologien sehr ähnlich. Aber heute sprechen wir über JavaScript – die Sprache, die sowohl auf dem Client als auch auf dem Server regiert.
\n\nKurze Einführung: REST und GraphQL in 60 Sekunden
\n\nREST (Representational State Transfer)
\nDies ist ein Architekturstil, bei dem jede Ressource (Benutzer, Beitrag, Kommentar) ihre eigene URL hat. Sie machen eine GET-Anfrage an /api/users/1 – Sie erhalten den Benutzer. Sie möchten seine Beiträge? Gehen Sie zu /api/users/1/posts. Alles einfach, vorhersehbar, aber... manchmal zu ausführlich.
GraphQL
\nDies ist eine Abfragesprache und eine Laufzeitumgebung. Sie haben einen einzigen Endpunkt (normalerweise /graphql), und Sie entscheiden selbst, welche Daten Sie erhalten möchten. Kein Over-fetching (wenn 50 Felder kommen, aber nur 3 benötigt werden) und kein Under-fetching (wenn 5 Anfragen nötig sind, um eine Seite zusammenzustellen).
Praxistauglicher Vergleich: Code in JavaScript schreiben
\n\nStellen wir uns eine typische Aufgabe vor: Auf einer Seite soll das Profil eines Benutzers mit seinen letzten drei Beiträgen angezeigt werden. Vergleichen wir beide Ansätze.
\n\nBeispiel REST API mit Express (Node.js)
\n\n// REST-Server mit Express\nconst express = require('express');\nconst app = express();\n\napp.get('/api/users/:id', (req, res) => {\n // Alle Benutzerdaten zurückgeben\n const user = users.find(u => u.id === req.params.id);\n res.json(user); // { id, name, email, phone, address, ... }\n});\n\napp.get('/api/users/:id/posts', (req, res) => {\n // Alle Beiträge des Benutzers zurückgeben\n const posts = posts.filter(p => p.userId === req.params.id);\n res.json(posts); // [{ id, title, body, createdAt, ... }]\n});\n\n// Client-Code (Frontend mit fetch)\nasync function loadProfile(userId) {\n // Erste Anfrage – Benutzer abrufen (es kommt viel Überflüssiges)\n const userResponse = await fetch(`/api/users/${userId}`);\n const user = await userResponse.json();\n \n // Zweite Anfrage – Beiträge abrufen (wieder überflüssige Daten)\n const postsResponse = await fetch(`/api/users/${userId}/posts`);\n const allPosts = await postsResponse.json();\n \n // Nur die 3 letzten Beiträge nehmen\n const latestPosts = allPosts.slice(0, 3);\n \n return { user, posts: latestPosts };\n}\n\nDas Problem ist offensichtlich: Wir haben viele unnötige Daten erhalten (Over-fetching). Warum brauchen wir email, phone, address, wenn wir nur den Namen und das Avatar anzeigen? Und es können 100 Beiträge sein, aber wir brauchen nur 3.
\n\nBeispiel GraphQL mit Apollo Server (Node.js)
\n\n// GraphQL-Schema\nconst typeDefs = `\n type User {\n id: ID!\n name: String\n avatar: String\n posts(limit: Int): [Post]\n }\n\n type Post {\n id: ID!\n title: String\n body: String\n }\n\n type Query {\n user(id: ID!): User\n }\n`;\n\n// Resolver (Logik zum Abrufen der Daten)\nconst resolvers = {\n Query: {\n user: (parent, { id }) => users.find(u => u.id === id),\n },\n User: {\n posts: (parent, { limit }) => {\n let result = posts.filter(p => p.userId === parent.id);\n if (limit) result = result.slice(0, limit);\n