This note summarizes the structure and cross-cutting runtime of the upstream codebase as observed by enumerating packages, settings, and URL configuration. It does not reproduce source listings.
A filesystem survey of the primary Python package directory shows on the order of 1,100 Python modules and roughly 1,900 text-oriented assets (Markdown, HTML, JavaScript, CSS, and Python combined). Automated tests, migrations, static vendor bundles, and documentation inside the tree contribute to that count. This confirms a large, mature web application with broad surface area rather than a thin service.
The central settings module wires a fixed set of first-party Django apps. Together they form Source Application A’s built-in functionality:
Third-party Django apps in the same settings list provide REST framework integration, OpenAPI generation, GraphQL bindings, filtering, tables, tagging, health checks, Prometheus metrics, request profiling (Silk), structured logging, CORS, social authentication, and runtime-tunable settings (Constance pattern).
Browser routes group under path prefixes such as circuits, cloud, data validation, DCIM, extras, IPAM, load balancers, tenancy, users, virtualization, VPN, and wireless. Core views handle home, global search, about, authentication, metrics (optional), media, worker status, Jinja rendering utilities, and theme preview.
Two extension mount points appear: one for packaged apps using a modern apps URL namespace and another for legacy plugin URL patterns—reflecting an evolutionary split while keeping backward compatibility.
Administrative and operational endpoints include a customized admin site, health checks, optional authenticated metrics, Celery worker status, and secured file download routes for database-stored attachments.
The API root mirrors the domain apps (same list as above) under a single API prefix. Additional endpoints expose OpenAPI schema in multiple formats, interactive Swagger and ReDoc, a JSON schema for settings (for UI-assisted configuration), a combined GraphQL-over-HTTP entry, status, and UI-helper APIs (for example dynamic filter field metadata and CSV import hints). App extensions register parallel API trees under both apps and legacy plugin API prefixes.
Request processing layers include:
This design separates transport and identity concerns from domain auditing.
Celery is integrated for asynchronous tasks, scheduled jobs, beat-driven schedules, and result persistence. Encoders and custom control paths support operational tooling. Kubernetes-oriented execution paths exist for isolating certain jobs.
An internal event broker abstraction allows registering multiple brokers at startup (for example syslog and Redis pub/sub). Configuration supports per-broker topic include/exclude lists. Publication fans out object lifecycle and user-oriented events to all registered brokers. Loading is defensive: misconfigured broker classes fail loudly at startup rather than silently dropping events.
Core hosts schema initialization, type generation utilities, and performance-oriented tests (for example guarding against excessive database fan-out). The public contract remains query-only in typical deployments.
The core tree includes integration points for a versioned SQL database that supports named branches and automatic commit semantics. When that backend is not in use, branch context becomes a no-op so the same code paths run on standard PostgreSQL or MySQL deployments.
Management commands cover database migrations, post-upgrade hooks, test data generation, secrets generation, content-type cache refresh, GraphQL query auditing, dynamic group auditing, installation metric submission, and model validation. A small CLI supports migration assistance for template and UI framework upgrades.
The core package contains extensive unit and integration tests spanning authentication, APIs, GraphQL, navigation, filters, forms, Celery, events, UI components, and release mechanics. Factory helpers and schema utilities support consistent test data construction.
Dedicated subpackages implement navigation, breadcrumbs, homepage composition, object detail tabbing, charts integration, bulk action buttons, and template tag libraries for permissions and UI widgets. View layers use router patterns that register many view sets per model for list/detail/create/edit/delete flows with shared behaviors.
The application can serve bundled static media, host embedded documentation for installed apps under configurable routes, and fall back to error pages when static collection fails in a given environment.
Beyond Django and the database, notable dependency families include: REST and schema tooling, GraphQL, Celery and Redis clients, Git integration, filtering and tables, tagging, tree queries for hierarchies, health and metrics, profiling, structured logging, cryptography, SSO helpers, and template engines (Django templates plus Jinja for specific features).