Du willst eine API, die sich erweitern lässt, ohne dass jedes neue Feature ein Architektur-Drama wird. Hier ist die ehrliche Entscheidungshilfe: REST, GraphQL oder tRPC.
API-Design eskaliert meistens nicht wegen Technik. Sondern wegen Scope: neue Clients, externe Integrationen, Performance-Druck, Security-Anforderungen, “kannst du mal schnell…?”. Und plötzlich ist dein “kleines Backend” ein Produkt.
Deshalb: Lass uns REST vs GraphQL vs tRPC nicht als Religionskrieg führen, sondern als Werkzeugwahl. Das Ziel ist nicht “modern”, sondern: stabil liefern, einfach betreiben, sauber erweitern.
Ich geb dir klare Use Cases, eine Vergleichstabelle, einen Umsetzungsplan und die typischen Fehler, die später richtig Zeit (und Nerven) kosten.
Bitte wähle zuerst eine Zusammenfassungsart aus.KI-Zusammenfassung
- REST ist dein Default, wenn du externe Integrationen, Caching/HTTP-Standards und klare Ressourcengrenzen willst.
- GraphQL lohnt sich, wenn du viele Clients mit unterschiedlichen Datenbedürfnissen hast und “Over/Underfetching” wirklich weh tut.
- tRPC ist stark, wenn du ein TypeScript-Stack bist und eine Produkt-App baust (end-to-end Types, schnelle DX).
- Wenn du Public API machst: tRPC nur, wenn du bewusst auf TS-Konsumenten setzt. Sonst REST (oder GraphQL) + Vertrag (OpenAPI/Schema).
- Wenn du Angst vor GraphQL-Abuse hast: berechtigt – du brauchst Limits (Depth/Complexity), Persisted Queries oder strikte Policies.
Erst Realität, dann Stil: 7 Fragen vor der Technik
- Wer konsumiert die API? Nur deine eigene App? Mehrere Frontends? Externe Partner?
- Wie viele Clients? Web, Mobile, Admin, Integrationen, Bots…?
- Wie ändern sich Datenbedürfnisse? ständig neue “Widgets”/Listen/Filter oder eher stabile Flows?
- Wie wichtig ist HTTP-Caching/CDN? Wenn du stark auf Caching setzt, hat REST Vorteile.
- Wie wichtig ist ein maschinenlesbarer Vertrag? SDKs, Doku, Tests, Tools, Security Reviews.
- Wie viel Governance hast du? Schema-Review, Deprecations, Breaking-Change-Prozess?
- Wie viel Security/Abuse-Risiko? Rate Limits, Query Abuse, BOLA/BFLA & Co (OWASP API Top 10).
- GraphQL wird weiter standardisiert im HTTP-Kontext (GraphQL over HTTP hat eigene Spezifikationsarbeit). Das macht Interop besser – aber du musst es trotzdem gut betreiben.
- Type-safe APIs (tRPC & Co) sind “DX-Gold”, aber oft eher Produkt-intern als Partner-öffentlich.
- Viele Teams landen bei einem Mix: REST für Public/Integrationen, GraphQL oder tRPC intern als BFF.
REST: boring – und genau deshalb oft richtig
Wann REST glänzt
- Public APIs & Integrationen: HTTP ist überall, Tooling ist riesig.
- CDN/Caching: GET/Cache-Control/ETag & Co sind “Standard-Mechanik”.
- Klare Ressourcen: wenn deine Domain gut in Ressourcen/Collections passt.
- Verträge & Doku: OpenAPI ist de-facto Standard für HTTP APIs (und 2025/2026 relevant weiterentwickelt).
Wo REST nervt
- Viele Clients, viele Varianten: du baust plötzlich 12 Endpoints “für Mobile”, “für Dashboard”, “für Export”.
- Over/Underfetching: du holst zu viel oder musst mehrere Requests orchestrieren.
- Versioning-Drama: wenn du Breaking Changes nicht im Griff hast und “v1/v2/v3” wild wächst.
- REST ohne Vertrag ist wie Baustelle ohne Plan: OpenAPI spart dir Doku- und Client-Chaos.
- Statt “v2”: versuch erst additive Changes (neue Felder/Endpunkte) + Deprecation-Policy.
GraphQL: stark bei vielen Clients – aber du brauchst Regeln
Wann GraphQL Sinn macht
- Viele Frontends mit unterschiedlichen Daten: Web will “viel”, Mobile will “wenig”, Admin will “anders”.
- Schnelle UI-Iterationen: neue Screens ohne ständig Backend-Endpunkte nachzuziehen.
- Schema als Contract: GraphQL ist per Definition schema-first. Die Spezifikation ist offiziell versioniert (Latest Release z.B. September 2025; Working Drafts laufen weiter).
Was GraphQL nicht automatisch löst
- Performance: N+1 ist real. DataLoader/Batching ist kein Nice-to-have.
- Abuse: “Gib mir alles, tief verschachtelt” – du brauchst Depth/Complexity Limits oder Persisted Queries.
- Caching: Du kannst cachen, aber es ist nicht so “native” wie REST-GET per CDN. Das muss man planen.
- GraphQL ohne Query-Limits: ein einziger böser Query kann deine DB grillen (oder zumindest dein Budget).
- “Wir machen alles in GraphQL”: am Ende sind Uploads, Webhooks, Files, Auth-Flows doch wieder “REST daneben”.
- Schema wächst ohne Governance: niemand weiß mehr, was deprecated ist und was noch genutzt wird.
tRPC: TypeScript-Speedrun, aber nicht für jeden Markt
Was tRPC dir wirklich bringt
tRPC ist eine TypeScript-first API-Lösung: Du definierst Procedures/Router im Backend und bekommst im Client End-to-End Types, ohne extra Schema-Datei. Das ist brutal schnell für Produktentwicklung. tRPC ist aktuell in der v11-Linie dokumentiert und migrierbar von v10.
Wann tRPC richtig stark ist
- Du bist 100% TypeScript (Backend + Frontend) und willst maximale DX.
- Eine App, ein Team: du kontrollierst Client & Server.
- Schnelles Iterieren: Feature bauen, Types kommen “mit”, weniger Boilerplate.
Wann tRPC dir Ärger macht
- Public API / Partner: Externe wollen oft sprachagnostische Verträge/SDKs. tRPC ist dafür nicht der Default.
- Langfristige Governance: Du brauchst trotzdem Deprecation, Versioning-Strategien und klare Ownership.
- Observability & Edge Cases: Du musst Logging, Rate Limits, AuthZ, Input-Validation sauber machen – wie überall.
- tRPC ist genial als internes BFF: Frontend spricht tRPC, Backend spricht nach außen REST/Webhooks.
- Wenn du später Partner integrieren willst: plane früh einen Public-Contract-Layer (z.B. REST + OpenAPI).
Vergleichstabelle: wann welches API-Design?
| Kriterium | REST | GraphQL | tRPC |
|---|---|---|---|
| Beste Stärke | Interop, HTTP-Standards, Caching, Tooling | Flexible Queries für viele Clients | End-to-End Types & schnelle DX (TS) |
| Typischer Sweet Spot | Public APIs, Integrationen, klassische CRUD | Produkt mit mehreren Frontends, datengetriebene UIs | Monorepo/TS-Stack, schnelles Produktteam |
| Risiko | Endpoint-Sprawl, Versionswildwuchs | Query-Abuse, N+1, Governance nötig | Public API schwierig, TS-Kopplung |
| Versioning/Evolution | über additive Changes + klare Deprecation, ggf. v2 | Schema-Evolution + Deprecation statt harte Versionssprünge | API-Änderungen wirken direkt in Types; braucht Disziplin |
| Security/Abuse | Rate Limits pro Endpoint, klassische Patterns | zusätzlich Depth/Complexity/Persisted Queries | wie REST (Inputs, AuthZ, Rate Limits), plus “internal” schützt nicht automatisch |
| Beste Wahl, wenn… | du externe Konsumenten erwartest | du UI-Teams entkoppeln willst | du Geschwindigkeit brauchst und TS durchziehst |
So setzt du’s um
8-Schritte-Plan: API-Design ohne Eskalation
- Entscheide “Public vs Internal”: Public = Vertrag/Kompatibilität first. Internal = DX/Speed first.
- Definiere 3–5 Kern-Use-Cases: welche Datenflüsse sind die wichtigsten?
- Wähle 1 Default: z.B. REST für Public, tRPC/GraphQL als BFF. Nicht alles mischen “weil geht”.
- Lege Governance fest: Deprecation-Policy, Review-Prozess, Ownership.
- Security-Baseline: AuthN/AuthZ, Object-Level Checks (OWASP), Rate Limits, Logging, Audit.
- Performance-Guardrails: REST: pagination, caching. GraphQL: batching, depth/complexity, persisted queries.
- Observability: Request IDs, structured logs, metrics (p95, error rate), tracing wo nötig.
- Dokumentation/SDK: REST: OpenAPI. GraphQL: Schema + docs. tRPC: TS client + klare “public surface” Regeln.
Mini-Use-Cases (damit es real bleibt)
- SaaS mit Partnern: REST + OpenAPI, intern optional GraphQL/tRPC als BFF.
- Produkt mit Web + Mobile + Admin: GraphQL (wenn du Governance + Limits machst) oder REST mit BFF-Schicht.
- Ein TS-Team, eine App: tRPC für Speed, später ggf. REST Layer für Integrationen.
// Entscheidung in einem Satz:
# Public = REST (mit OpenAPI)
# Multi-Client UI = GraphQL (mit Limits & Governance)
# TS Monorepo = tRPC (intern/BFF), Public später extraTypische Fehler & wie du sie vermeidest
- Fehler: “Wir nehmen GraphQL, dann brauchen wir keine Architektur mehr.” Fix: Query-Limits, Batching, Deprecation und Ownership sind Pflicht.
- Fehler: tRPC als öffentliche Partner-API. Fix: tRPC intern nutzen; für extern REST/GraphQL mit Contract.
- Fehler: REST ohne Contract/Versioning-Strategie. Fix: OpenAPI + additive Changes + klare Deprecation.
- Fehler: “Internal ist sicher.” Fix: OWASP API Top 10 gilt auch intern: AuthZ auf Objekt-Ebene, Logging, Rate Limits.
- Fehler: Zu viele Stile gleichzeitig. Fix: 1 Default + Ausnahmen nur mit Grund (und dokumentiert).
Fazit: die pragmatische Empfehlung
Wenn du nichts Spezielles brauchst: REST ist weiterhin der beste Default – vor allem für Public APIs und Integrationen.
Wenn deine UI ständig neue Datenkombis will: GraphQL kann massiv Stress rausnehmen, wenn du Limits, Batching und Governance ernst nimmst.
Wenn du TS durchziehst und schnell liefern willst: tRPC ist ein Top-Tool – aber behandle es als Produkt-intern/BFF, nicht automatisch als Partner-Schnittstelle.
Nächster Schritt: Schreib deinen Top-3 Use Case auf (z.B. “Dashboard”, “Mobile List”, “Partner Export”) und prüf: Ist das eher “Ressourcen & Caching” (REST), “flexible Datenkombis” (GraphQL) oder “TS-Speed” (tRPC)?
FAQ
Wann ist REST besser als GraphQL?
Wenn du externe Integrationen erwartest, HTTP-Caching/CDN wichtig ist, und du klare Ressourcengrenzen willst. REST + OpenAPI ist dafür extrem robust.
Für wen lohnt sich GraphQL wirklich?
Für Produkte mit mehreren Clients und dynamischen UIs, wo Over/Underfetching messbar nervt. Aber nur, wenn ihr Governance + Limits (Depth/Complexity/Persisted Queries) ernst nehmt.
Ist tRPC nur was für TypeScript?
Realistisch: ja, das ist sein Sweet Spot. tRPC ist TypeScript-first und glänzt, wenn Client und Server TS sind. Für sprachagnostische Partner-APIs ist REST/GraphQL meist einfacher.
Wie versioniert man GraphQL ohne Breaking Changes?
Typisch ist Schema-Evolution: additive Felder/Typen hinzufügen, Altes deprecaten, Usage messen, dann entfernen. Das braucht Disziplin und Kommunikation, aber verhindert “v2/v3” Chaos.
Wie verhindere ich GraphQL Query Abuse (Depth/Complexity)?
Mit Guardrails: Depth/Complexity Limits, Batching, Timeouts, Rate Limits, ggf. Persisted Queries. Ohne das kann GraphQL bei Abuse sehr teuer werden.
Brauche ich OpenAPI trotz GraphQL oder tRPC?
Für REST: ja, meistens. Für GraphQL: du hast das Schema als Vertrag, OpenAPI ist optional. Für tRPC: wenn du externe Konsumenten willst oder Doku/SDK tooling brauchst, ist ein zusätzlicher “Public Contract” oft sinnvoll.
Was ist ein BFF (Backend for Frontend) und wann hilft das?
Ein BFF ist eine API-Schicht speziell für ein Frontend (oder eine App-Familie). Es hilft, wenn du interne Datenquellen bündeln willst, ohne deine Public API zu verbiegen. Typischer Move: Public REST, intern BFF via GraphQL oder tRPC.