6 min read - Exceev Framework Stack: Architecture Decisions and Limits

A framework decision carries assumptions about the language, runtime and conventions the team will support as the codebase, requirements and ownership change.

The stack described here uses TypeScript across several layers, Angular and NestJS for application work, Next.js for this content site, and Jest and Playwright at different test layers. This article records the reasoning and the limits of that choice; it is not a performance claim about client projects.

The TypeScript Bet

The most consequential decision we made wasn't choosing a framework. It was choosing a language.

TypeScript runs everywhere in our stack. Frontend, backend, build scripts, infrastructure-as-code, test suites. That sounds rigid, and honestly, it is. But the rigidity pays for itself.

When a NestJS API and Angular client import a shared ProjectResponse, a breaking TypeScript change can surface in consumers included in the same type check. That catches some contract mismatches early. Runtime validation and integration tests remain necessary because TypeScript does not verify network payloads by itself.

The other thing that matters at a consultancy: people move between projects. Scopes shift, someone goes on leave, or a new engagement needs support. A shared language lets an Angular engineer read a NestJS pull request without first switching languages, while common linting and formatting conventions reduce avoidable setup differences. It does not make frontend and backend work interchangeable; runtime knowledge and project context still matter.

Is TypeScript the best language for every task? No. Different languages suit different runtimes, libraries and operating constraints. Most work described here concerns web applications, APIs and tooling. In that scope, sharing one language can reduce context switching, but it is not a universal argument against a polyglot stack.

Frontend-Backend Symmetry

Angular and NestJS weren't chosen independently. We picked them as a pair, because they think about code the same way.

The frameworks are not structurally identical, but they share useful concepts: dependency injection, decorators, services and explicit feature boundaries. Angular standalone components declare their own template dependencies, while NestJS modules organise providers and controllers. That shared vocabulary can make code reviews easier without erasing the differences between browser and server code.

That opinionation is useful when the team records its conventions. It reduces repeated folder-structure decisions and leaves more review time for data flow, failure handling and business rules.

Angular for Product Interfaces

FormAI, our AI-powered form builder, runs on Angular. So does SoarUI, our internal Angular design system. Angular is our default for anything with complex state, deep component trees, and a maintenance horizon measured in years.

Angular documents signals as a granular state-tracking mechanism, and recommends standalone components for new development. Those features reduce some framework ceremony, but they do not remove the need to choose state ownership, module boundaries or an upgrade process.

NestJS for APIs and Services

NestJS mirrors Angular on the server side. Controllers map to components. Services are injectable. Guards and interceptors handle cross-cutting concerns. If you know one, you can read the other.

The practical upside: code reviews get better. A frontend engineer reviewing a backend PR already understands the patterns. The shared vocabulary, modules, providers, guards, interceptors, means design conversations don't need a glossary.

NestJS documents HTTP applications, WebSocket gateways and several microservice transports. Sharing domain services across those entry points can be useful, but adding a transport still requires protocol design, failure handling, security and tests.

Where Next.js Fits

Yes, we run two frontend frameworks. People ask about this.

Our split is simple: Next.js handles this content site, while Angular handles the interactive products described here. Next.js provides file-based routes and metadata APIs that fit the blog and marketing pages. That is a team convention, not a general rule about which framework every organisation should use.

FormAI, SoarUI, client dashboards, those are Angular. Complex state, deep interaction, component reuse. Different problem, different tool.

The two frameworks still create a maintenance cost, so we keep their roles explicit and review exceptions instead of pretending the overlap is zero.

How We Test

Two tools, clear boundary between them.

Jest covers everything below the browser. Service logic, utility functions, API endpoints, database queries, component rendering in isolation. For Angular we pair it with Angular Testing Library; for NestJS, the NestJS testing module. Same assertion API, same mocking approach, same config. An engineer switching projects doesn't need to relearn the test suite.

Playwright covers selected browser journeys. Its documentation describes actionability checks and support for Chromium, Firefox and WebKit. Those features can reduce some timing work and broaden browser coverage; they do not guarantee a stable suite. Test isolation, data setup and application behaviour still determine reliability.

The rule is strict: Playwright tests user flows (authentication, data submission, multi-step workflows). Jest tests units and integration. We don't let them bleed into each other's territory. That boundary is what keeps both suites fast and maintainable.

Why This Matters More Than Any Single Choice

None of these tools are the objectively "best" option in their category. You can find benchmarks where another framework wins, blog posts arguing for a different testing tool, and valid reasons to pick a different language. We know. We've read them.

The value is not in any one tool. It comes from conventions that make code and ownership easier to find across projects. Shared validation, API clients and UI components can reduce duplication when their contracts truly match. We verify that benefit in review rather than assigning a universal onboarding or delivery time to the stack.

For Exceev, consistency is an architecture criterion alongside product fit, security and operability. The relevant question is not which framework wins in the abstract, but whether the set remains understandable and supportable for the work in front of us.

Primary sources

• Angular signals guide, reviewed 27 August 2026
• Angular standalone-component migration guide, reviewed 27 August 2026
• NestJS modules documentation, reviewed 27 August 2026
• NestJS WebSocket gateways, reviewed 27 August 2026
• Next.js metadata documentation, reviewed 27 August 2026
• Playwright browser support, reviewed 27 August 2026
• Playwright actionability checks, reviewed 27 August 2026

If you are evaluating your own stack, examine how the parts interact and who can operate them. A familiar framework is useful only when it also meets the product, runtime and maintenance constraints. If you want a second opinion on your stack, we're happy to talk.