Full‑Stack TypeScript bei dectria: React, NestJS, NX und OpenAPI – was wir aus „We love our Techstack“ mitnehmen

Kontext: Warum dieser Stack zur Mission passt

In „We love our Techstack“ von Marc Kornberger (dectria) bekommen wir eine klare Botschaft mit: Ein Tech‑Stack sollte geliebt werden – weil er Entwicklerinnen und Entwickler schneller, fokussierter und effizienter macht. Das klingt nach einem Motto, ist hier aber gelebte Praxis. Der Vortrag skizziert den Weg von einer Neugier für IT über frühe Projekte mit Angular/Express hin zur heutigen Kombination aus React auf der Frontend‑Seite, NestJS im Backend, NX als Monorepo‑Rückgrat sowie OpenAPI und einem API‑First‑Ansatz als verbindendem Gewebe zwischen den Schichten.

Was dectria baut, ist dabei sehr konkret: webbasierte Anwendungen und REST‑APIs, die Daten erfassen, Regeln prüfen und in typischen Fällen keine hochgradig rechenintensiven Operationen benötigen. Genau dafür ist dieser Stack konstruiert – mit TypeScript als durchgängiger Sprache, die Frontend und Backend, aber auch Libraries in einem Monorepo zusammenbindet.

Dieses „Love your tools“ zieht sich durch den ganzen Talk: Das richtige Werkzeug für den Job, gut gepflegte Ökosysteme, schnelle Iteration und die Möglichkeit, Code wiederzuverwenden – all das sind Leitplanken, die den Stack begründen.

Der Weg zum Stack: Use Case, Team, Community

Marc stellt den Auswahlprozess nüchtern auf drei Beine:

• Use Case: Web‑Apps und REST‑APIs, Daten erfassen, validieren, präsentieren; punktuell Businesslogik und leichte Berechnungen.
• Teamfähigkeiten: Voll‑Stack‑Erfahrung mit JavaScript/TypeScript, etwas Java und C#, Frontend‑Know‑how in Angular und React.
• Community & Wartbarkeit: Werkzeuge müssen aktiv gepflegt sein; starke Community, battle‑getestete Libraries und verlässliche Weiterentwicklung sind Pflicht.

Die Leitlinien sind bewusst pragmatisch: Kein Tool, das das Team nicht kennt. Keine Abhängigkeit, die morgen „abgekündigt“ ist. Keine Nostalgie – sondern ein Stack, der Geschwindigkeit und Stabilität gleichermaßen liefert.

Frontend: React als Standard, Next.js situativ

Auf der Frontend‑Seite setzt dectria auf React – in der Regel als Single‑Page‑Application. Next.js kommt dann ins Spiel, wenn die zusätzlichen Features den Mehrwert liefern, der die Mehrarbeit rechtfertigt. Wichtig: Es geht nicht um Tool‑Fetisch, sondern um den „fit for purpose“.

• React: Die Standardwahl für SPAs. Marc ist „sehr happy mit React“, gerade aus Frontend‑Sicht.
• Next.js: „Nice features“, aber „Overhead“ – also bewusst nicht default, sondern gezielt eingesetzt.

Diese Differenzierung passt zum Use‑Case: Viele Business‑UIs mit klarer API‑Anbindung, überschaubaren Berechnungen und hoher Iterationsgeschwindigkeit profitieren von einem schlanken React‑Setup. Wenn Framework‑Mehrwerte (z. B. in Richtung Rendering‑Strategien) überwiegen, wird Next.js gezogen – sonst nicht.

Backend: NestJS als strukturierte Service‑Basis

Im Backend vertraut dectria auf NestJS. Der Grundtenor: Eine strukturierte, gut gewartete Basis für REST‑Services, die wunderbar in TypeScript‑Ökosysteme passt. Das spielt die Stärken des Teams aus und hält die mentale Last gering.

