フロントエンドとバックエンド間のトランスポートとしてフラットファイルとデータベース/ APIを使用する
何人かの開発者の間でかなり白熱した議論を引き起こしたアプリケーションがあります。
基本的には、Webレイヤーとバックエンドレイヤーに分かれています。 WebレイヤーはシンプルなWebフォームによって情報を収集し、このデータをJSONドキュメント（文字通り.jsonファイル）としてバックエンドで使用される監視フォルダーに隠します。バックエンドは数秒ごとにこのフォルダーをポーリングし、ファイルを取得して、その機能を実行します。
ファイル自体は非常にシンプル（つまり、すべての文字列データ、ネストなし）で、最大で約1〜2kであり、システムはほとんどの時間アイドル状態です（ただし、常に最大100のメッセージをバーストします）。バックエンド処理ステップは、メッセージごとに約10分かかります。
ある開発者が、リレーショナルデータベース（MySQL）、noSQLデータベース（Redis）、または単純なREST APIなどの場合に、メッセージングシステムとしてファイルシステムを使用することは悪い解決策であると提案したときに議論が起こります。代わりに呼び出しを使用する必要があります。
Redisは、キューに入れられたメッセージの処理のために、組織の他の場所で使用されていることに注意してください。
私が聞いた議論は次のように分類されます
フラットファイルを支持して：
フラットファイルは、他のソリューションよりも信頼性が高くなります。ファイルは、「監視」フォルダーから取得された後、「処理」フォルダーに移動され、最後に「完了」フォルダーに移動されるためです。とにかく他のものを壊してしまうような非常に低レベルのバグを除いてメッセージが消えるリスクはゼロです。
フラットファイルを理解するには、それほど技術的な知識は必要ありません-
catだけです。書き込むクエリがなく、誤ってメッセージをキューからポップして永久に消えてしまうリスクはありません。ファイル管理コードはすべての言語の標準ライブラリの一部であるため、プログラミングの観点からはデータベースAPIよりも単純です。これにより、コードベースの全体的な複雑さと、持ち込む必要のあるサードパーティのコードの量が削減されます。
YAGNIの原則 は、フラットファイルが現在正常に機能することを示しています。より複雑なソリューションに変更する必要はないため、そのままにしておきます。
データベースを支持して：
ファイルでいっぱいのディレクトリよりもデータベースをスケーリングする方が簡単です
フラットファイルには、誰かが「完了」ファイルを「監視」ディレクトリにコピーして戻すリスクがあります。このアプリケーション（仮想マシン管理）の性質により、壊滅的なデータ損失が発生する可能性があります。
T/Sにより高度な技術を要求することは、教育を受けていないスタッフが物事を突くだけで何かを台無しにする可能性が低くなることを意味します。
特にRedisなどのDB接続コードは、少なくとも標準のライブラリファイル管理機能と同じくらい堅牢です。
DB接続コードは、ファイル操作よりもレベルが高いため、開発者の観点から見ると明らかに（機能的でない場合）単純です。
私が見ることができることから、両方の開発者には多くの有効なポイントがあります。
これらの2人のうち、pro-files devまたはpro-databases devのうち、ソフトウェアエンジニアリングのベストプラクティスと一致するものはどれですか？
Ewanが言及したデータベースまたはキューシステムを含むソリューションに切り替えると、
- バックエンドとフロントエンドの両方で新しい複雑なシステムへの依存を作成する
- 不必要な複雑さと新しい障害点の負荷を導入する
- コストの増加（所有コストを含む）
単一のボリューム内でのファイルの移動/名前変更は、ファイル/レコードのロックなどの問題に関して、現在のすべてのOSでアトミックであることが保証されています。 OSレベルの権利管理は、洗い流されていないものをロックアウトし、許可されたオペレーター（管理者/開発者）による軽率な/偶発的な誤操作を防ぐのに十分なはずです。したがって、現在のソリューションのパフォーマンスが十分である限り、データベースはまったく何も提供しません。
私たちの会社では何十年にもわたって同様のファイルベースのインターフェースを使用しており、大きな成功を収めています。他の多くのものが出たり消えたりしましたが、これらのインターフェースは完全にシンプルで信頼性があり、最小限の結合/依存関係のために残っています。
どちらの解決策も本質的に悪い習慣だとは思わないので、どちらがベストプラクティスであるか答えることは難しいかもしれません。
規模を扱っている場合は、YAGNIの原則がここに適用されるとは思いません。 「動作」は相対的であり、壊滅的なデータ損失の可能性が強く、スケーリングする能力がほとんどない場合、その動作は実際には考慮しません。あなたが扱っている規模は正確にはわかりませんが、これらのエントリが大量にある場合、新しいシステムに切り替えるのが難しくなります。そのため、これが当てはまる場合は、データベースがベストプラクティスと言えます。
MongoDBまたはredis（私はredisの経験がなく、優れたもののみを読み取ります）は、データが既に適切に収まっているはずなので正常に動作します（jsonドキュメントは、MongoDBのBSONドキュメントに簡単に変更されることがよくあります）。また、ディスクへの頻繁な読み取り/書き込みが頻繁に行われる代わりに、大量のデータがメモリに保持されるという利点もあります。また、同時読み取り/書き込みによって破損やブロックが発生しないことも確認します。
ここにYAGNIプリンシパルが適用され、ファイルがボトルネックではなく、スコープ内でスケーリングされ、壊滅的な問題がない場合、ファイルを使用することは「ベストプラクティス」と言えます。問題がなければ、何かを変更する理由はありません。いくつかのテストを記述し、それを強調して、制限とボトルネックがどこにあるかを確認します。
とにかく、データベースがこのコンテキストでの解決策であるかどうかはわかりません。同じサーバー上のものと通信している場合、ある種のIPCを実行できますが、違いますか？
ファイルを保存してそれを完了したディレクトリにコピーすることは、特に多くの通信層の主要な要素です。古いメインフレームシステムなどで。 「反」の人はポイントを持っています。それには多くの問題とEdgeのケースがあります。これは、100％の信頼性が必要な場合に対処するのが難しく、ファイルの頻度とボリュームを拡大するときに頻繁に発生します。
トランザクションの両側を制御する場合は、利用可能な多くの単純なキューイングシステムのいくつかを確認することをお勧めします。データベースではなく、ZeroMQ、RabbitMQ、MSMQなど。しかし、あなたが示唆するように、それが壊れた場合...