この数日間、いくつかの個人プロジェクトを改造しました。一部は、フロントエンドとバックエンドを統合して、ノード.js内で単一のアプリケーションとして管理するようにしました。また、一部は、元々外部のデータベースをアプリケーション内に組み込むように変更しました。大まかに言えば、私が行ったことは、分離されていたシステムを統合することです。マイクロサービスとフロントエンドとバックエンドの分離が流行している現在、なぜこれを行うのでしょうか？簡単に言えば、開発とメンテナンスの便利さのためです。
以前、私も常にフロントエンドとバックエンドの分離とSOAアーキテクチャを強調していました。個人プロジェクトでも、全体の拡張性を確保するために、一部分を変更しても他の部分に影響を与えないようにするためです。そのために、フロントエンドとバックエンドを分離し、データベースを分割し、シンプルなサービスを個別に展開し、単純なプロジェクトも最小単位のモジュールに分割しました。私がやったことが間違っているとは言えませんが、十分に複雑なシステムでは、このようにすることでチームがより効果的に協力し、サービスの可用性を確保できます。
しかし、実際には、私の個人プロジェクトにとっては、このようなアプローチはむしろ多くの不必要なトラブルを引き起こします。複数のサービスの状態を同時に監視する必要があり、デプロイや開発にもより多くの時間がかかります。分離はチームの役割分担の問題を解決しましたが、全体的な作業量は実際に増加しています。個人開発者にとっては、役割分担の問題自体が存在しないため、このようなアプローチは必要ありません。
私はいくつかの小さなプロジェクトを持っています。外部のAPIを使用してデータを取得し、自分のデータベースに保存し、フロントエンドで表示するだけの単純なものです。フロントエンドとバックエンドの作業量は合わせて1000行にも満たないです。しかし、私はそれをフロントエンドとバックエンドに分けて、データベースを個別に展開しています。実際には、アクセス負荷がほとんどないこのようなアプリケーションでは、外部データベースを使用する必要は全くありません。データの永続化には関心がないからです。同様に、個人プロジェクトの場合、フロントエンドが単にバックエンドのデータのCRUD表示である場合、分離する必要はありません。ただし、バックエンドがフロントエンドの他の問題を引き起こす場合は、分離する必要があります。モノリシックなアプリケーションは、サービス間の通信のネットワーク遅延を排除することもできます。
システム全体を「圧縮」した後、プロジェクトの将来の拡張性に頭を悩ませる必要がなくなり、むしろ軽やかな気持ちになりました。一つのコマンドでプロジェクト全体をDockerイメージにパッケージ化することもできますし、または直接AppEngineにデプロイすることもできますので、後続のメンテナンスに頭を悩ませる必要はありません。将来の拡張性は、本当に必要になるまで考えずに、開発の初期段階で過度な設計をする必要はありません。