Réaliser un POC de l'utilisation de Jsonnet pour générer des fichiers Yaml de fixtures

[stephane-klein]

De 2018 à 2022, en suivant ma doctrine "enlever des couches", j'ai écrit mes fixtures directement en SQL (je souhaite écrire un billet à ce sujet).

Depuis mi-2023, j'écris des fichiers Yaml pour générer mes données de configurations, de fixtures ou données de démos des applications que je développe.

Après avoir créé ces fichiers, j'utilise un script écrit en Javascript pour charger ces fichiers Yaml vers PostgreSQL, comme dans cet exemple poc-sync-yaml-postgres.

Ces fichiers Yaml sont très verbeux, mais très faciles à comprendre, ils décrivent les objets à importer, de manière statique.
Aucun système de boucle, de référence…

Les liaisons entre les objets sont définies par des uuid ou nanoid.

J'éprouve une légère pénibilité à écrire et maintenir les liaisons de manière statique via des id.
Et je me pose la question si Jsonnet pourrait être une solution élégante pour générer mes fichiers Yaml sous un format un peu plus sophistiqué 🤔.

Je pourrais utiliser le système de références de Jsonnet, par exemple self pour récupérer les id vers lesquels je souhaite faire des liaisons 🤔.

Je souhaite garder les fichiers Yaml comme format intermédiaire, parce qu'ils sont simples à comprendre. Je continuerai à les versionner via Git, parce que cela me permet de facilement partager une URL vers une ressource, c'est très pratique pour communiquer de manière précise.

Question que je me pose : si je fais le bilan final, est-ce que l'ajout d'un peu de complexité avec un outil de plus dans la stack est compensé par une réelle amélioration de l'expérience de développement apportée par ce workflow ?

Le but de cette issue est :

• Publier un projet GitHub de mise en œuvre de cette méthode, sans doute basé sur poc-sync-yaml-postgres.
• Tester l'implémentation de ce système dans mon projet privé Value-Props
• Faire un bilan

[stephane-klein]

Je viens de poster https://mamot.fr/@stephane_klein/111878356793717916

[stephane-klein]

On me dit :

Au final tu auras les mêmes problématique qu'en SQL si c'est généré non ?

Ma réponse est "peut être", mais :

• le json sera sans doute un peu plus "statique" que le SQL
• le json sera sans doute un peu moins verbeux que le SQL
• il est plus facile d'écrire des données hiérarchiques en JSON qu'en SQL
• et surtout, je garde la version "statique" en YAML, qui me permet de bien comprendre à quoi ressemble les fixtures