Proposal: Migrate GeoDaisy to a Django-Centric Python Stack

[jakob1379]

Summary

Propose migrating GeoDaisy from the current Express + Vite stack to Django so the project benefits from a unified, production-hardened Python framework while keeping the existing Deck.gl mapping experience and a clearly defined request pipeline.

Background

• GeoDaisy currently relies on an Express proxy that secures DMI, HIP, and MapTiler access while a Vite frontend renders the exploratory map UI.
• The roadmap calls for a Python-first deployment model, suggesting that our platform, auth, and API layers should consolidate around the Python ecosystem.
• Platform stakeholders expect consistent observability and audit trails across proxy calls, which are easier to supply once everything terminates inside Django.

Why Django

• Django is a well-established, battle-tested framework with nearly 20 years of adoption across research, government, and enterprise domains.
• The project enjoys long-term support releases, rapid security response, and a thriving community that continuously validates best practices for data-heavy applications like GeoDaisy.

Ecosystem Advantages

• Django REST Framework provides expressive serializers, viewsets, pagination, and throttling to reimplement our proxy endpoints with robust validation.
• django-allauth enables pluggable authentication/OAuth with major identity vendors, reducing time-to-production for secure logins.
• The wider Django ecosystem includes django-environ for configuration management, django-channels for realtime features, and Celery integrations for async jobs.

Proposed Migration Approach

1. Scaffold a Django project that replaces the Express server, porting existing validation and interpolation logic into DRF views.
2. Serve the current Deck.gl/Mapbox bundle as Django static assets, using templates plus HTMX/Alpine.js to keep dynamic panels lightweight.
3. Configure django-allauth for OAuth/OIDC logins and evaluate permission scopes for data exports and administrative tooling.
4. Introduce a BFF-style aggregation layer inside Django that normalizes responses from DMI, HIP, and MapTiler before they reach the frontend.
5. Update Docker/systemd workflows to run Django via gunicorn or uvicorn, maintaining parity with existing deployment scripts.

System Design Recommendation

• Centralize request handling through a Django API Gateway app that issues signed tile URLs, proxies data provider queries, and enriches payloads with cached metadata.
• Attach Celery or Django-Q for asynchronous refresh of heavy geospatial datasets, allowing the frontend to hydrate incrementally without locking the request thread.
• Standardize observability by instrumenting Django middleware with OpenTelemetry exporters feeding into the existing monitoring stack.

sequenceDiagram
    participant U as Analyst
    participant FE as Deck.gl Frontend
    participant API as Django API Gateway
    participant DMI as DMI Data Services
    participant HIP as HIP API
    participant MT as MapTiler Tiles

    U->>FE: Request map view / analytics
    FE->>API: Fetch layer metadata + authenticate
    API->>API: Validate session via allauth
    opt Credentialed request
        API->>DMI: Proxy dataset query
        DMI-->>API: Return dataset
        API->>HIP: Fetch HIP resources
        HIP-->>API: Return enriched data
    end
    API-->>FE: Unified GeoJSON payload
    API->>MT: Generate signed tile URL
    MT-->>FE: Provide tiles through CDN
    FE-->>U: Render map and analytics panels

Loading

Benefits

• Single, cohesive Python stack with first-class auth, ORM, and admin tooling reduces operational complexity.
• Mature security posture and documentation help satisfy compliance needs and onboarding for new contributors.
• Rich ecosystem accelerates future features such as caching, background processing, and real-time updates.
• Consistent request sequencing improves traceability for audit and incident response.

Open Questions

• Do we need persistent storage beyond API proxies (e.g., caching, user preferences), and if so which database fits best?
• Which identity providers should django-allauth target first (institutional SSO, OAuth, etc.)?
• What SLAs should govern asynchronous refresh jobs, and how do we retry failed provider calls without overwhelming third-party services?
• What is the phased timeline for retiring the Node-based services once Django endpoints reach feature parity?

References

• Django Project
• Django REST Framework
• django-allauth
• OpenTelemetry for Python