Nathabee Creations

Category: Django

  • Building the RNA-Bee Web Platform

    INSERT: RNA-Bee Web Platform Hero Pattern

    Building the RNA-Bee Web Platform

    RNA-Bee is not only a simulation engine. It is a complete web platform designed to make computational RNA experiments accessible through a browser while keeping the scientific backend independent from the public website.

    The platform combines WordPress, Django REST Framework, PostgreSQL, MariaDB, Redis, Celery and Docker Compose behind a single public HTTPS endpoint.

    INSERT: Full Web Platform Diagram

    The web platform has two faces

    RNA-Bee exposes one public website, but internally two applications cooperate.

    WordPress

    WordPress handles the visible website: pages, navigation, project presentation and the block-based interface that users interact with.

    Django REST

    Django handles the scientific application layer: API endpoints, experiment models, validation, persistence and orchestration of computational work.

    This separation allows each side to remain focused. WordPress does not become a scientific backend, and Django does not need to solve content management, page building and editorial workflows.

    One domain, different routes

    Users reach RNA-Bee through one HTTPS domain. Apache acts as the public reverse proxy and decides which application receives each request.

    https://rna-bee.nathabee.de/
        |
        v
Apache
        |
        +---- /       → WordPress
        |
        +---- /api/   → Django REST API

    This produces a simple browser experience while preserving a clean backend boundary.

    The WordPress interface can call the API using normal HTTP requests without exposing internal services such as PostgreSQL or Redis to the internet.

    INSERT: Apache Reverse Proxy / Request Routing Image

    Why WordPress for the frontend?

    RNA-Bee uses WordPress as a frontend because the public site needs more than a single application screen. It also needs normal website capabilities such as project pages, explanations, navigation, reusable design patterns and eventually dedicated blocks for scientific interaction.

    • Block-based page construction
    • Reusable Gutenberg patterns
    • Custom RNA-Bee blocks
    • Theme-based visual identity
    • Accessible editorial content without changing backend code

    The important architectural decision is that WordPress remains the interface layer. Scientific state and simulation logic stay behind the API.

    Why Django REST for the application backend?

    The scientific side of RNA-Bee belongs naturally in Python because the broader computational biology ecosystem is strongly represented there.

    Django provides the application framework around that scientific code, while Django REST Framework exposes the operations through a structured HTTP API.

    • Validate RNA sequences and experiment parameters
    • Create and retrieve experiments
    • Persist simulation metadata
    • Start asynchronous jobs
    • Expose progress and results to the frontend
    • Provide a stable boundary around the scientific engine
    WordPress block
      |
      | HTTP / JSON
      v
Django REST API
      |
      +---- experiment data
      |
      +---- simulation jobs
      |
      +---- result retrieval

    Keeping long-running work out of HTTP requests

    Scientific computation does not fit well into a normal request-response cycle. A simple folding prediction may be fast, but evolutionary experiments can require repeated calculations across many sequences and generations.

    Instead of making the browser wait for the complete computation, RNA-Bee delegates longer jobs to Celery workers.

    Browser
   |
   v
POST /api/experiments/
   |
   v
Django validates request
   |
   v
Experiment saved
   |
   v
Task sent to Redis
   |
   v
Celery worker executes simulation
   |
   v
Results persisted
   |
   v
Frontend requests status/result

    This gives the platform a much cleaner execution model. A web request can finish quickly while the experiment continues independently in the background.

    INSERT: Async Experiment Lifecycle Diagram

    Redis as the message broker

    Redis provides the communication layer between Django and the Celery workers.

    Django does not need to know which worker will execute a task. It submits the job, Redis makes it available to the queue, and an available Celery worker takes responsibility for the computation.

    Django
   |
   v
Redis queue
   |
   v
Celery worker

    This loose coupling also makes it possible to add more workers later without changing the public API.

    PostgreSQL for scientific application data

    The Django application uses PostgreSQL for structured simulation and application data.

    • Experiments
    • RNA sequences
    • Predicted structures
    • Generations
    • Fitness values
    • Mutation history
    • Simulation status
    • Reproducibility metadata

    This data belongs to the scientific application, not to the content-management system.

    MariaDB stays with WordPress

    WordPress keeps its own MariaDB database for normal CMS responsibilities such as pages, menus, users, settings and editorial content.

    Using two databases may appear redundant, but it preserves an important boundary:

    Website content belongs to WordPress. Scientific experiment data belongs to the RNA application.

    Neither application needs direct database access to the other. Integration happens through application interfaces instead of shared tables.

    Docker Compose ties the platform together

    All application services are described through Docker Compose. This keeps the runtime environment explicit and reproducible.

    • wordpress — public WordPress application
    • wordpress-db — MariaDB for WordPress
    • django — Django REST application
    • celery-worker — asynchronous simulation execution
    • postgres — Django and simulation database
    • redis — task broker

    The containers can be rebuilt independently while persistent state remains in dedicated volumes.

    INSERT: Docker Compose Services Diagram

    Private Docker networks

    Not every service needs to communicate with every other service. RNA-Bee uses network boundaries so that services are connected only where necessary.

    Frontend network
   |
   +-- WordPress
   +-- Django

