florian_briand
add40f32c5
### Détails Début d'implémentation de bindings pour FSV SESAM-Vitale - Création de la crates/fsv-sys - Ajout des headers des versions FSV 1.40.14 et 1.40.13 dans un sous-dossier crates/fsv-sys/vendor - Génération des bindings depuis ces headers avec bindgen - Implémentation d'une structure de loading de la librairie au runtime - Un pattern similaire au "TypeState pattern" est utilisé pour gérer plusieurs versions possibles des bindings FSV - Une macro permet de générer avec un peu moins de boilerplate que nécessaire la couche d'accès aux fonctions de la librairie ### Pourquoi ? Cette PR est une étape importante du ticket #38 Une telle sys-crate, respectant (à peu près) les bonnes pratiques d'une telle implem, permet : - Pouvoir être diffusée publiquement en tant que telle, pour faciliter le travail à des copaines - De concentrer le travail très spécifique et bas niveau de gestion des librairies et des bindings dans une crate dédiée - De ne pas "forcer" une approche "orientée" sur l'API plus haut niveau qu'on décide de brancher sur ces bindings - En effet, l'implem haut niveau fait des choix non neutres, comme le choix de certains types, la technique de gestion des erreurs, etc. ### Documentation # Aide reçue sur les forums Rust - [Génération des bindings avec Bindgen](https://users.rust-lang.org/t/how-to-handle-bindgen-generating-types-aliases-instead-of-callable-functions/118083) - [Gestion des versions multiples avec la structure de loading de la librairie](https://users.rust-lang.org/t/manage-various-versions-of-a-c-library-loaded-at-runtime/118973) # Documentations - [Making a sys-crate](https://kornel.ski/rust-sys-crate) - [LibLoading](https://docs.rs/libloading/latest/libloading/) - [Bindgen](https://rust-lang.github.io/rust-bindgen/) Reviewed-on: #70 Reviewed-by: kosssi <simon@p4pillon.org> |
||
---|---|---|
.gitea | ||
crates | ||
docs | ||
entity | ||
frontend | ||
migration | ||
scripts | ||
.env.linux.example | ||
.env.win.example | ||
.gitattributes | ||
.gitignore | ||
.ignore | ||
Cargo.lock | ||
Cargo.toml | ||
README.md |
Krys4lide
Logiciel de Pharmacie libre et open-source.
Modules applicatifs
crates
: Dossier racine des modules Rustcrates/backend
: Serveur backend propulsé par Axum, exposant une API RESTcrates/desktop
: Client desktop propulsé par Tauri, exposant lefrontend
crates/sesam-vitale
: Bibliothèque de gestion des services SESAM-Vitale (Lecture des cartes CPS et Vitale, téléservices ...)crates/utils
: Bibliothèque de fonctions utilitairescrates/fsv-sys
: Bindings Rust pour les librairies dynamiques FSV (SESAM-Vitale)
frontend
: Interface web du logiciel, propulsée par Nuxt.js
Installation
Fichiers de configuration
Certaines librairies nécessitent de définir certaines paramètres de configuration pour fonctionner correctement, en particulier le moteur SESAM-Vitale.
Ces paramètres sont définis dans un fichier de configuration .env
situé dans un des dossiers suivant (par ordre de priorité) :
- dans le dossier courant (
./.env
) - dans le dossier du manifeste (par exemple
crates/sesam-vitale/.env
) - dans le dossier de configuration standard de l'OS (par exemple, sur linux,
~/.config/krys4lide/.env
- plus d'info)
Des exemples de fichiers de configuration sont disponibles à la racine du projet : .env.linux.example
et .env.win.example
.
Development
Pré-requis
Frontend (Nuxt + Typescript)
Le frontend est propulsé par Nuxt.js, un framework TypeScript pour Vue.js. Pour le développement, il est nécessaire d'installer les dépendances suivantes :
- Bun, un gestionnaire de paquets, équivalent à
npm
en plus performant
Tauri CLI
TODO: Tauri CLI, réellement nécessaire ?
La CLI Tauri est nécessaire au lancement du client desktop
. Elle peut être installée via Cargo :
cargo install tauri-cli --version "^2.0.0-rc"
SeaORM CLI
SeaORM est notre ORM. Le CLI SeaORM est nécessaire pour la génération des modèles de la base de données et des migrations associées. Elle peut être installée via Cargo :
cargo install sea-orm-cli
L'applicatif va chercher les informations de connexion à la base de données dans la variable DATABASE_URL
importée depuis les fichiers de configuration.
DATABASE_URL=sqlite://p4pillon.sqlite?mode=rwc
Toutefois, l'usage de la CLI de SeaORM nécessite de renseigner les informations de connexion à la base de données dans un fichier .env
situé à la racine du projet.
Astuce : utilisé un lien symbolique pour éviter de dupliquer le fichier
.env
.
FSV-sys
La crate fsv-sys
nécessite la présence des librairies fournies par le package FSV et la CryptolibCPS. Les instructions d'installation sont disponibles dans le README de la crate fsv-sys
.
Backend Hot-reload
Voir le README de la crate backend
pour les prérequis de développement du serveur backend.
Lancement
Pour lancer l'application en mode développement, il est nécessaire d'exécuter plusieurs composants simultanément :
# Lancement du serveur backend
systemfd --no-pid -s http::8080 -- cargo watch -w crates/backend -x 'run --bin backend'
# Lancement de l'interface utilisateur (frontend ou desktop)
# - frontend (serveur web, accessible via navigateur)
bun run --cwd frontend/ dev
# - desktop (client desktop, basé sur Tauri)
cargo tauri dev --no-watch
Pour circonscrire les hot-reloads intempestifs mais peu utiles :
- le
backend
n'est rechargé que si des modifications sont détectées dans le dossier précisé par-w crates/backend
- le rechargement du
desktop
est désactivé par l'option--no-watch
; en effet, le rechargement dufrontend
est déjà pris en charge parbun
et ne nécessite pas de rechargement dudesktop
Build
Pour packager le client desktop
, il est nécessaire de faire appel à la CLI Tauri, qui se charge de gérer le build du frontend
et son intégration au bundle :
cargo tauri build
Gestion de la base de données
Création d'une migration
sea-orm-cli migrate generate <nom_de_la_migration>
Cette commande génère un fichier de migration à adapter dans le dossier migration/src
.
Appliquer les migrations
sea-orm-cli migrate up
Génération des entitées
sea-orm-cli generate entity -o entity/src/entities --with-serde both