2
votes

Partage de la validation ou du module d'entrée backend et frontend

Je souhaite partager la validation d'entrée parce que:

L'expérience utilisateur en frontend, indique instantanément à l'utilisateur si l'entrée est bonne / mauvaise
Problèmes de sécurité dans le backend, même si l'utilisateur contourne le javascript du frontend, un utilisateur ne peut pas jouer avec l'API RESTful
De plus, le javascript dans le frontend est toujours conditionné par le navigateur qui l'interprète et ne peut pas faire confiance

Quelle est la meilleure façon de partager la validation d'entrée dans une application Web javascript complète (frontend: react, backend: nodejs)?

La solution à laquelle je pense est de créer un module de validation avec tous mes validateurs javascript à la racine de ma base de code:

Si sur localhost, les deux environnements utilisent ce module pour valider l'entrée.
S'il est en production / pré-production, mon script de déploiement copie le module à la fois en frontend et en backend avant le déploiement.
Le code d'importation ressemblerait à ceci chaque fois que j'essaie de valider une entrée: const validator = process.env.ENV === 'local'? require ('../../ validator'): require ('/ validator')

Existe-t-il une autre méthode largement acceptée pour ce faire (je suppose que c'est un problème très courant mais je n'ai pas trouvé de problèmes similaires)? Sinon, ma méthode est-elle correcte?

javascript reactjs node.js validation

2 commentaires

Vous avez raison de vouloir valider à la fois le front-end et le back-end. La façon dont vous faites cela dépend de vous, mais votre solution pourrait fonctionner si votre validation est un module quelconque. Je dirais que vous avez besoin d'une validation différente pour FE vs BE, car vous avez des objectifs différents. FE - parcours de l'utilisateur, n'autorisant pas l'entrée qui échouera / erreur. BE - ne pas autoriser les données endommagera / endommagera le système, et FE + BE - s'assurer que les données sont `` valides '' (c'est-à-dire que le numéro de téléphone est un numéro de téléphone, etc.).

Mais partager le code serait extrêmement utile. Un utilisateur avec un navigateur à jour n'essayant pas de contourner la validation frontend obtiendrait toujours ses erreurs avant de soumettre son entrée. J'aurais donc au moins besoin d'une validation backend aussi stricte que mon frontend, puis je pourrais ajouter une validation personnalisée dans le backend. Le partager permettrait de gagner beaucoup de temps, d'éviter les doublons de code et de synchroniser les équipes backend et frontend lorsqu'elles modifient la validation des entrées. Merci d'avoir soulevé la différence intéressante entre les données valides et nuisibles

3 Réponses :

0
votes

Habituellement, vous feriez des validations simples sur le front-end et des validations plus complexes sur le backend

Par exemple: valider si e-mail avec regex sur le front-end, envoyer un simple mail pour confirmer l'existence de cet e-mail

1 commentaires

Plus complexe signifie souvent que vous pouvez au moins construire sur le simple. C'est pourquoi je voudrais dupliquer la validation frontend avec backend. Cela n'implique pas que je ne fais pas de validation personnalisée dans le backend. Le code résultant dans le backend n'est peut-être pas optimisé en suivant cette méthode, mais je recherche davantage une sécurité supplémentaire + une synchronisation frontend / backend que des performances supplémentaires ici.

1
votes

C'est une bonne pratique d'utiliser les validations en tant que module, mais vous devriez considérer ce qui se passerait si, pour une raison quelconque, vous deviez / vouliez changer la technologie back-end en quelque chose qui ne ressemble pas à Javascript.

Dans le cas où vous allez l'implémenter - vous aurez une dépendance du client et du serveur sur ce module et vous devrez maintenir différentes versions de ce module ou déployer le code client et le code serveur à chaque fois que vous aurez une validation changement - ce qui entraîne une certaine complexité que vous devez également prendre en compte.

0 commentaires

2
votes

Points à retenir des réponses et de la mise en œuvre:

La mise en œuvre fonctionne et constitue un bon moyen de tirer parti d'une application javascript fullstack
Cela crée une certaine complexité et vous devez faire attention à ne pas implémenter de bibliothèques / méthodes javascript qui ne se comporteront pas de la même manière entre deux environnements très différents (sur un navigateur client et sur un backend nodejs). Je n'utiliserai donc aucune bibliothèque tierce et uniquement du javascript vanille dans mon validateur (exemple: n'utilisez pas le mot-clé export dans mon validateur mais utilisez module.exports = {} , car l ' exportation ES6 ne fonctionnera pas dans nodejs)
Si vous souhaitez éviter les bogues en production, vous devez toujours déployer à la fois en frontend et en backend à chaque fois que vous modifiez votre module validator et testez dans les deux environnements (j'ai ajouté un script qui s'exécute avant le déploiement et vérifier les différences entre les 2 modules)
Parce que cela me fait gagner beaucoup de temps, je partage désormais également d'autres éléments de programmation fonctionnelle dans mon application
Nous avons réalisé que cette façon d'utiliser votre propre module ressemble beaucoup à l'utilisation d'un module npm à la fois en frontend et en backend (c'est juste moins encombrant que de devoir le publier sur le registre npm si vous pensez que cela sera inutile pour la communauté )

3 commentaires

Je me demandais, comment avez-vous mis en œuvre cela? Je pense faire quelque chose de similaire, mais je ne sais pas par où commencer ... Avez-vous créé un nouveau package importé à la fois par FE et BE comme import 'my-shared-module' ? Ou faites-vous simplement référence au dossier qui se trouve en dehors des deux projets?

D'après ce dont je me souviens, j'ai fait l'importation conditionnelle en fonction de mon environnement. Si je suis en local, je me réfère à un dossier en dehors du projet. Si dans prod je me suis référé directement au fichier (ils ont tous deux été copiés par un script avant le déploiement). Je ne sais pas si c'est clair, je peux préciser.

Je pense qu'il y a de meilleures façons de le faire à coup sûr