Remplacement de la stack HTMx #65

New Issue

florian_briand · 2024-09-22T19:06:14+02:00

florian_briand commented

2024-09-22 19:06:14 +02:00

Comme évoqué sur Matrix il y a quelques semaines, à l'usage, HTMx est finalement un frein dans le développement de l'interface. La simple tentative de mettre en place, dans #61, une popup de login s'avère pénible. HTMx, c'est très bien pour des sites web, en concurrence avec un Django ou un RoR, mais pour des applications, on sort de son cadre idéal et c'est juste relou.

Il est donc temps de passer à une nouvelle stack. Ce ticket est là pour en discuter.

Architecture

Avec HTMx, on était parti sur une architecture "client lourd autonome" avec un seul binaire, comportant :

un serveur backend web (axum) fournissant du HTMx et allant taper dans la base de donnée ou utilisant la librairie sesam-vitale
une webview (Tauri) affichant le frontend : des pages HTMx générées par le serveur axum
un design system à base de tailwind + flowbite
une dynamisation en JS, quand nécessaire, à base de AlpineJS
une base de donnée

J'aimerais remettre en question cette approche "client lourd autonome", pour envisager une solution séparant le client du serveur+bdd. Cela fait suite aux observations effectuées dans les pharmacies du projet, sur leur fonctionnement et leur infrastructure, ainsi qu'une meilleure compréhension du fonctionnement des LGO.

En effet, la "base de donnée" est centrale dans un LGO, et se doit d'être une "unique source de vérité". Aussi, il parait logique d'avoir, de manière stable, un "serveur backend" installé sur une des machines d'une officine ; et d'avoir des clients qui s'y connectent.
En se débarrassant de HTMx, on se débarrasse de la nécessité d'avoir un serveur pour générer le frontend : par exemple, avec une SPA, tout le frontend peut être fournis à la webview de Tauri sous la forme d'assets web (JS/Webcomponents/CSS/...).
On peut donc, sans contraintes, adopter une architecture client "lourd" (tauri+SPA) - serveur.

Je ne vois, finalement, que des avantages à cette approche :

c'est une approche classique, donc "fiable", au sens où la majorité des librairies et techno actuelles sont pensées pour un tel fonctionnement
cela permet de la souplesse dans les setups : installer le serveur sur le poste le plus approprié et on fait tourner des clients sur les périphériques qui nous arrangent, localement ou à distance, ouvrant la porte à des clients mobiles ou une approche SaaS, par exemple
ça n'empêche pas de la subtilité : pour des setups particuliers, on peut mettre en place de la réplication et du load balancer, on peut séparer le serveur "opérationnel" d'un serveur "ETL" exploitant les données pour des dashboards, on peut ...

On aurait donc :

Backend
- Un serveur web (axum) exposant une API REST/JSON classique ; il pourrait aussi exposer la SPA ou d'autres interfaces web, par exemple pour pouvoir fournir des accès web sur des fonctionnalités particulières, aux patients ou à l'équipe
- Une base de donnée (SeaORM + SQLite)
- Librairie sesam-vitale
Client lourd
- Webview Tauri
- SPA : techno à définir, cf + bas
- Librairie sesam-vitale

Techno SPA

Deux approches s'offrent à nous :

Une approche TypeScript classique, avec un framework classique de SPA : React/Next, Vue/Vite/Nuxt, Svelte ...
Une approche en Rust : Leptos, Sycamore,

Notons qu'il existe aussi Dioxus Labs, qui est une surcouche à Tauri, encapsulant un framework homemade, sledgehammer ... Mais le développeur semble seul, tout comme le développeur de sledgehammer, ce qui ne me rassure pas.

J'ai creusé un peu les avantages/inconvénients des approches TS versus Rust, et voilà mes observations :

