Ein Frontend-Team hat eine typsichere API-Mocking-Schicht eingeführt, die nur in der Entwicklung existiert. Durch den Einsatz von Axios-Interceptoren und Vite's Tree-Shaking bleibt das Produktions-Bundle unberührt. Entwickler rufen Daten mit ihren üblichen Mustern ab, während sie auf Backend-Endpunkte warten, und schalten dann einfach ein einzelnes Environment-Flag um, um die echte API aufzurufen.

Warum das Team einen besseren Weg zum Mocking brauchte

Frontend-Entwickler stoßen auf Hindernisse, wenn eine Backend-Route noch nicht fertiggestellt ist. Die schnelle Lösung – das Hardcoden einer Antwort innerhalb einer Komponente oder das Verstreuen von if (process.env.NODE_ENV === 'development')-Blöcken im gesamten UI – hält die App zwar in Bewegung, hinterlässt aber technische Schulden. Diese Mock-Objekte werden Teil der Logik der Komponente, erhöhen das Risiko, Fake-Daten in die Produktion zu bringen, und machen den Code schwerer lesbar und testbar.

Das Team wollte jeden Mock aus dem Komponentenbaum auslagern, einen Vertrag (Contract) zwischen Front- und Backend erzwingen und garantieren, dass nichts Zusätzliches im Produktions-Build landet.

Der dreistufige Prozess, dem das Team folgt

  1. Contract Meeting – Frontend- und Backend-Entwickler setzen sich zusammen und listen jede Anfrage, ihre URL, Methode und den erwarteten Payload auf.
  2. Typisierter Vertrag – Sie wandeln die Liste in ein TypeScript-Interface um, das als Single Source of Truth für die Struktur von Requests und Responses dient.
  3. Interceptor-Anbindung – Ein Axios-Interceptor untersucht jede ausgehende Anfrage. Wenn die URL mit einem registrierten Mock übereinstimmt, gibt der Interceptor die Mock-Daten zurück; andernfalls wird die Anfrage an den Live-Server weitergeleitet.

Da der Interceptor die einzige Stelle ist, an der die Mock-Logik lebt, bleibt der Komponenten-Code unverändert. Entwickler nutzen weiterhin ihre normalen Data-Fetching-Hooks – wie etwa useQuery – ohne zusätzliche bedingte Logik hinzuzufügen.

So wird ein Aufblähen der Produktion vermieden

Das Team hat drei Schutzmechanismen implementiert, die es Rollup (dem von Vite verwendeten Bundler) ermöglichen, den Mock-Code beim Erstellen des Produktions-Builds vollständig zu entfernen:

  • import.meta.env.DEV wird in einem Produktions-Build zu false aufgelöst, sodass das gesamte Interceptor-Modul während des Tree-Shaking verschwindet.
  • Die Variable MODE wird auf etwas anderes als test gesetzt, wenn Unit-Tests ausgeführt werden, wodurch testspezifischer Code getrennt bleibt.
  • Ein benutzerdefiniertes Flag, VITE_ENABLE_MSW, ist standardmäßig auf false gesetzt und muss zur Aktivierung der Mocks explizit eingeschaltet werden.

Wenn alle drei Bedingungen false sind, gelangt das Mock-Registry niemals in das finale Bundle.

Organisation der Mock-Dateien

Das Repository folgt einem feature-zentrierten Layout:

  • interfaces/ – Enthält die TypeScript-Definitionen, die aus dem Contract Meeting generiert wurden.
  • scenarios.ts – Enthält konkrete Beispiele für erfolgreiche Antworten und Fehlerfälle für jeden Endpunkt.
  • devHandlers.ts – Fungiert als zentrale Registry, die URLs auf die Szenario-Daten abbildet und den Interceptor in Axios einbindet.

Ein kleines Scaffolding-Skript kann diese Dateien automatisch generieren: Man gibt ihm eine URL und das passende Interface, und es erstellt die Stub-Dateien und registriert den Mock. Das Skript liegt außerhalb des Produktions-Code-Pfads, sodass es die Bundle-Größe nicht beeinflusst.

Was das Team gewonnen hat

  • Keine Mocks innerhalb von Komponenten – Alle Fake-Daten leben in einer dedizierten Schicht, wodurch der UI-Code sauber bleibt.
  • End-to-End-Typsicherheit – Mock-Daten entsprechen denselben TypeScript-Interfaces, die auch für echte Antworten verwendet werden, sodass Unstimmigkeiten zur Kompilierzeit erkannt werden.
  • Kein zusätzliches Gewicht in der Produktion – Tree-Shaking entfernt den Interceptor und die Mock-Daten vollständig, sodass die Bundle-Größe unverändert bleibt.
  • Gemeinsame Szenarien für Entwicklung und Tests – Dieselben Mock-Definitionen steuern sowohl die lokale Entwicklung als auch automatisierte Tests, was Duplikate reduziert.

Kompromisse und Grenzen

Der Ansatz ersetzt kein echtes Backend. Wenn der Mock-Vertrag von der Live-API abweicht, bemerken Entwickler die Unstimmigkeit erst, nachdem sie das Environment-Flag umgeschaltet haben.

Was als Nächstes zu beachten ist

  • Tooling-Integration –
  • Breitere Akzeptanz –
  • Performance-Monitoring –

Das Fazit ist klar: Durch das Auslagern der Mock-Logik in eine typisierte, umgebungskontrollierte Schicht können Frontend-Teams ihre Komponenten sauber halten, typsicher bleiben und Produktions-Builds ohne versteckte Mock-Payloads ausliefern. Die Aufrechterhaltung eines gemeinsamen Vertrags ist der Preis für einen reibungsloseren Entwicklungsablauf und eine sauberere Codebasis.