Des schémas de validation dynamiques, portables et compatibles avec Zod

[domutala]

Introduction

La validation des données joue un rôle clé dans le développement logiciel. Des formulaires frontend jusqu’aux API backend, les applications doivent s’assurer que les données reçues suivent des règles précises.

Cependant, on définit souvent les schémas de validation directement dans le code source. Cette méthode pose problème quand on doit configurer les règles de façon dynamique, les stocker en base de données ou les partager entre plusieurs applications.

L'idée est de proposer un concept qui permet de définir, stocker et reconstruire des schémas de validation compatibles avec Zod. Il ne dépend pas d'une définition écrite uniquement sous forme de code TypeScript ou JavaScript.

---

1. Une définition indépendante du code

Une définition indépendante du code signifie que la description d’un concept ou d’une règle ne dépend pas directement du code source. Elle se trouve en dehors du logiciel, par exemple dans un fichier de configuration ou de documentation. Cela permet de modifier la définition sans devoir changer le code, ce qui rend la maintenance plus simple et limite les erreurs humaines.

Le concept repose sur une représentation organisée des schémas de validation. Cette représentation s’exprime dans un format qu’on peut sérialiser, comme JSON.

On peut enregistrer une définition dans un fichier ou dans une base de données. On peut ensuite la réutiliser à différents endroits d'une application.

Par exemple, un formulaire peut se présenter sous la forme d'un tableau d'objets. Chaque objet décrit un champ et ses règles de validation.

Chaque champ possède notamment :

• Un nom qui permet de l'identifier.
• Un type de données, comme une chaîne de caractères, un nombre ou un booléen.
• Des propriétés qui indiquent si elles sont obligatoires ou optionnelles.
• Une liste de règles de validation qui s’appliquent à sa valeur.

Une définition pourrait prendre cette forme :

{
  "version": 1,
  "name": "user-registration",
  "fields": [
    {
      "name": "username",
      "type": "string",
      "required": true,
      "validators": [
        {
          "type": "min",
          "value": 3
        },
        {
          "type": "max",
          "value": 30
        }
      ]
    },
    {
      "name": "email",
      "type": "string",
      "required": true,
      "validators": [
        {
          "type": "email"
        }
      ]
    }
  ]
}

Cette représentation montre les règles de validation sans inclure de fonctions exécutables ou dépendre directement des objets internes de Zod. On peut donc la sérialiser, la transmettre, la versionner et la stocker pour longtemps.

---

2. Un système pour valider les définitions

Une définition de schéma doit d'abord être validée avant de pouvoir être utilisée.

Il faut vérifier sa structure, les types de ses propriétés, les règles disponibles et les valeurs associées à chaque règle.

En plus de cette validation structurelle, le système doit aussi vérifier si les règles sont cohérentes.

Par exemple, on ne peut pas appliquer une règle email à un champ numérique. Aussi, certaines contraintes peuvent ne pas aller ensemble ou exiger qu'on les applique dans un ordre précis.

Cette étape permet de distinguer deux niveaux de validation :

• La validation de la définition : vérifier que la configuration est bien structurée et cohérente.
• La validation des données : vérifier que les valeurs reçues respectent les contraintes fixées.

Zod peut intervenir à ces deux niveaux. Il peut valider la structure de la définition et exécuter les règles décrites par celle-ci.

---

3. De la définition au schéma Zod

Une fois que la définition est validée, on peut l'interpréter pour reconstruire un schéma Zod correspondant.

Le processus consiste à lire la définition. On construit ensuite le schéma de base de chaque champ. Puis, on applique les règles qui correspondent à son type.

Les champs sont ensuite réunis pour créer un schéma global qui décrit l'objet attendu.

Conceptuellement, le processus suit quatre étapes :

1. Charger une définition à partir d'un fichier, d'une base de données ou d'une autre source.
2. Valider et standardiser cette définition.
3. Créer les schémas Zod pour les champs et leurs contraintes.
4. Rassembler ces schémas pour obtenir un validateur exécutable.

Le résultat est un vrai schéma Zod. On peut l'utiliser avec ses fonctions de validation, de gestion des erreurs et de traitement des données.

