Architecture technique

Dodock est un framework applicatif full-stack fondé sur les métadonnées. Il fournit tous les outils nécessaires pour déployer des applications métier en production : base de données, cache, tâches de fond et notifications temps réel.

Vue d'ensemble

L'architecture de Dodock s'organise autour du concept de bench : un environnement qui héberge plusieurs sites (tenants) partageant les mêmes applications.

Concepts clés

Architecture multi-tenant

Dodock est une plateforme multi-tenant. Chaque tenant (appelé "site") possède :

• Sa propre base de données
• Ses propres fichiers uploadés
• Sa propre configuration

Les applications sont partagées entre tous les sites du bench.

Pile technique

Dodock repose sur une pile technique moderne et éprouvée.

Composants principaux

MariaDB

MariaDB stocke toutes les données : documents, métadonnées des DocTypes, utilisateurs et configurations. Chaque site possède sa propre base de données, garantissant une isolation complète en environnement multi-tenant.

Redis

Trois instances Redis distinctes assurent différentes fonctions :

Structure des répertoires

L'initialisation d'un bench avec bench init crée cette structure :

dokos-bench/
├── apps/                         # Applications installées
│   ├── frappe/                   # Framework (obligatoire)
│   ├── erpnext/                    # Application métier
│   └── custom_app/               # Applications personnalisées
│
├── sites/                        # Sites hébergés
│   ├── assets/                   # Assets compilés (JS, CSS)
│   ├── apps.txt                  # Apps installables
│   ├── common_site_config.json   # Configuration partagée
│   └── monsite.localhost/        # Répertoire du site
│       ├── site_config.json      # Configuration du site
│       ├── private/              # Fichiers privés
│       ├── public/               # Fichiers publics
│       └── locks/                # Verrous de synchronisation
│
├── config/                       # Configuration Redis
│   ├── redis_cache.conf
│   ├── redis_queue.conf
│   └── redis_socketio.conf
│
├── logs/                         # Journaux des processus
├── env/                          # Environnement virtuel Python
└── Procfile                      # Définition des processus

Processus et services

L'exécution de Dodock nécessite des services système (base de données, cache) et des processus applicatifs (serveur web, workers).

Les services système dépendent de l'architecture de déploiement. Les processus applicatifs sont définis dans le Procfile en développement et dans config/supervisor.conf en production.

Services système

Processus applicatifs

Serveur WSGI : répond aux requêtes HTTP. En développement, bench start lance le serveur Werkzeug. En production, Gunicorn est configuré automatiquement via Supervisor.

Workers Redis : exécutent les tâches de fond (emails, rapports, calculs). Démarrés automatiquement par bench start en développement, configurés dans Supervisor en production.

Scheduler : planifie l'exécution des tâches programmées (horaires, quotidiennes, etc.). Même gestion que les workers.

Développement vs Production

developer_mode

developer_mode est un paramètre distinct du mode de déploiement. Lorsqu'il est activé, les modifications apportées aux DocTypes, rapports et autres composants via l'interface soient répercutées dans le dépôt de l'application, le site doit être en developer_mode.

Cette option s'active dans le fichier site_config.json du site :

sites/{votre_site}/site_config.json

{
  "developer_mode": 1
}

Activé : les modifications apportées aux DocTypes, rapports, scripts et autres composants sont sauvegardées dans le code source de l'application. Elles peuvent être versionnées avec Git, partagées et déployées sur d'autres instances.

Désactivé : les modifications restent isolées sur l'instance courante. Elles ne sont pas synchronisées avec le dépôt de l'application, ce qui complique le suivi des changements et la collaboration.

L'accès complet aux options de développement nécessite d'être connecté en tant qu'Administrator.

Résolution du site

Le framework détermine le site cible selon :

1. L'en-tête HTTP Host de la requête
2. L'en-tête X-Frappe-Site-Name (pour les API)
3. Le fichier currentsite.txt (en développement)

Configuration

Chaque site possède un fichier site_config.json :

{
  "db_name": "site1_db",
  "db_password": "••••••••",
  "encryption_key": "••••••••"
}

La configuration commune se trouve dans common_site_config.json.

Cycle de vie d'une requête

1. Réception : Nginx reçoit la requête HTTP/WebSocket
2. Routage : Nginx route vers Gunicorn (HTTP) ou Socket.io (WebSocket)
3. Résolution : Le framework identifie le site via l'en-tête Host
4. Authentification : Vérification de la session utilisateur
5. Cache : Consultation du cache Redis
6. Base de données : Requête MariaDB si nécessaire
7. Logique métier : Exécution des contrôleurs et hooks
8. Réponse : Sérialisation JSON/HTML et envoi

Pour aller plus loin