Building a TypeScript-First Frontend SDK for Capital Markets

In my most recent engagement I led the architecture and delivery of a production frontend SDK for global capital markets applications – running on both browser and integrated desktop platforms, supporting delivery teams across London, New York, and Miami. The SDK itself took around a year to design and build from the ground up. In the period that followed, multiple projects across several teams were delivered on top of it. This post covers the architectural approach, the decisions behind it, and what distinguishes it from a conventional component library.

Why a Component Library Is Not Enough

The typical answer to “we need UI consistency across teams” is a component library: styled buttons, inputs, and data grids published as a package. That solves roughly 20% of the actual problem. What it does not address is where state lives, how view logic is tested independently of rendering, how a blotter in React and a blotter in Angular share identical behaviour, how complex form validation chains work across dependent fields, or how any of this is governed across a codebase that will run in production for five or more years with evolving teams.

We built something with a different foundation: a TypeScript-first, framework-agnostic SDK where React and Angular are treated as equal native rendering targets – not one ported to the other. The framework choice for the view layer is a deployment concern, not an architectural one.

The Biggest Pillar: MVVM and Dependency Injection

The most important architectural decision in the entire SDK is the combination of MVVM and a first-class IoC dependency injection system. Everything else – the blotter API, the forms engine, the shell, the persistence service – builds on top of this foundation. Getting this right is what makes SOLID design principles apply naturally rather than being enforced through convention or code review discipline.

The MVVM pattern enforces a hard separation between three things that most front-end codebases blend together: the view (a React component or Angular template), the ViewModel (a pure TypeScript class containing all business logic and state), and the model (data and services). The view is as thin as possible – it is just a template that binds to the ViewModel’s exposed properties and commands. It contains no business logic, no conditional branching, no data transformation. All of that lives in the ViewModel.

This matters for several reasons. First, testability: because a ViewModel is a plain TypeScript class with no JSX, no Angular decorators, and no rendering framework knowledge, it can be instantiated and tested in isolation with zero UI involvement. Business logic that would otherwise require mounting components, simulating events, and asserting on DOM output is instead tested as straightforward unit tests against TypeScript classes. Second, reusability across stacks: the same ViewModel powers both the React and Angular implementations of a feature. The React developer writes a React template; the Angular developer writes an Angular template; both bind to the same ViewModel and get identical behaviour. The core business logic is written once, not twice. Third, long-term maintainability: the boundary between pure TypeScript and framework-specific code is explicit and enforced. New engineers know exactly where business logic lives and where rendering concerns live – there is no ambiguity about which side of the line a given piece of code belongs on.

The dependency injection system is built as a wrapper around Inversify, providing a first-class, high-performance, on-demand service resolution mechanism. Rather than relying on Angular’s built-in injector (which only works in Angular) or React context (which is not really DI at all), the SDK maintains its own IoC container that works identically in both stacks. Services are registered against interfaces, not concrete implementations – which is how the D in SOLID (Dependency Inversion) actually applies in practice rather than in theory. Angular gets a transparent DI bridge that maps the SDK container into Angular’s own injector, so Angular components consume services normally without knowing the underlying mechanism. React gets a hook-based integration layer that resolves ViewModel and service instances from the same container on demand.

The SDK also implements a service discovery pattern on top of Inversify – services can be resolved by capability rather than by concrete type, which means consuming code depends on abstractions and the container decides which implementation to provide at runtime. This makes the single responsibility principle and open/closed principle apply naturally: adding new behaviour means registering a new implementation, not modifying existing classes.

The net result is a codebase where the vast majority of logic is pure TypeScript – framework-agnostic, fully testable, consistently structured across both stacks. React and Angular contribute only what they are actually good at: native component rendering and template binding. The hard parts belong to the SDK.

Monorepo Structure

The SDK lives in an Nx monorepo with a strict separation between layers. The top level contains four library packages and a set of reference applications:

• Core library – the framework-agnostic foundation: all MVVM abstractions, IoC container, services, streaming, state, theming, and UI component logic. No dependency on React or Angular.
• React library – thin React integration layer. Hooks that connect the view to ViewModels, React-native component wrappers, Redux integration, and React-specific layout implementations.
• Angular library – thin Angular integration layer. Directives that connect the view to ViewModels, Angular-native component wrappers, Angular module structure, and DI bridge to the core container.
• CLI – project scaffolding tool that generates new applications preconfigured with the full SDK, authentication, theming, dock layout, CI/CD pipelines, ArgoCD deployment templates, and AI assistant context.

Nx boundary rules enforce that only the React and Angular libraries may import from Core – consuming applications never reach into Core directly. This keeps the dependency graph clean and upgrades tractable.

Platform Architecture

The SDK is structured in three layers:

• Core SDK – the TypeScript foundation covering IoC/DI, MVVM, state management, messaging, configuration, logging, streaming, notifications, theming, testing utilities, base components, desktop interop, security, instrumentation, and APM integration via Datadog.
• Framework SDK layer – the Angular UI SDK (NG Zorro components, framework directives, DI adapters) and React UI SDK (Ant Design components, framework hooks, DI adapters), plus shared packages for application shell and data services.
• Application layer – individual products (trading blotters, risk monitors, order management, operational tools, and others) sitting on top of a unified application shell, deployable to browser or integrated desktop environments.

The platform targets Windows, macOS, Chrome, tablet, and integrated desktop interop – all from a single codebase.

What the SDK Provides

Scaffolding CLI with Full Deployment Pipeline

The scaffolding CLI does considerably more than generate a starter project. In a few commands it produces a fully working application ready to build and deploy, including:

• GitHub Actions workflows – pre-configured CI pipelines covering lint, test, build, and Docker image publishing, wired to branch conventions out of the box
• ArgoCD deployment manifests – Kubernetes deployment YAML templates pre-structured for standard client environments: dev, UAT, and production, with environment-specific configuration overlays already in place
• Docker configuration – production-ready Dockerfiles and compose files aligned to the organisation’s container standards
• Full SDK integration – authentication, theming (AntD for React, NG Zorro for Angular), dock layout, widget architecture, and AI assistant context all wired up before the first line of business code is written

The result is that a new project goes from a CLI command to a deployable, environment-aware application in minutes rather than days. Infrastructure decisions that would typically consume the first sprint of any new project are already made and encoded in the generated output. Teams start from working, not from blank.

Observability: Logging, Instrumentation, and Datadog APM

Observability is a first-class SDK concern, not something left to each application team to figure out independently. The SDK ships a structured logging service, a client-side instrumentation layer for tracking user interactions and application events, and a built-in integration with Datadog APM. Every generated project comes with Datadog configured out of the box – real user monitoring, error tracking, and performance traces are available from day one without any per-application setup. Support teams get consistent, queryable telemetry across all applications in the portfolio rather than fragmented logging from teams who each chose a different approach.

Config-Driven Shell and Dock Layout

The application shell is entirely config-driven. Navigation, panels, workspace layouts, and module registration are declared in configuration rather than code. The dock layout system wraps a proven open-source dock library, exposing a component API that handles panel creation, tear-off, resize, and state persistence. On integrated desktop platforms, the same configuration drives the interop layer – window management, application channels, and cross-application registration – without the consuming application needing platform-specific code.

Persistent State Service

Any component or screen can register with the persistence service. Column widths, panel positions, filter state, sort order, and active tabs are all serialised and restored on page load. A user who refreshes their browser returns to exactly the state they left, including their dock layout arrangement. This is a cross-cutting platform service, not something individual teams implement per application.

Blotter API

The blotter module wraps a high-performance data grid library, exposing both client-side and server-side row model implementations through a consistent SDK API. Teams configure a blotter via a metadata endpoint – column definitions, grouping, sorting, filtering, row actions – and the SDK handles grid wiring, streaming row updates via RxJS observables, server-side query specification, and toolbar integration. A team building a new blotter writes configuration and a ViewModel, not grid framework boilerplate.

