Skip to main content

​
Core request flow

Django General Structure Diagram Ruoom follows Django’s model-view-template flow. Core owns the project settings and root URL configuration, while installed plugins contribute Django apps, URL namespaces, templates, static assets, migrations, and optional integration metadata.

​
Core applications

  • administration: businesses, domain mappings, locations, rooms, operating days, waivers, staff-facing configuration, navigation, permissions, and domain bootstrap.
  • registration: profiles, sign-in and signup flows, privacy handling, authentication middleware, and plugin-provided sign-in options.
  • customer: customer account and profile pages.
  • ruoom: settings, root routing, plugin discovery and metadata, email infrastructure, storage backends, health checks, and UI customization.
  • security: key and encryption support.
Ruoom Core Models

​
Plugin lifecycle

  1. A released wheel installs a package below the shared plugins Python namespace.
  2. RUOOM_PLUGINS supplies the ordered plugin identifiers for the deployment.
  3. Core maps identifiers to Django app configs and adds only importable packages to INSTALLED_APPS.
  4. plugins.<name>.plugin.PLUGIN_METADATA declares the URL prefix and namespace plus optional navigation, settings tabs, sign-in options, permission groups, public/staff URL patterns, middleware, and dependencies.
  5. Core mounts each plugin’s URLs and exposes its metadata to shared UI and authentication components.
Unknown identifiers fail during settings initialization. Known but uninstalled packages are skipped, so a reliable deployment should install every artifact before setting RUOOM_PLUGINS, then run python manage.py check.

​
Core endpoints

  • /administration/: staff dashboard and management workflows.
  • /customer/: customer account workflows.
  • /registration/: password authentication and account creation.
  • /admin/: Django admin.
  • /health/ and /health: health checks.
  • /accounts/: Django authentication URLs.
Plugin endpoints are mounted dynamically. Their complete paths combine the metadata prefix with the routes listed in each plugin’s architecture page.

​
Persistence and storage

Core uses SQLite by default. A sqlite:// or postgresql:// DATABASE_URL selects an explicit backend. Local uploads use the filesystem; STORAGE=S3 switches private uploaded media to an S3-compatible backend while public static assets remain same-origin through WhiteNoise.