API Platform Architecture
Turning AlgoLens into infrastructure.
“The value of a platform is measured by the products it allows others to build.”
API first, browser second
The API is not a side feature of the web app. The web app is a client of the API. Any capability available in the browser—trace generation, explanation, export, comparison, complexity analysis, project management, or sharing—should be reachable programmatically. This is what makes AlgoLens useful for LMS platforms, IDEs, internal engineering tools, interview products, research pipelines, and documentation systems.
The API surface should be split by domain and stability. Execution APIs launch runs, Trace APIs read and compare immutable traces, Visualization APIs produce media and replay outputs, AI APIs explain and critique, Learning APIs generate quizzes and exercises, Project APIs manage workspaces and collections, and Administration APIs handle keys, billing, analytics, usage, and organizations.
Long-running work should use jobs. Streaming should support both WebSocket and Server-Sent Events for live trace events, progress, AI tokens, exports, notifications, and comments. REST remains the default for broad adoption, GraphQL serves dashboard-style aggregate reads, and SDKs hide protocol details behind native client libraries.
Universal Core
├─ REST API
├─ Streaming API
└─ GraphQL
↓
Web App · CLI · SDKs · LMS · IDEs · Third-party Products