L’architecture ServerFree

• Le serverless ne signifie pas réellement qu’il n’y a pas de serveur, mais simplement qu’on utilise le serveur de quelqu’un d’autre
• L’architecture ServerFree propose un concept permettant d’exécuter du code sans serveur backend, conteneur ni machine virtuelle
• Dans cette architecture, le code s’exécute dans le navigateur et seul un serveur servant des fichiers statiques est nécessaire
• Démonstration d’une méthode pour packager une application web afin qu’elle puisse s’exécuter dans le navigateur
• Le code frontend est buildé comme d’habitude, le backend est packagé pour s’exécuter dans un Web Worker, et la base de données utilise SQLite compilé en WebAssembly

Idée

• Il a été décidé de créer un projet de démo via le content marketing, avec l’idée de développer un suivi de candidatures attirant l’attention sur les questions de confidentialité, inspiré par Hacker News
• Le projet a évolué en un processus de développement d’une nouvelle architecture, en résolvant des problèmes liés aux Web Workers, aux incohérences de documentation et aux documents manquants.

Première tentative avec une architecture classique (la partie facile)

• L’application a été construite avec SubZero CLI pour modifier le schéma de base de données et configurer les autorisations.
• Elle fournit des fonctions CRUD et de filtrage, mais l’interface a été personnalisée de façon à se rapprocher davantage d’un produit que d’une simple démo.
• La sidebar a été déplacée en haut pour réduire l’espace gaspillé à gauche.
• Des composants Show, Create, Edit et List ont été ajoutés à la page Opportunities.
• Un flux de filtrage complexe a été mis en place sans toucher au code backend.
• Le dashboard a été amélioré pour afficher des données pertinentes comme « opportunités ouvertes », « progression moyenne / candidature » et « nombre moyen de jours après candidature ».
• Pour le déploiement en production, une image Docker a été buildée, la base de données a été initialisée, puis le conteneur a été exécuté.
• Le fichier de base de données SQLite a été conservé hors du conteneur afin de préserver les données de manière persistante.
• Turso DB a été utilisé pour résoudre les problèmes de persistance et de sauvegarde de la base de données SQLite.

Passage à l’architecture ServerFree (la partie amusante)

• SQLite a été compilé en WebAssembly pour être utilisé comme base de données.
• OPFS (Origin-Private FileSystem) a été utilisé pour stocker les données.
• Le code backend s’exécute dans un Web Worker afin d’éviter de bloquer le thread de l’interface.
• Express a été remplacé par itty-router pour assurer la compatibilité avec le navigateur.
• Un Service Worker intercepte et traite les requêtes entre l’interface et le backend.
• Une communication fiable entre le Service Worker et le Web Worker a été mise en place via le thread principal.
• Le code lié à l’authentification a été retiré du thread principal (UI).
• Les données sont stockées sur l’ordinateur de l’utilisateur et ne sont pas envoyées à un serveur.

Conclusion

• Cette architecture est particulièrement utile lorsque les données client sont indépendantes et n’ont pas besoin d’être partagées entre utilisateurs.
• L’absence de serveur backend réduit les coûts d’hébergement, renforce la confidentialité des données et améliore la sécurité.
• Avec des outils comme Electric, il est possible de synchroniser une partie de la base de données vers le client et de traiter certaines requêtes/queries dans le navigateur