Architectural and Design Review
This section contains an independent architectural and design review of
the DTaaS codebase, performed against the feature/distributed-demo
branch (commit e7f9dd6, July 2026). The findings describe the
codebase at that commit.
Scope and Method
The review covers the five deliverable packages of the monorepo and the deployment scenarios that bind them together:
| Package | Path | Technology |
|---|---|---|
| React client | client/ |
React 19, Redux Toolkit, oidc-client-ts |
| Library microservice | servers/lib/ |
NestJS, GraphQL (Apollo), cloudcmd |
| DT Runner | servers/execution/runner/ |
NestJS, REST, execa |
| DTaaS CLI | cli/ |
Python, click, python-on-whales |
| Services manager | deploy/services/cli/ |
Python, click (dtaas-services) |
| Deployment scenarios | deploy/dtaas/docker/, deploy/vagrant/ |
Traefik, docker compose |
The review followed a standard system design review framework: requirements traceability, recovery of the high-level architecture from code and deployment artifacts, deep dives into each component, and an analysis of scale, reliability and security across components. Each finding was checked against the source files, and each claim in these documents cites the file it was observed in.
Documents
- Architecture Review: the architecture as implemented, recovered from code and compose files, with data flows and trade-off analysis.
- Design Review: component-level review of the client, microservices, CLIs and deployment tooling.
- Systemic Issues: issues that recur across components and releases, with evidence.
- Improvement Proposals: prioritised, incremental recommendations with migration paths and explicit trade-offs.
Summary Verdict
DTaaS has a clear product vision, unusually good documentation for a research platform and substantial test investment in the client. The main architectural risks are concentrated in four areas:
- the gap between the documented and the implemented architecture;
- the delegation of core platform logic (DT lifecycle, execution, state) to the browser and to GitLab;
- a perimeter-only security model in which internal services trust the network;
- a static per-user deployment model that limits scale.
None of these is fatal. All four can be addressed incrementally, and the improvements document proposes concrete paths.