Explorer
KNOW-PAT-243

Architecture minimale d'une application créative Web

Domaine
architecture
Type
pattern
Priorité
P1

Architecture minimale d'une application créative Web

Problème

Un éditeur d'image, de vidéo ou d'audio devient fragile lorsque l'interface, le moteur de calcul, les fichiers et la synchronisation partagent le même état et le même thread. La réponse n'est pas un empilement immédiat de WebAssembly, WebGPU et microservices.

Architecture de départ

  1. Interface, commandes et accessibilité sur le thread principal.
  2. Moteur de traitement derrière une API stable, dans un Worker dès qu'une tâche bloque réellement l'interaction.
  3. État de projet séparé des médias : modèle versionné, sérialisable et rejouable.
  4. Médias et temporaires dans un stockage adapté aux volumes, jamais dans localStorage.
  5. Services cloud facultatifs : compte, sauvegarde distante, partage et collaboration. Le document local reste utilisable si le réseau disparaît quand le produit le permet.
UI / commandes
      | messages typés
Moteur Worker ---- rendu intensif
      |                 |
état projet       Canvas / GPU
      |
IndexedDB + OPFS ---- synchronisation cloud optionnelle

Contrats à définir avant la technologie

  • Commandes déterministes : entrée, résultat, progression, annulation et erreur.
  • Propriété explicite des buffers et fermeture des ressources natives (VideoFrame, handles, contextes).
  • Version du format de projet et migrations testées.
  • Budget mémoire, taille maximale de document et appareils cibles.
  • Mode dégradé si une capacité avancée manque.

Progression

  • MVP : JavaScript/TypeScript, Canvas 2D si suffisant, un Worker pour la tâche mesurée comme lourde, sauvegarde IndexedDB.
  • Après preuve : OffscreenCanvas, WebGL ou WebCodecs selon le goulot observé.
  • Seulement si justifié : WebAssembly pour réutiliser du code natif ou accélérer un noyau mesuré ; WebGPU derrière détection et repli ; collaboration CRDT lorsque plusieurs utilisateurs éditent réellement le même état.

Gate

Une évolution est acceptée seulement si elle améliore une métrique définie dans KNOW-PAT-250 sans supprimer la récupération après crash, l'accessibilité ou le fonctionnement sur la matrice de navigateurs retenue.

Sources