angular engineering at findev
Angular at Findev is not a typical web frontend job. The interfaces we build process thousands of real-time messages, display financial data that must be accurate at every update, and handle actions where a single submission can represent a significant trade. The engineering requirement follows from that: correctness is not a quality bar, it is a functional requirement. Data that arrives late, renders incorrectly, or drops under load is not a UX problem. In a financial context, it is an operational one.
A trading interface can be functionally correct and still fail its users through poor performance. In one Findev project, traders use a global platform to trade and consume real-time data about hundreds of financial products simultaneously.
There is another important part of this work: a single click or form submission may represent a very large trade. In that context, a click is no longer just an interface event. It is a step in a significant financial transaction. UI correctness, predictable behaviour, and test coverage matter because a small frontend defect may affect the transaction itself.
This places the browser inside the system's performance and correctness envelope. Every stream subscription, state update, validation rule, change-detection pass, and DOM operation contributes to the experience of the trader. A component that works well with one instrument may behave differently when the same update path is repeated hundreds of times.
At Findev, we shape each Angular project around the product, the team, and the way it is delivered. There is no fixed rule. Engineers decide what fits the project best, and that decision may change as the system and team evolve. Some projects use a monorepo, while others keep applications and libraries in separate repositories.
For a focused application, the Angular CLI may provide everything the team needs. Angular's modern build system uses esbuild for compilation and bundling while its development server uses Vite. These tools are already part of the current Angular toolchain.
A larger workspace containing multiple applications and shared libraries may benefit from Nx. Its project graph, module boundaries, task caching, and affected-project detection help when a shared change must be validated against several applications without rebuilding unrelated parts of the workspace.
Separate repositories can work better when applications have independent teams and delivery cycles. The structure may also change later if the original boundaries no longer match how the software is developed.
The current trading-platform stack includes Angular 20+, TypeScript, RxJS, and JavaScript.
RxJS helps us express asynchronous flows, but using observables is the easy part. Engineers still need to understand subscription lifetimes, emission frequency, scheduling, error handling, and the amount of rendering triggered downstream. Diagnosing a performance problem may require following an update through the reactive pipeline, Angular change detection, and the browser rendering process.
That is why we care about JavaScript beyond framework APIs. Investigating a production issue may require understanding computational complexity, memory allocation, V8, or the browser event loop. Angular expertise without JavaScript expertise leaves too many performance problems unexplained.
Unit testing, test-driven development, and code review remain part of working in a large Angular codebase. Unit tests verify components and isolated behaviour. End-to-end tests verify that the complete workflow still works in a real browser.
We use Playwright to test important user journeys across the application. For a trading interface, this means more than checking whether a button is visible. A test can cover the full sequence from entering data and submitting a form to receiving the result and displaying the final state. Playwright traces help investigate failures through DOM snapshots, network requests, console output, and screenshots captured during the test.
Playwright's MCP server gives AI agents direct browser control, and its CLI is built for use with tools such as Copilot and Claude Code. This can reduce the mechanical work of creating and maintaining tests, but generated code still requires engineering review. An AI tool can propose a test; the engineer remains responsible for deciding whether it proves the right financial behaviour.
The UI is not an isolated layer. Some work extends into Node.js microservices built with NestJS or Express and supported by MongoDB or Redis.
Angular provides structure, but it does not provide performance or correctness for free. Nx can make a large workspace easier to manage, but it adds concepts and configuration. End-to-end tests take longer than unit tests, while covering the browser-level workflows that unit tests cannot.
The tools earn their place when they reduce a real engineering risk. The common requirement is that engineers understand the framework, the runtime beneath it, and the financial significance of the actions presented through the interface.