Utilisation de fichiers plats vs base de données / API comme transport entre un frontend et un backend
J'ai une application qui a généré une discussion plutôt animée entre quelques développeurs.
Fondamentalement, il est divisé en une couche Web et une couche principale. La couche Web collecte des informations par un simple formulaire Web, stocke ces données sous forme de document JSON (littéralement un fichier .json) dans un dossier de surveillance utilisé par le serveur principal. Le serveur principal interroge ce dossier toutes les quelques secondes, récupère le fichier et exécute ses fonctions.
Les fichiers eux-mêmes sont très simples (c'est-à-dire toutes les données de chaîne, pas d'imbrication), et environ 1-2k au plus grand, le système passant la plupart de son temps au repos (mais éclatant jusqu'à 100 messages à tout moment). L'étape de traitement du backend prend environ 10 minutes par message.
L'argument survient lorsqu'un développeur suggère que l'utilisation du système de fichiers comme couche de messagerie est une mauvaise solution, quand quelque chose comme une base de données relationnelle (MySQL), une base de données noSQL (Redis) ou même un simple appel d'API REST devrait être utilisé à la place.
Il convient de noter que Redis est utilisé ailleurs dans l'organisation pour la gestion des messages en file d'attente.
Les arguments que j'ai entendus se décomposent comme suit
En faveur des fichiers plats:
Les fichiers plats sont plus fiables que toute autre solution, car le fichier n'est déplacé d'un dossier "watch" vers un dossier "processing" qu'après avoir été récupéré, et finalement vers un dossier "done" une fois terminé. Il n'y a aucun risque de disparition des messages, à moins de bogues de très bas niveau qui pourraient de toute façon casser d'autres choses.
Les fichiers plats nécessitent moins de sophistication technique pour comprendre - juste
cat. Aucune requête à écrire, aucun risque de sauter accidentellement un message de la file d'attente et de le faire disparaître pour toujours.Le code de gestion de fichiers est plus simple que les API de base de données du point de vue de la programmation, car il fait partie de la bibliothèque standard de chaque langue. Cela réduit la complexité globale de la base de code et la quantité de code tiers qui doit être introduit.
Le principe YAGNI indique que les fichiers plats fonctionnent très bien en ce moment, il n'est pas nécessaire de passer à une solution plus compliquée, alors laissez-le.
En faveur d'une base de données:
Il est plus facile de faire évoluer une base de données qu'un répertoire plein de fichiers
Les fichiers plats présentent un risque que quelqu'un recopie un fichier "terminé" dans le répertoire "watch". En raison de la nature de cette application (gestion de machine virtuelle), cela pourrait entraîner une perte de données catastrophique.
Exigeant plus de sophistication technique pour T/S, l'application signifie que le personnel non instruit est moins susceptible de gâcher quelque chose en se contentant de pousser les choses.
Le code de connexion DB, en particulier pour quelque chose comme Redis, est au moins aussi robuste que les fonctions de gestion de fichiers de bibliothèque standard.
Le code de connexion DB est visiblement (sinon fonctionnellement) plus simple du point de vue du développeur, car il est plus élevé que la manipulation de fichiers.
D'après ce que je peux voir, les deux développeurs ont beaucoup de points valides.
Donc, parmi ces deux personnes, le développeur pro-files ou le développeur pro-database, lequel est le plus conforme aux meilleures pratiques en génie logiciel, et pourquoi?
Passer à une solution impliquant des bases de données ou les systèmes de files d'attente mentionnés par Ewan
- créer une dépendance à l'égard d'un nouveau système complexe à la fois en backend et en frontend
- introduire une complexité inutile et une multitude de nouveaux points de défaillance
- augmenter le coût (y compris le coût de possession)
Le déplacement/changement de nom de fichiers dans un seul volume est garanti atomique sur tous les systèmes d'exploitation actuels, quelles que soient leurs difficultés en ce qui concerne des choses comme le verrouillage de fichiers/enregistrements. La gestion des droits au niveau du système d'exploitation devrait être suffisante pour bloquer le non lavé et pour empêcher une mauvaise manipulation irréfléchie/accidentelle de la part des opérateurs autorisés (administrateurs/développeurs). Les bases de données n'ont donc rien à offrir tant que les performances de la solution actuelle sont à la hauteur.
Dans notre entreprise, nous utilisons des interfaces similaires basées sur des fichiers depuis des décennies avec beaucoup de succès. Beaucoup d'autres choses sont venues et ont disparu, mais ces interfaces sont restées en raison de leur simplicité, fiabilité et couplage/dépendances minimes.
Je ne pense pas que l'une ou l'autre solution soit par nature une mauvaise pratique, donc répondre à la meilleure pratique peut être difficile.
Je ne crois pas que le principe YAGNI s'applique ici si vous avez affaire à l'échelle. Le "travail" est relatif, si vous avez un fort potentiel de perte de données catastrophique et peu de capacité de mise à l'échelle, je ne considérerais pas vraiment cela comme un travail. Je ne suis pas exactement sûr de l'échelle à laquelle vous faites face, mais si vous avez une quantité massive de ces entrées, il devient plus difficile avec chacune de passer à un nouveau système. Donc, si c'est le cas, je dirais qu'une base de données est la meilleure pratique.
MongoDB ou redis (je n'ai aucune expérience avec redis, ne lisez que les bonnes choses) devraient bien fonctionner car vos données devraient déjà bien y entrer (les documents json sont souvent changés trivialement en documents BSON pour MongoDB). Il présente également l'avantage supplémentaire de conserver un grand nombre de données en mémoire au lieu de fréquentes lectures/écritures fréquentes sur le disque. Il s'assure également que les lectures/écritures simultanées ne conduisent pas à la corruption ou au blocage.
Si le principal YAGNI s'applique ici et que les fichiers ne sont pas un goulot d'étranglement, ils évoluent dans la portée et n'ont pas de problèmes catastrophiques, je dirais que s'en tenir aux fichiers est une "meilleure pratique". Il n'y a aucune raison de changer quoi que ce soit s'il n'y a pas de problèmes, peut-être écrire des tests, le souligner et voir où sont vos limites et goulots d'étranglement.
Je ne sais pas si une base de données est de toute façon la solution dans ce contexte. Si vous communiquez avec des choses sur le même serveur, une sorte de IPC pourrait être fait, non?
Alors que le bon 'ol enregistre un fichier et le copie dans un répertoire fait est un aliment de base de nombreuses couches de communication en particulier. avec des systèmes de châssis principal plus anciens et similaires. Les gars "anti" ont un point; en ce qu'il présente de nombreux problèmes et cas Edge. Ce qui est difficile à gérer si vous avez besoin d'une fiabilité à 100% et se produit plus souvent lorsque vous augmentez la fréquence et le volume des fichiers.
Si vous contrôlez les deux côtés de la transaction, je vous suggère de regarder certains des nombreux systèmes de mise en file d'attente simples disponibles. ZeroMQ, RabbitMQ, MSMQ etc. plutôt qu'une base de données. Mais comme vous le laissez entendre, si ce n'est pas cassé ...