Django as the Ops Analysis API (Application Programming Interface) Layer (Django As The Ops Analysis API Layer)

An analysis notebook is not an API (Application Programming Interface)

EDA and ML start in notebooks; production needs Django (or equivalent) with versioned endpoints, auth, and pagination. Maps and booking remotes consume that layer.

PostGIS / Mongo / ES / OSRM edge
              ↓
        Django Analysis API
         ↙        ↘
   Control Plane   MFE remotes

This series connects API boundaries, GitLab CE→EC2 delivery, and continuous pentesting.

Concepts, defined where they first appear

📦 Analysis API
Django read/analysis endpoints consumed by MFEs and the control plane.

📦 Closed Network CI
Pipelines on self-hosted GitLab CE runners inside a closed network.

📦 Artifact
Versioned deploy package shipped to EC2.

📦 Continuous Pentest
Open-source security scanning in the pipeline (ProjectDiscovery ecosystem).

Self-hosted GitLab CE in a closed network ships packages to EC2 via pipeline.

Why Django

Fast serialization, ops-friendly admin needs, proximity to the Python ML ecosystem.

What gets exposed

Hotspots, route deltas, geofence read models — never raw ERP rows.

Consumers

Wait geofence, expedition map, and booking desk share the auth contract.

The mappings that get confused most often

❌ Cron a notebook and call it an API
✓ Production APIs need versioning and auth

❌ Let each MFE write its own SQL
✓ One analysis API protects the contract

❌ Pentest once a year
✓ Continuous scanning belongs in the pipeline

A checklist for auditing your own system

1. Which endpoints are in public OpenAPI?
2. Which remote shares auth?
3. Who pushes signed artifacts to EC2?
4. Was the last security scan in the pipeline?
5. Do frontends carry correlation IDs on 5xx?

What to take away from this part

1. Django analysis API is the frontend’s read gateway.
2. Delivery is closed GitLab CE → EC2 discipline.
3. Security scanning is part of delivery.

The path from notebook to production goes through an API.