Modernizing Legacy APIs into a Web Application Platform
We rebuilt access to a legacy API and proprietary data delivery model based on Windows and COM as a browser-accessible web application. Rather than replacing the existing service, we abstracted its legacy interface behind a typed adapter, domain model and REST API, enabling use from a modern React web application.
Design boundaries that make legacy assets reusable.
The Transformation
Contain legacy dependencies within a boundary instead of spreading them across the application.
↔ Scroll horizontally to see the full diagram.
View diagram as text
Windows runtime, COM objects, proprietary containers and the vendor API are handled at an integration boundary. The vendor API connects to the F# adapter, domain model, REST API and React application. The adapter retains the Windows/COM integration responsibility; browser clients do not inherit it. This is a conceptual responsibility and integration view.
Background
Valuable data, locked behind an old interface.
The external data service offered extensive data and capabilities accumulated over many years, but access depended on Windows COM objects and proprietary data formats.
- Dependency on a specific operating system
- COM-specific interfaces
- Proprietary data containers
- Difficult browser access
- Tight coupling between application code and the vendor API
- Poor fit with modern web and API development
- Vendor-specific knowledge required of consumers
The customer wanted to make these capabilities accessible through a browser-based application.
Modernization Strategy
Create a new boundary around a system that cannot be rewritten.
We could not rewrite the external legacy system itself. Instead, we introduced an abstraction / anti-corruption layer between the vendor-specific interface and the new application.
↔ Scroll horizontally to see the full diagram.
View diagram as text
An integration boundary containing a typed adapter, domain model and REST API separates the legacy system from modern applications.
Modernization does not always mean replacement. Sometimes the better solution is to contain a legacy dependency within a robust boundary.
Typed F# Adapter
From a vendor-specific API to a typed domain API.
The foundational F# adapter and REST modernization technology came from prior development by CoRISE’s technical advisor. CoRISE used this engineering asset to design, develop and integrate the customer-facing web application.
The adapter wrapped the legacy COM interface and exposed a more structured F# API. Its purposes were to:
- Isolate COM-specific calls
- Hide vendor-specific data representations
- Map external data into domain-oriented types
- Express valid states through the type system
- Separate application logic from legacy implementation details
↔ Scroll horizontally to see the full diagram.
View diagram as text
The F# adapter wraps the COM API and maps its data into a typed domain model.
Anti-Corruption Layer
Keep the legacy model from leaking throughout the application.
Without Boundary
↔ Scroll horizontally to see the full diagram.
- High coupling
- Vendor semantics spread through the application
- Difficult testing / replacement
- Difficult Web integration
View diagram as text
The frontend or application directly depends on COM, vendor types and proprietary data.
With Boundary
↔ Scroll horizontally to see the full diagram.
- Isolated dependency / clearer ownership
- Testable application layer
- Reusable API
- Easier future migration
View diagram as text
The vendor system connects through an adapter, domain model and application API to the frontend.
This boundary follows the anti-corruption layer concept in Domain-Driven Design.
REST API Modernization
Turn a local API into a service accessible over a network.
↔ Scroll horizontally to see the full diagram.
View diagram as text
The F# adapter and domain model translate the COM API into a REST interface consumed over HTTP and JSON.
The REST layer went beyond a mechanical COM-to-HTTP proxy. It introduced a stable application boundary with:
- Request models
- Response models
- Domain mapping
- Error handling
- API boundaries
- Separation of frontend concerns from legacy details
The goal was to make the system usable by modern clients without exposing the legacy implementation model.
Web Application
Turn legacy data into a product people can use in a browser.
CoRISE built a customer-facing React application using the modernized API. The frontend consumes the REST API as a conventional web client without needing to understand:
- COM
- Windows-specific calls
- Proprietary data container behavior
- Vendor-specific API structure
React is an implementation choice; the central change is architectural modernization.
Browser-based access
Independent frontend evolution
UI / UX flexibility
Easier integration
Additional future clients
Clear separation of responsibilities
Architecture Diagram
Legacy System → Boundary → Reusable Modern Capability.
↔ Scroll horizontally to see the full diagram.
View diagram as text
The external legacy data service exposes COM and proprietary data through a legacy boundary to the F# adapter, domain model and REST API. The React web app uses the API across the network boundary. Future clients are extension points, not delivered clients in this case. COM integration through the adapter still requires a Windows-side runtime.
Before / After
From desktop-bound integration to a reusable service.
Before
Windows-bound Integration
↔ Scroll horizontally to see the full diagram.
- COM dependency
- Proprietary data representation
- Desktop-oriented access
- Client code coupled to vendor API
- Difficult Web access
View diagram as text
Client code is tightly coupled to the vendor API and COM, without a browser access path.
After
Reusable Service Boundary
↔ Scroll horizontally to see the full diagram.
- Legacy dependency isolated
- Typed adapter / explicit domain model
- REST API boundary
- Browser-based application
- Reusable service interface / future-client extensibility
View diagram as text
The browser application reaches the isolated legacy dependency through a REST API boundary.
Attribution & Reuse
Connect prior engineering work to customer value.
CoRISE’s technical advisor developed the foundational F# wrapper and REST modernization technology as an independent technical project. CoRISE drew on this engineering asset and expertise to build the customer application.
Turn engineering knowledge accumulated by people and organizations into reusable technology that delivers customer value.
↔ Scroll horizontally to see the full diagram.
View diagram as text
The technical advisor’s independent engineering asset becomes a reusable capability applied in CoRISE’s customer project to deliver product value.
What This Case Demonstrates
What this case demonstrates.
- 01
Legacy API Modernization
Connect existing assets to a modern architecture while preserving their value.
- 02
Anti-Corruption Layer
Keep external system models and APIs from leaking throughout an application.
- 03
Typed Integration
Use types to transform a legacy interface into an accessible domain model.
- 04
API Modernization
Turn a local, desktop-oriented interface into a service API.
- 05
Product Engineering
Take integration through to a web application that people can actually use.
CoRISE Contribution
CoRISE’s contribution
Product Engineering
- Customer requirements
- Web application design
- React frontend development
- API integration
- User experience implementation
Architecture & Integration
- Use of the legacy adapter architecture
- Frontend / backend separation through REST
- Boundary design between the legacy interface and web application
- Connecting domain and application models
Technical Advisory
- Legacy COM integration expertise
- F# adapter expertise
- REST modernization knowledge
- Legacy API modernization architecture
The foundational adapter technology already existed. CoRISE brought it into the customer project and delivered the application and integration.
Technologies
- Type
- Legacy API Modernization
- Legacy Interface
- COM / Proprietary Data Container
- Adapter
- F#
- Domain Layer
- Typed Domain Model
- API
- REST / HTTP / JSON
- Frontend
- React / TypeScript
- Pattern
- Anti-Corruption Layer / Adapter
Outcome
Make legacy technology a reusable asset.
Instead of replacing a valuable existing data service, this work isolated its legacy interface inside an adapter. The architecture preserved the existing asset while making it usable by web applications, APIs and future applications.
We designed a durable boundary between old and new systems, preserving existing value while enabling new uses.