Wichtig ist dabei die explizite Abgrenzung: Der typische Workload sind nicht CPU‑schwere Algorithmen, sondern solide Businesslogik, Validierung und verlässliche Datenflüsse. Dafür ist NestJS mit seinen klaren Konventionen und seiner Community ein passender Baustein.

TypeScript durchgehend: Ein Stack, eine Sprache

Der „Elefant im Raum“, wie Marc es nennt, ist TypeScript – und zwar end‑to‑end. Der Vorteil liegt auf der Hand:

• Gemeinsame Interfaces und Typen zwischen Frontend und Backend.
• Geringere Kontextwechsel, einheitliche Denkmuster, bessere Lesbarkeit.
• Code‑Wiederverwendung über Bibliotheken, die in mehreren Teilprojekten genutzt werden können.

Die Kombination aus TypeScript und NX (siehe unten) senkt die Einstiegshürden für Shared Code praktisch auf null: Ein gemeinsamer Typ wird einmal definiert und steht in allen relevanten Paketen bereit. Weniger Duplikate, weniger Drift, weniger Boilerplate.

Monorepo mit NX: Reuse, Geschwindigkeit, Ordnung

dectria nutzt ein NX‑Monorepo als zentrales Organisationsmuster. Der Effekt: Bibliotheken entstehen aus dem Code heraus – sobald etwas austauschbar oder potenziell wiederverwendbar wirkt, wird es als Library extrahiert und steht sofort in mehreren Apps zur Verfügung.

Marc betont den geringen Aufwand: „fast keine Eintrittsbarriere“. Das Monorepo wird so zum Katalysator für einheitliche Standards und schnelle Iteration:

• Einheitlicher Build‑ und Test‑Pfad für Frontend und Backend.
• Gemeinsame TS‑Konfigurationen und Linting‑Regeln.
• Ein Ort für Utilities, Validierungen, DTOs und Domänenobjekte.

Der Setup‑Prozess ist dabei bewusst schlank: Laut Marc reichen „zwei Commands“, um ein initiales Monorepo aufzusetzen, inklusive Auswahl eines Build‑/Transpile‑Tools und des Testframeworks. Konkrete Befehle nennt er nicht – wichtig ist die Beobachtung: Der „Scaffold“ kostet kaum Zeit und führt sofort in produktive Arbeit.

API‑First mit OpenAPI: Eine Quelle der Wahrheit

Zwischen Frontend und Backend fungiert OpenAPI als „Klebstoff“. dectria definiert Schnittstellen API‑First und schafft so eine Single Source of Truth. Das Ergebnis ist konsistent:

• Die API‑Definition führt das Gespräch – Implementierung und Nutzung folgen ihr.
• Tippfehler und Drift zwischen Frontend‑Contracts und Backend‑Implementierung werden vermieden.
• Typen und Strukturen können zentral abgeleitet werden.

Diese Disziplin zahlt sich gerade in Teams aus, die schnell iterieren und Features häufig anpassen: API‑Änderungen sind explizit; Auswirkungen werden früher sichtbar.

Mobile, wenn nötig: React Native oder Flutter – je nach Anforderung

Auch das gehört zur Ehrlichkeit dieses Stacks: Für mobile Projekte setzt das Team je nach Bedarf auf React Native oder, bei spezifischen Anforderungen, auf Flutter. Das ist kein Widerspruch zur TypeScript‑Linie, sondern Ausdruck des „Right tool for the job“. Gleichzeitig ist klar, wo das Herz schlägt:

Die Botschaft: Offen für Alternativen, aber mit einer klaren Präferenz, die Produktivität bringt.

Entscheidungsprinzipien: Was wir mitnehmen

Der Talk kondensiert einige simple – und gerade deshalb starke – Prinzipien, die wir als Redaktion von DevJobs.at so zusammenfassen:

1. Richte deinen Stack am Use Case aus. Wenn deine Anwendungen Daten verwalten, Regeln prüfen und darstellen, brauchst du einen schlanken, gut wartbaren Stack – kein Komplexitätsmonster.
2. Entwickle mit dem Team – nicht gegen es. Kenne die Skills, rekrutiere passend, und entscheide für Werkzeuge, in denen die Crew effizient ist.
3. Wähle Tools mit Community‑Rückenwind. Gute Wartung, breite Nutzung, battle‑getestete Libraries sind dein Beschleuniger.
4. Kapsle Wissen in Libraries. Erkenntnisse, Validierungen, Typen, DTOs – was wiederverwendbar ist, gehört in Bibliotheken.
5. API‑First minimiert Reibung. Eine verlässliche OpenAPI‑Definition ist der beste Schutz gegen Contract‑Drift.
6. „Work smarter, not harder.“ Automatisierung, Scaffolding und ein Monorepo sparen Zeit – jeden Tag.

Ein exemplarischer Projektfluss – ohne Schnörkel

Aus dem Gesagten ergibt sich ein klarer Projektfluss, den wir so beobachten:

• Start mit einem NX‑Monorepo und einer React‑App als SPA. Die Wahl des Build‑ und Test‑Setups erfolgt direkt beim Scaffold.
• Ein NestJS‑Service setzt die REST‑API um. Domänenlogik und Validierungen liegen serverseitig dort, wo sie hingehören.
• Typen und Schnittstellen werden in TypeScript gemeinsam modelliert und als Libraries im Monorepo geteilt.
• Eine OpenAPI‑Definition dient als vertragliche Basis zwischen Frontend und Backend; Änderungen laufen darüber.
• Im Laufe der Implementierung werden Utilities (z. B. Formatierungen, Validierungen) als Libraries extrahiert – „fast instant“.

Das Resultat ist nicht spektakulär – und gerade das ist der Punkt. Dieser Stack ist auf das Wesentliche optimiert: schnell, vertraut, wiederverwendbar, wartbar.

Lektionen für Teams mit ähnlichem Problemraum

Für Engineering‑Teams, die mit vergleichbaren Anforderungen arbeiten, lassen sich aus „We love our Techstack“ folgende Lehren ziehen:

• Vermeide Über‑Engineering. Wähle Next.js nur dort, wo seine Extras tatsächlich gebraucht werden; sonst bleib bei einer direkten React‑SPA.
• Entkopple Verträge von Implementierung. OpenAPI zwingt zu Präzision und verhindert, dass Frontend und Backend aneinander vorbeientwickeln.
• Investiere früh in Monorepo‑Strukturen. Je früher Shared Code entsteht, desto weniger technische Schulden sammeln sich an.
• Bewahre Sprachenhygiene. Ein durchgehendes TypeScript‑Modell schafft Klarheit, reduziert Wechselkosten und macht Kommunikation leichter.
• Behalte Wartbarkeit im Blick. Die Lebensdauer deiner Abhängigkeiten ist ein Projekt‑Risikofaktor – plane sie ein.

Häufige Stolpersteine – und wie dieser Stack dagegenhält

Aus der Praxis, wie Marc sie schildert, ergeben sich typische Fallstricke, die hier adressiert werden:

• Stack‑Zerfaserung: Wenn jedes Projekt andere Tools nutzt, explodiert der mentale Overhead. Die dectria‑Kombination minimiert Variation und hält die Lernkurve flach.
• Contract‑Drift: Ohne API‑First wandern Frontend und Backend auseinander. OpenAPI und gemeinsame Typen verhindern das.
• „In die Zukunft optimieren“: Tools ohne aktive Pflege sind Risiko. Die strukturierte Community‑Prüfung schützt davor.
• Fehlender Fokus im Team: Frontend‑Spezialisten sollten vorrangig Frontend bauen, um Effizienz zu maximieren – Marcs Rollenwahl spiegelt das wider.

Zitate, die hängen bleiben

• „You need the right tool for the job.“ – Eine simple Regel, die viele Architekturen robuster macht.
• „Work smarter, not harder.“ – Automatisierung und sinnvolle Defaults sind Kultur, nicht Add‑on.
• „We don’t want to write all the code ourselves.“ – Battle‑getestete Libraries sind kein Luxus, sondern ein Produktivitätsmotor.

