Full‑Stack TypeScript at dectria: React, NestJS, NX, and OpenAPI – Key Lessons from “We love our Techstack”

Context: A stack that matches the mission

In “We love our Techstack” by Marc Kornberger (dectria), one message is unmistakable: you should love your stack because it makes developers faster, more focused, and more effective. This is not a slogan here—it’s the result of deliberate choices. The talk walks from early curiosity about IT and initial projects with Angular/Express to today’s combination of React on the frontend, NestJS on the backend, NX for monorepo management, plus OpenAPI and an API‑first approach as the connective tissue across layers.

The products dectria builds are concrete: web applications and REST APIs that collect data, validate business rules, and present results—typically without computationally expensive workloads. The stack is designed specifically for this context, with TypeScript as the end‑to‑end language that binds frontend, backend, and shared libraries together.

That mindset—love your tools—runs through the entire session: pick the right tool for the job, rely on maintained ecosystems, iterate fast, and maximize reuse.

How the stack came together: use case, team, community

Marc frames the selection process around three pillars:

• Use case: web apps and REST APIs that capture data, validate business logic, and present it; occasional calculations that are not heavy.
• Team capabilities: full‑stack experience with JavaScript/TypeScript, some Java and C#, frontend experience with Angular and React.
• Community and maintenance: choose well‑maintained tools with strong communities and battle‑tested libraries.

The approach is pragmatic: don’t pick tools your team doesn’t know, don’t rely on unmaintained dependencies, and don’t optimize for novelty. Pick what yields speed and stability.

Frontend: React by default, Next.js when benefits outweigh overhead

On the frontend, dectria defaults to React—typically as a single‑page application. Next.js is used selectively for its additional features, but it’s not the default because it adds overhead when that extra functionality isn’t required.

• React: the standard choice for SPAs; Marc is “very happy with React,” especially from a frontend developer’s standpoint.
• Next.js: offers “nice features,” yet introduces overhead—applied where its benefits are justified.

This maps directly to the problem space: many business UIs with clear API integration and modest computational demands benefit from a lean React setup. When the advanced features of a framework pay off, Next.js comes in—otherwise the SPA stays streamlined.

Backend: NestJS for structured services

In the backend, dectria uses NestJS. The goal is a structured, well‑maintained foundation for REST services that fits neatly into a TypeScript ecosystem. That aligns with team skills and reduces mental overhead.

The workloads are deliberately scoped: not CPU‑intensive algorithms, but business logic, validation, and reliable data flows. For this, NestJS and its conventions—and its community—are a good fit.

TypeScript end to end: one stack, one language

As Marc puts it, TypeScript is “the elephant in the room”—and it’s used across the stack. Advantages include:

• Shared interfaces and types across frontend and backend.
• Fewer context switches, more consistent mental models, and clearer code.
• Reuse via libraries consumed by multiple parts of the system.

Combined with NX (more below), this reduces the friction for shared code to nearly zero: define a type once, leverage it everywhere. Fewer duplicates, less drift, less boilerplate.

Monorepo with NX: reuse, speed, order

The team organizes code in an NX monorepo. The effect: libraries emerge naturally from the code. As soon as something looks reusable or broadly useful, it’s extracted into a library and becomes available across apps.

Marc emphasizes the low barrier: “almost no boundary of entry.” The monorepo becomes a catalyst for standards and iteration:

• Unified build and test flows across frontend and backend.
• Shared TS configurations and lint rules.
• A home for utilities, validation logic, DTOs, and domain types.

The setup is intentionally lightweight. According to Marc, it takes “two commands” to bootstrap a monorepo, including prompts for the build/transpile tool and the testing framework. He doesn’t list commands; the important point is that scaffolding takes minutes and you can start building immediately.

API‑first with OpenAPI: a single source of truth

OpenAPI acts as the glue between frontend and backend. dectria defines interfaces API‑first, creating a single source of truth. The impact is clear:

• The API definition leads; implementation and consumption follow it.
• Typos and drift between frontend contracts and backend implementations are reduced.
• Types and structures can be derived centrally.

This discipline pays off in fast‑moving teams where features change frequently: API changes are explicit; downstream effects surface sooner.

Mobile when needed: React Native or Flutter, depending on requirements

When mobile comes up, the team uses React Native for some projects or switches to Flutter where requirements call for it. That’s not a contradiction to the TypeScript‑first posture, it’s a practical interpretation of “right tool for the job.” Still, the preference is unmistakable:

Open to alternatives, yet anchored in what keeps the team fast.

Decision principles: what stands out

From DevJobs.at’s editorial perspective, the talk distills a few strong principles:

