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 APIThis 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 retrievalKeeping 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/resultThis 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 workerThis 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
+-- MariaDBThis 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 privateThis 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 / restartApplication 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 blockThis 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
- Introducing RNA-Bee — the project, RNA folding, evolution and its goals
- RNA-Bee Architecture — system architecture and technical decisions
- Building the RNA Simulation Engine — ViennaRNA, RNAstructure, mutation, folding, fitness and evolution
- 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