Les approches Rust génèrent du WASM (WebAssembly), très performant côté frontend, mais avec lequel c'est relou d'intéragir en JS. Ce qui peut fermer la porte pour l'usage de certaines librairies JS côté client.
Il faut bien comprendre que, dans les deux cas, le code TS ou Rust "génèrent" le code WASM/JS de l'application client. Les performances, la sécurité et la fiabilité de Rust ne sont donc des avantages qu'au "build"
L'avantage au "build" de Rust est concurrencé par divers techno : TypeScript, par son typage, augmente la fiabilité par rapport à Javascript ; Vite, est une "nouvelle" approche de builder, qui réduit largement certains défauts rencontrés dans les anciennes approches de build JS/TS
Côté performances, les frameworks Rust sont à peine plus performant que VueJS

Comme évoqué sur Matrix il y a quelques semaines, à l'usage, HTMx est finalement un frein dans le développement de l'interface. La simple tentative de mettre en place, dans #61, une popup de login s'avère pénible. HTMx, c'est très bien pour des sites web, en concurrence avec un Django ou un RoR, mais pour des applications, on sort de son cadre idéal et c'est juste relou. Il est donc temps de passer à une nouvelle stack. Ce ticket est là pour en discuter. # Architecture Avec HTMx, on était parti sur une architecture "client lourd autonome" avec un seul binaire, comportant : - un serveur backend web (axum) fournissant du HTMx et allant taper dans la base de donnée ou utilisant la librairie sesam-vitale - une webview (Tauri) affichant le frontend : des pages HTMx générées par le serveur axum - un design system à base de tailwind + flowbite - une dynamisation en JS, quand nécessaire, à base de AlpineJS - une base de donnée J'aimerais remettre en question cette approche "client lourd autonome", pour envisager une solution séparant le client du serveur+bdd. Cela fait suite aux observations effectuées dans les pharmacies du projet, sur leur fonctionnement et leur infrastructure, ainsi qu'une meilleure compréhension du fonctionnement des LGO. En effet, la "base de donnée" est centrale dans un LGO, et se doit d'être une "unique source de vérité". Aussi, il parait logique d'avoir, de manière stable, un "serveur backend" installé sur une des machines d'une officine ; et d'avoir des clients qui s'y connectent. En se débarrassant de HTMx, on se débarrasse de la nécessité d'avoir un serveur pour générer le frontend : par exemple, avec une SPA, tout le frontend peut être fournis à la webview de Tauri sous la forme d'assets web (JS/Webcomponents/CSS/...). On peut donc, sans contraintes, adopter une architecture client "lourd" (tauri+SPA) - serveur. Je ne vois, finalement, que des avantages à cette approche : - c'est une approche classique, donc "fiable", au sens où la majorité des librairies et techno actuelles sont pensées pour un tel fonctionnement - cela permet de la souplesse dans les setups : installer le serveur sur le poste le plus approprié et on fait tourner des clients sur les périphériques qui nous arrangent, localement ou à distance, ouvrant la porte à des clients mobiles ou une approche SaaS, par exemple - ça n'empêche pas de la subtilité : pour des setups particuliers, on peut mettre en place de la réplication et du load balancer, on peut séparer le serveur "opérationnel" d'un serveur "ETL" exploitant les données pour des dashboards, on peut ... On aurait donc : - Backend - Un serveur web (axum) exposant une API REST/JSON classique ; il pourrait aussi exposer la SPA ou d'autres interfaces web, par exemple pour pouvoir fournir des accès web sur des fonctionnalités particulières, aux patients ou à l'équipe - Une base de donnée (SeaORM + SQLite) - Librairie sesam-vitale - Client lourd - Webview Tauri - SPA : techno à définir, cf + bas - Librairie sesam-vitale # Techno SPA Deux approches s'offrent à nous : - Une approche TypeScript classique, avec un framework classique de SPA : React/Next, Vue/Vite/Nuxt, Svelte ... - Une approche en Rust : Leptos, Sycamore, > Notons qu'il existe aussi [Dioxus Labs](https://dioxuslabs.com), qui est une surcouche à Tauri, encapsulant un framework homemade, [sledgehammer](https://dioxuslabs.com/blog/templates-diffing) ... Mais le développeur semble seul, tout comme le développeur de sledgehammer, ce qui ne me rassure pas. J'ai creusé un peu les avantages/inconvénients des approches TS versus Rust, et voilà mes observations : - Les approches Rust génèrent du WASM (WebAssembly), très performant côté frontend, mais avec lequel c'est relou d'intéragir en JS. Ce qui peut fermer la porte pour l'usage de certaines librairies JS côté client. - Il faut bien comprendre que, dans les deux cas, le code TS ou Rust "génèrent" le code WASM/JS de l'application client. Les performances, la sécurité et la fiabilité de Rust ne sont donc des avantages qu'au "build" - L'avantage au "build" de Rust est concurrencé par divers techno : TypeScript, par son typage, augmente la fiabilité par rapport à Javascript ; Vite, est une "nouvelle" approche de builder, qui réduit largement certains défauts rencontrés dans les anciennes approches de build JS/TS - Côté performances, les frameworks Rust sont à peine plus performant que VueJS