1. Align your stack with the use case. If your apps manage data, validate rules, and present results, favor a lightweight, maintainable stack.
2. Build with your team, not against it. Know the skills you have and choose tools that map to them.
3. Pick communities, not just tools. Maintenance and battle‑tested libraries accelerate delivery.
4. Encapsulate knowledge in libraries. Validation, DTOs, domain types—if it’s reusable, extract it.
5. Use API‑first to reduce friction. A reliable OpenAPI spec is your defense against contract drift.
6. “Work smarter, not harder.” Scaffolding and monorepos aren’t vanity—they’re daily time savers.

A simple project flow—no frills required

The talk implies a straightforward project flow:

• Initialize an NX monorepo with a React SPA. Choose build/transpile and test setups during scaffolding.
• Implement a NestJS service for REST endpoints. Keep business rules and validation server‑side.
• Model types and interfaces in TypeScript once and share them as libraries across packages.
• Treat OpenAPI as the contract. Route changes through the API definition.
• As you build, extract utilities and validations into shared libraries—“almost instantly.”

The result isn’t flashy, which is precisely the point. The stack is optimized for what matters: speed, familiarity, reuse, and maintainability.

Lessons for teams with similar problem spaces

For teams with comparable needs, “We love our Techstack” surfaces several lessons:

• Avoid over‑engineering. Reach for Next.js when its features clearly solve current problems; otherwise keep a lean SPA.
• Decouple contracts from implementation. OpenAPI enforces precision and prevents frontend/backed from drifting apart.
• Invest early in monorepo structure. The sooner shared code appears, the fewer technical debts you accumulate.
• Keep language hygiene. A single TypeScript model across both sides reduces switching costs and clarifies communication.
• Keep maintenance front‑and‑center. The lifespan and stewardship of your dependencies are project risks—plan accordingly.

Common pitfalls—and how this stack counters them

The talk implicitly addresses common pitfalls:

• Fragmented stacks: when every project uses a different tool, cognitive load balloons. The dectria combo minimizes variation and keeps learning curves gentle.
• Contract drift: without API‑first, frontend and backend diverge. OpenAPI and shared types counter this.
• Optimizing for “future cool”: unmaintained tools are liabilities. A deliberate community check helps avoid dead ends.
• Role diffusion: letting frontend specialists stretch too thin reduces efficiency. Marc’s focus on frontend reflects the productivity of specialization.

Quotes that stick

• “You need the right tool for the job.” A simple rule that hardens architectures.
• “Work smarter, not harder.” Automation and good defaults are a culture, not an afterthought.
• “We don’t want to write all the code ourselves.” Battle‑tested libraries are a productivity engine, not a shortcut.

Where this stack shines

From the talk, suitability is clear:

• Business UIs with validation‑heavy input, clear workflows, and REST backends.
• Teams that are strong in TypeScript across frontend and backend.
• Organizations that value rapid iteration and maintainable interfaces.

It’s not aimed at compute‑intensive workloads—Marc explicitly describes modest computational needs. Different priorities would apply there.

The small evolution: from Angular/Express to React/NestJS

Marc’s path moves from early Angular and Express projects—already full‑stack JavaScript—toward React and NestJS at dectria. The takeaway isn’t the brands; it’s the willingness to evolve when something fits better.

Everyday productivity: what truly moves the needle

From our vantage point, four ingredients matter most day‑to‑day:

1. A stack the team knows. Fewer context switches, more flow.
2. Shared types and contracts. Rename a field once; everyone sees the change.
3. Monorepo ergonomics. New libraries emerge in minutes; reuse is the default.
4. Restraint with frameworks. Use Next.js when needed; otherwise keep the SPA lean.

Conclusion: A stack that works—so developers can work

“We love our Techstack” is a description of a curated toolbox, not a sales pitch. React, NestJS, NX, and OpenAPI—bound by end‑to‑end TypeScript—are combined at dectria to match a specific use case: web apps and REST APIs with clear business rules, fast iteration, and high reuse.

The recurring message: choose consciously, vet communities, keep contracts stable, extract shared code early, and trust a setup that accelerates rather than hinders. That’s why they love their tech stack—and why these principles are worth applying to your context.

Concrete takeaways to apply

• Default to full‑stack TypeScript when frontend and backend are tightly coupled and your team is strong in it.
• Use an NX monorepo to share libraries and types with minimal friction.
• Embrace API‑first with OpenAPI to minimize frontend‑backend friction.
• Choose React as the SPA default; bring in Next.js when its added features address real needs.
• Keep the focus on productivity—“work smarter, not harder.” Tooling should amplify speed and quality, not get in the way.

Ultimately, Marc’s core line sums it up: love your stack—because it makes you faster. At dectria, that’s daily practice.

• 

  

  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.

  Watch now