La définition stockée est la version persistante du schéma. Le schéma Zod reconstruit est sa version exécutable.

---

4. Un même schéma pour le frontend et le backend

Avoir un schéma identique pour le frontend et le backend simplifie la communication entre les deux parties. Les développeurs peuvent travailler avec les mêmes structures de données, ce qui réduit les erreurs et les malentendus. Cela facilite aussi la maintenance du code, car les modifications apportées d’un côté sont plus faciles à répliquer de l’autre. Travailler avec un schéma commun permet donc de gagner du temps et d’améliorer la cohérence du projet.

Un des grands avantages de ce concept est qu'on peut employer une même définition dans plusieurs environnements.

Côté frontend

Une application peut charger une définition et recréer le schéma Zod correspondant pour vérifier les données d’un formulaire avant de les envoyer.

Les règles peuvent aussi venir d'une configuration que l'on peut gérer, au lieu d'être toujours écrites directement dans les composants de l'interface.

Côté backend

Le serveur peut charger la même définition. Il peut aussi reconstruire le schéma correspondant pour vérifier les données reçues par une API.

La validation sur le serveur est toujours nécessaire. Les règles mises en place dans le navigateur ne garantissent pas la sécurité.

Une source de vérité commune

Partager une même définition aide à réduire la répétition des règles entre les applications frontend et backend.

Il rend aussi la maintenance plus simple. Quand une définition change, les environnements qui l'utilisent peuvent refaire leur schéma à partir de cette nouvelle version.

Pour assurer une validation cohérente, les deux environnements doivent tout de même utiliser des versions compatibles du format de définition et du mécanisme de reconstruction.

---

5. Des schémas qui restent et qui changent

La sérialisation des définitions offre plusieurs possibilités.

Les schémas peuvent être stockés dans une base de données pour permettre la création de formulaires dynamiques. Ils peuvent aussi être enregistrés dans des fichiers pour gérer des configurations versionnées. On peut également les placer dans des services distants pour partager des règles entre plusieurs applications.

Cette approche est particulièrement intéressante pour :

• Les administrateurs peuvent configurer les formulaires.
• Les applications SaaS qui offrent des champs personnalisés pour chaque organisation.
• Les API dont les contraintes dépendent d'une configuration.
• Les systèmes qui doivent garder et réutiliser des définitions de validation.
• Les applications partagent des règles de validation entre différentes interfaces et services.

Le versionnage des définitions permet aussi de changer le format tout en gardant la possibilité de retrouver les anciennes configurations et de gérer leur compatibilité.

Il faut cependant définir clairement les règles de migration, les transformations de données et ce qu'il advient des définitions qui ne sont plus prises en charge.

---

6. Une organisation basée sur la séparation des responsabilités

Ce concept repose sur une séparation claire entre trois responsabilités :

1. La définition explique les types de données, les champs et les contraintes attendues dans un format portable.
2. La validation de la définition garantit que cette représentation est correcte dans sa structure et cohérente dans son sens.
3. La reconstruction change la définition en un schéma Zod que l’on peut exécuter.

Cette séparation permet de garder une représentation indépendante du code applicatif. Elle repose aussi sur un moteur de validation qui a déjà fait ses preuves.

Elle évite aussi la nécessité de transformer des fonctions JavaScript en chaînes de caractères, ce qui ne marche pas avec un stockage JSON simple et peut entraîner des risques d'exécution de code non fiable.

Les règles disponibles doivent donc avoir des identifiants et des paramètres que le système prend en charge de façon claire.

---

Conclusion

Définir, stocker et reconstruire des schémas de validation compatibles avec Zod permet de rendre les règles de validation faciles à utiliser ailleurs et à réutiliser.

Si on sépare la façon de représenter les règles de leur exécution, on peut garder les schémas dans des fichiers ou des bases de données. Ensuite, on peut les reconstruire dans différents environnements.

Le principe est simple. On décrit une fois les règles de validation, on les stocke sous une forme portable, puis on les reconstruit là où elles sont nécessaires.

Cette approche permet de créer des systèmes de validation dynamiques. On peut les configurer et les partager entre le frontend et le backend. Elle profite aussi des capacités de Zod pour effectuer les validations.