Runtime dev, viewer et publication

Runtime dev vs runtime viewer

Fonctionnel

Le produit doit séparer développement et consultation publiée. Un dashboard publié s’ouvre normalement dans le viewer. Pour modifier, action explicite : “Entrer en édition”.

Technique

Même application, mais deux runtimes séparés :

/workspace/*   # développement
/viewer/*      # consultation publiée

Le viewer ne doit pas charger : moteur workspace complet, outils dev, gestion multi-fenêtres, panneaux d’édition, layout editor.

Séparation des ressources dev / consommation

Fonctionnel

Une requête qui plante en développement ne doit jamais impacter les dashboards publiés.

Technique

Prévoir séparation : workers dev/viewer, queues dev/viewer, caches dev/viewer, quotas dev/viewer, pools de connexions séparés et monitoring séparé.

Publication des dashboards

Fonctionnel

Un dashboard peut passer en mode publié via une action “Publier”. Le publié est destiné à la consultation par utilisateurs finaux.

Technique

status: draft | published
draftVersionId
publishedVersionId

Publication :

• fige une version publiée ;
• bascule vers ressources viewer ;
• conserve draft modifiable séparément.

Draft preview

Fonctionnel

Possibilité d’exceptions pour des consommateurs testeurs.

Technique

DraftPreviewAccess
  objectId
  objectType
  userId | groupId
  permission: view_draft
  expiresAt