Forms API with Rule Engine

The forms module provides a rich field API with client-side and server-side validation, RxJS-based dependency tracking between fields, and a rule engine that triggers visibility, validation, and value changes in response to field state changes. A field change can cascade through a declared dependency graph – disabling fields, firing async validation, populating dependent lookups – all configured rather than manually wired in component code. Backend validation rules integrate into the same pipeline so client and server errors surface consistently.

Theming: Ant Design with Dark Mode Foundation

The theme system is built on Ant Design (React) and NG Zorro (Angular) with dark mode as the primary target, appropriate for trading floor environments. Design tokens cover semantic colour for financial data (positive/negative P&L, alert states, neutral hierarchies), flex-based layout primitives, typography, and component-level overrides. Tokens are exposed as CSS custom properties and typed constants, applied globally through the SDK theme service – individual components never hardcode visual values.

Charts, Maps, and Notifications

Charts wrap a commercial charting library with config-driven components and streaming data support. Maps wrap an open-source mapping library with config-driven components for geographic data use cases common in commodities and energy domains. The notification API integrates with the desktop interop layer so in-app notifications can be promoted to OS-level desktop notifications and cross-application broadcasts.

Built-in Support Mode and Impersonation

The SDK includes a built-in impersonation service for support and operations teams. An authorised support engineer can assume a user’s identity and view the application in read-only mode that exactly reflects what that user sees – layout, data permissions, and persistent state. This is wired into the security layer and surfaced through the shell UI without any per-application implementation work.

AI-Native Development

One of the more distinctive aspects of this SDK is that it is explicitly designed for AI-assisted development, not just human developers. Every package ships with a structured context file, and the monorepo uses a hierarchical routing system so that an AI coding agent working on a specific task reads only the relevant context – not the entire codebase at once.

The routing is task-specific: an agent working on the data grid reads the blotter context; an agent working on forms reads the forms context; an agent working on theming reads the theme context. Each context file covers architecture patterns, naming conventions, state management approach, styling guidelines, and the service locator pattern – everything the agent needs to generate code that conforms to SDK standards without human supervision of every detail.

The SDK ships agent workflow configurations for Claude, Cursor, and Roo – pre-configured with mandatory reading rules and task-specific routing. Projects generated by the CLI receive these configurations automatically, so every new project is AI-ready from day one. Developers are required to update context files whenever they add or modify features – the AI context is treated as a first-class deliverable and validated in CI alongside code changes. The result is governed AI-assisted development: agents operate within SDK standards by default, producing code that a senior engineer reviewing it would find indistinguishable from hand-crafted output.

Governance

Keeping standards intact as teams grow and rotate is the hardest long-term challenge. The SDK enforces governance through several mechanisms:

• Nx module boundary enforcement – packages import only from declared dependencies; cross-layer imports and circular dependencies are rejected at build time
• Semantic versioning with deprecation windows – no API or component is removed without prior deprecation warnings across at least two minor versions
• AI context files as a living contract – CI validates that context files are updated alongside code changes
• Storybook per library – every component has stories; visual regression is part of the pipeline
• Platform-level support infrastructure – impersonation, Datadog APM, structured logging, instrumentation, and a support wiki are first-class SDK features, not per-project afterthoughts

Outcome: Months to Weeks

The headline result is straightforward: applications that previously took months to deliver are now delivered in weeks, with consistent look and feel, consistent behaviour, and a codebase that a new engineer can orient to quickly because the patterns are identical across every project in the portfolio.

The SDK absorbs all the platform complexity – grid integration, RxJS streaming, IoC container setup, desktop interop, theme inheritance, dock layout persistence, form validation chains, Datadog APM, and the entire path from build to production deployment – so that consumer applications contain the minimum possible code. A new application is largely configuration and business-specific ViewModel logic. The hard problems are already solved.

That is the measure of a good platform: the teams building on top of it should rarely have to think about it.