Django: Ops Analiz API (Application Programming Interface) Katmanı (Django Ops Analiz API Katmani)

Analiz notebook’u API (Application Programming Interface) değildir

EDA ve ML notebook’ta doğar; üretimde Django (veya eşdeğeri) versiyonlu endpoint, auth ve sayfalama ile okuma sunar. Harita ve booking remote’ları bu katmanı tüketir.

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

Bu seri API sınırları, GitLab CE→EC2 teslimatı ve sürekli pentest’i bağlar.

Kavramlar ilk geçtiği yerde

📦 Analysis API
Django üzerinde okuma/analiz uçları — MFE ve control plane tüketicisi.

📦 Closed Network CI
Self-hosted GitLab CE runner’ları ile kapalı ağda pipeline.

📦 Artifact
EC2’ye giden sürümlenmiş deploy paketi.

📦 Continuous Pentest
Pipeline’a gömülü açık kaynak güvenlik taraması (ProjectDiscovery ekosistemi).

Kapalı ağda self-hosted GitLab CE, EC2’ye pipeline ile paket taşır.

Neden Django

Hızlı serileştirme, admin ops ihtiyaçları, Python ML ekosistemine yakınlık.

Ne expose edilir

Hotspot, rota deltası, geofence read model — asla ham ERP satırı.

Tüketiciler

Wait geofence, expedition map, booking desk aynı auth sözleşmesini kullanır.

Bu bölümde en çok karışan eşleştirmeler

❌ Notebook’u cron ile ‘API’ yapmak
✓ Üretim API’si sürüm ve auth ister

❌ Her MFE farklı SQL yazsın
✓ Tek analiz API’si kontratı korur

❌ Pentest’i yılda bir kez yapmak
✓ Pipeline içi sürekli tarama gerekir

Kendi sisteminizi denetleme listesi

1. Hangi endpoint’ler public OpenAPI’de?
2. Auth hangi remote ile paylaşılıyor?
3. EC2’ye kim imzalı artifact atıyor?
4. Son güvenlik taraması pipeline’da mı?
5. Frontend 5xx ile korelasyon ID taşıyor mu?

Bu bölümden aklında kalması gerekenler

1. Django analiz API’si frontend’in tek okuma kapısıdır.
2. Teslimat kapalı GitLab CE → EC2 disiplinidir.
3. Güvenlik taraması delivery’nin parçasıdır.

Notebook’tan geçen yol, production’a çıkmaz; API’den geçer.