Backend network
   |
   +-- Django
   +-- Celery
   +-- PostgreSQL
   +-- Redis

WordPress DB network
   |
   +-- WordPress
   +-- MariaDB

    This makes dependencies clearer and reduces accidental exposure between unrelated services.

    Only the web layer is exposed

    PostgreSQL, MariaDB, Redis and Celery do not need public internet access.

    The host exposes only the web applications locally, and Apache publishes those applications through HTTPS.

    Internet
   |
   v
Apache :443
   |
   +---- WordPress container
   |
   +---- Django container

PostgreSQL   private
MariaDB      private
Redis        private
Celery       private

    This keeps infrastructure services behind the application boundary instead of turning every Docker port into a public service.

    Persistent data and disposable containers

    One of the useful properties of the Docker model is the distinction between applications and data.

    Containers can be recreated. Important data must survive independently.

    • MariaDB data
    • PostgreSQL data
    • WordPress files and uploads
    • Redis state where persistence is useful
    • Generated simulation results

    These are stored separately from the short-lived container filesystem, so rebuilding an application image does not imply losing the project state.

    A development and deployment workflow built around Git

    The reproducible platform also changes how RNA-Bee is developed.

    Local development
      |
      v
Git commit
      |
      v
GitHub repository
      |
      v
VPS git pull
      |
      v
Docker Compose rebuild / restart

    Application code, Docker configuration, the WordPress child theme and project-specific plugins can be versioned together, while runtime data remains outside Git.

    This creates a useful boundary between what defines the application and what the running application produces.

    WordPress as a programmable interface

    The long-term WordPress role goes beyond presenting static project pages.

    RNA-Bee can expose scientific functionality through dedicated Gutenberg blocks. A block can collect experiment parameters, call the Django API and render the returned state or results inside the website.

    RNA-Bee Gutenberg Block
        |
        +-- RNA sequence
        +-- experiment settings
        +-- start action
        |
        v
Django API
        |
        v
Experiment
        |
        v
Result
        |
        v
Visualization block

    This approach keeps the user experience native to WordPress while ensuring that the scientific implementation remains in Python.

    INSERT: Future RNA-Bee Gutenberg Simulation Block Screenshot

    Why this platform fits an experimental project

    RNA-Bee is expected to change as new experiments and interfaces are added. The platform therefore needs to support iteration without forcing every change into one monolithic application.

    • WordPress can evolve independently as the interface changes.
    • Django can evolve independently as experiment models become richer.
    • Celery workers can scale independently as computation becomes more expensive.
    • Scientific adapters can change without redesigning the public website.
    • Docker keeps the runtime reproducible while the project grows.

    The browser sees one RNA-Bee application; internally, each layer remains responsible for a different part of the problem.

    The platform is the foundation, not the experiment

    The web platform is now capable of hosting the project, serving the frontend and API, persisting application state and executing asynchronous jobs. But infrastructure alone does not make RNA-Bee scientifically interesting.

    The next milestones move back toward the experiments themselves: the first real folding workflow, mutation and selection models, RNA structure visualization and reproducible evolutionary runs.

    The RNA-Bee series

    1. Introducing RNA-Bee — the project, RNA folding, evolution and its goals
    2. RNA-Bee Architecture — system architecture and technical decisions
    3. Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
    4. Building the RNA-Bee Web Platform — Docker, Django REST, Celery, Redis and WordPress integration

    Future build notes

    As RNA-Bee moves from platform setup into actual experiments, individual milestones can be documented separately.

    • RNA-Bee: First folding experiment
    • RNA-Bee: Mutation and selection model
    • RNA-Bee: Building the WordPress simulation block
    • RNA-Bee: Visualizing RNA structures
    • RNA-Bee: Reproducible experiments

    Project links

    Open RNA-Bee

    View source on GitHub