florian_briand added the

enhancement

module/desktop

module/frontend

labels 2024-09-22 19:06:14 +02:00

florian_briand self-assigned this 2024-09-22 19:06:14 +02:00

florian_briand added this to the 0 - POC project 2024-09-22 19:06:14 +02:00

florian_briand commented

2024-09-22 19:09:12 +02:00

À titre personnel, après toutes ces réflexions, je suis tenté pour aller vers une approche Tauri + Vue/Vite en Typescript.

C'est une techno que je maitrise déjà, qui est réputée et largement pratiquée sur le marché.
C'est moins funky que Leptos, par exemple, et réduit les risques (d'avoir du mal à recruter, de voir la techno disparaître, de rencontrer des problèmes marginaux ...)

Je pense intéressant, également, de s'appuyer sur Nuxt (surcouche à Vue) plutôt que sur Vue "vanilla", pour plusieurs raisons :

L'exemple actuellement dans la doc de Tauri est avec Nuxt, c'est donc moins d'emmerdes au setup
Nuxt fournit un "cadre" à Vue : le routeur, la gestion des états, une gestion centralisée des différentes couches de "DX" (linting, vite ...)
Une potentielle capacité à optimiser le build : on peut, avec Nuxt, fournir simplement un "gros bundle JS" dans un index.html ; mais on peut aussi "pré-builder" un certain nombre de pages HTML, pour ne pas avoir besoin que le JS construise "tout" le DOM

À titre personnel, après toutes ces réflexions, je suis tenté pour aller vers une approche Tauri + Vue/Vite en Typescript. C'est une techno que je maitrise déjà, qui est réputée et largement pratiquée sur le marché. C'est moins funky que Leptos, par exemple, et réduit les risques (d'avoir du mal à recruter, de voir la techno disparaître, de rencontrer des problèmes marginaux ...) Je pense intéressant, également, de s'appuyer sur Nuxt (surcouche à Vue) plutôt que sur Vue "vanilla", pour plusieurs raisons : - L'exemple actuellement dans la doc de Tauri est avec Nuxt, c'est donc moins d'emmerdes au setup - Nuxt fournit un "cadre" à Vue : le routeur, la gestion des états, une gestion centralisée des différentes couches de "DX" (linting, vite ...) - Une potentielle capacité à optimiser le build : on peut, avec Nuxt, fournir simplement un "gros bundle JS" dans un index.html ; mais on peut aussi "pré-builder" un certain nombre de pages HTML, pour ne pas avoir besoin que le JS construise "tout" le DOM

florian_briand referenced this issue

2024-09-23 19:06:34 +02:00

Refactoring de l'interface : migration d'un monolithe HTMx vers un client Nuxt + serveur Axum #66

florian_briand referenced this issue

2024-09-24 01:14:00 +02:00

Ajout d'un parcours utilisateur⋅ice de connexion / déconnexion #67

florian_briand referenced this issue from a commit

2024-09-24 12:55:29 +02:00

Merge pull request 'Refactoring de l'interface : migration d'un monolithe HTMx vers un client Nuxt + serveur Axum' (#66) from feat/65_move_out_htmx_with_axum_backend_and_nuxt_frontend into main

florian_briand referenced this issue from a commit

2024-09-24 12:57:35 +02:00

Merge pull request 'Ajout d'un parcours utilisateur⋅ice de connexion / déconnexion' (#67) from feat/61_add_login_workflow into main