Time series data API
Split a time-series platform into a hardened TypeScript gateway and Java service.
Outcomes
gateway + service Runtime split
OAuth2, rate limits Edge controls
OpenAPI Contract
The problem
A public data API should not mix every concern into one service. Traffic control, authentication, HTTPS, domain logic, persistence, and documentation all matter, but they do not belong in the same layer.
Architecture split
| Layer | Responsibility | Stack |
|---|---|---|
| Gateway | HTTPS, rate limits, OAuth2 validation, proxying | Express, TypeScript |
| Service | Domain API, persistence, OpenAPI contract | Java 21, Spring Boot |
| Data | Time-series persistence | PostgreSQL |
| Ops | Local stack and repeatable setup | Docker, Makefile, env templates |
Approach
The repository uses a production-style split: the gateway is the public boundary and the service is the domain boundary.
- Gateway at the edge. It validates access tokens, limits abusive traffic, terminates HTTPS in local development, and forwards clean requests.
- Service for the domain. The Java service exposes the time-series API, persists data, and publishes OpenAPI docs.
- Operational clarity. Docker, environment templates, Postman assets, and documentation make the system understandable to run.
Outcome
This is a compact but serious backend architecture project. It shows API thinking beyond endpoints: trust boundaries, deployable structure, local operations, and contracts that another engineer can inspect.
Repository
The public project lives at timeseries-api.