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, avec le système passant la plupart de son temps inactif (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, lorsque quelque chose comme une base de données relationnelle (MySQL), une base de données noSQL (Redis) ou même un appel d'API REST ordinaire 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 catcela. 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 stipule 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 éduqué 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, de ces deux personnes, le développeur pro-fichiers ou le développeur pro-bases de données, laquelle est la 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 / renommage 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. "Travailler" 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 avez affaire, 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 vos 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 d'IPC pourrait être effectuée, 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 marginaux. Qui sont difficiles à gérer si vous avez besoin d'une fiabilité à 100% et se produisent 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é ...

La solution de base de données est la bonne. Il résout beaucoup de dépendance sur un hôte particulier ou des conditions aux limites.

Les deux sont des solutions similaires, sauf que la base de données n'est pas hébergée sur un hôte particulier. Cela supprime les problèmes de pare-feu / d'accès avec le système Unix. Nous avons eu des cas de suppression "accidentelle" de systèmes de fichiers et personne à blâmer.

Avec la base de données, vous pouvez également avoir le même problème, mais vous pouvez activer l'audit ou insérer uniquement la logique pour vous débarrasser des suppressions.

Également dans le système de fichiers si vous devez mettre une application dans le nom de fichier, par exemple OASIS, vous devrez créer des fichiers OASIS.john_doe.system1.20160202. Cela devient fastidieux et peut être représenté plus facilement dans la base de données. Vous pouvez même avoir des champs nuls dans la base de données et la logique en fonction de cela

Il est également facile de mettre à jour les bases de données plutôt qu'un répertoire de fichiers complet en cas de correctifs ou de correctifs que vous pourriez vouloir faire sur les tables. Bien sûr, vous pouvez le faire sur le système de fichiers mais la mise à jour de la base de données est plus intuitive.

Par exemple, vous voulez une réexécution mais avec un système différent de celui d'OASIS, dites DESERT et john_doe à doe_smith et datez de 20160101 à 20151231

Facile à générer des lignes pour DESERT / doe_smith / 20151231 à partir de l'ensemble d'origine plutôt que de créer ces fichiers avec un script shell.

Donc, pour la lisibilité, la solution de base de données de point de vue d'extension est meilleure.