Wann dieser Stack besonders gut passt

Auf Basis des Talks ist die Eignung klar umrissen:

• Business‑UIs mit validierungsintensiver Eingabe, klaren Workflows und REST‑Backends.
• Teams mit TypeScript‑Kompetenz im Frontend und Backend.
• Organisationen, die Wert auf schnelle Iteration und wartbare Schnittstellen legen.

Nicht im Fokus sind Szenarien mit extrem rechenintensiven Jobs – hier wären andere Prioritäten (z. B. spezialisierte Runtimes oder Services) ausschlaggebend. Marc grenzt das klar ab.

Die kleine Evolutionsgeschichte: Von Angular/Express zu React/NestJS

Spannend ist der Weg: Erste eigene Projekte baute Marc mit Angular und Express – also bereits JavaScript/Node im Voll‑Stack. Bei dectria erfolgte der Wechsel zu React und NestJS, mit dem Ergebnis eines heute sehr runden Setups. Neben der Toolchain zeigt das auch eine Haltung: Technologie ist Mittel zum Zweck; wenn etwas besser passt, wird gewechselt.

Produktivität im Alltag: Was den Ausschlag gibt

Aus Redaktionssicht sind es vier Dinge, die im Alltag den Unterschied machen:

1. Ein Stack, den das Team kennt. Weniger Kontextwechsel, weniger „Wie ging das noch mal?“, mehr Flow.
2. Geteilte Typen und Contracts. Ein API‑Feld wird einmal umbenannt – alle sehen die Änderung.
3. Monorepo‑Ergonomie. Neue Libraries entstehen in Minuten; Wiederverwendung ist Standard, nicht Sonderfall.
4. Maß halten bei Frameworks. Next.js wird dort eingesetzt, wo es Vorteile bringt – sonst bleibt die SPA schlank.

Fazit: Ein Stack, der arbeitet – damit Entwickler arbeiten können

„We love our Techstack“ ist kein Werbeslogan, sondern die Beschreibung eines bewusst kuratierten Werkzeugkastens. React, NestJS, NX und OpenAPI – getragen von durchgehendem TypeScript – sind bei dectria so kombiniert, dass sie den spezifischen Use Case optimal stützen: Web‑Apps und REST‑APIs mit klarer Businesslogik, schneller Iteration und hoher Wiederverwendung.

Die wiederkehrende Botschaft: Wähle bewusst, prüfe die Community, halte Verträge stabil, extrahiere Shared Code früh – und vertraue auf ein Setup, das dich arbeiten lässt, statt dich auszubremsen. Genau deshalb lieben sie ihren Tech‑Stack – und genau deshalb lohnt es sich, diese Prinzipien auf den eigenen Kontext zu übertragen.

Konkrete Takeaways zum Mitnehmen

• Setze auf Full‑Stack TypeScript, wenn Frontend und Backend eng verzahnt sind und dein Team darin stark ist.
• Nutze ein NX‑Monorepo, um Libraries und Typen geringfügig reibungsarm zu teilen.
• Halte dich an API‑First und OpenAPI, um Frontend‑Backend‑Reibung zu minimieren.
• Wähle React als SPA‑Standard; greife zu Next.js, wenn die zusätzlichen Features den tatsächlichen Bedarf adressieren.
• Halte den Fokus auf Produktivität („work smarter, not harder“) – Tooling soll Tempo und Qualität verstärken, nicht behindern.

Am Ende bleibt Marcs Kernsatz die beste Zusammenfassung: Liebe deinen Tech‑Stack – weil er dich schneller macht. Bei dectria ist das kein Lippenbekenntnis, sondern Alltag.

• 

  

  Michael Jauk, Co-Founder von dectria

  Michael Jauk von dectria beschreibt im Interview die Organisation des jungen Unternehmens, die technologisch interessanten Aspekte sowie die Gestaltung von Recruiting und Onboarding.

  Jetzt ansehen