1

私は Java の世界から来て、Rails の初心者です。中規模のRails 3.2ビジネスアプリケーションを開発しました。2 番目のアプリケーションと、ユーザーがこれらにアクセスできるようにし、管理ユーザーと役割の管理を提供する「ポータル」アプリケーションを開発する時が来ました。

シングル サインオンは要件であり (ポータルに 1 回ログインすると、権限のあるアプリケーションにアクセスできるようになります)、アプリケーション間で共有する必要がある多くの基本的なドメイン モデルがあります。また、アプリケーションはほとんど同じ gem と同じ CSS を使用します。

すべてのアプリケーションは同じサーバーに常駐し、データベースを共有できます。これらのアプリに取り組んでいる開発者は 2 人いますが、一度に 1 つのアプリだけです (つまり、1 人を超えるチームはありません)。

これを設計するには、次の 3 つの方法があるようです (一般的なデータ アクセスをサービスとして公開する方法は使用しません)。

  1. (モジュールとルートを介して) 名前空間化されたモデル、コントローラー、およびビューを備えた単一のメガアプリ。単一の git リポジトリ。

  2. 共有モデル、ビュー、コントローラーを含む、ポータル用の単一の軽量マスター Rails アプリ。各ビジネス アプリは、マウント可能な Rails エンジンとして実装されます。マスター アプリと各エンジンの git リポジトリ。

  3. 共有モデル、ビュー、コントローラーを備えた単一の完全なエンジン。ポータルおよび各ビジネス アプリ用の Rails アプリ。これらはすべて完全なエンジンを参照します。エンジンには、共有 Java DAO ライブラリーのように、私が推測するすべてのモデルを含めることができます。エンジン全体と各アプリの git リポジトリ。

Java のようなアプローチは 3 であり、これが最も合理的なアプローチのようです。私が読んだことから、エンジンはマスターアプリを強化する一般的な機能(例:Devise)に使用されることを意図していたとしても、2は確かに可能です。以前に 1 つが実装されているのを見たことがありますが、ポータル + 複数の Web アプリ アーキテクチャの場合は 2 つまたは 3 つではありません。既存のアプリをエンジンに変換するのは大変ですが、可能です。

1 つのメガ アプリと 1 つのサーバーを持つことには、特定の便利さがあります。たとえば、展開が簡素化されます。ただし、アプリが独自のリポジトリになく、コードを変更するにはコードベース全体を再デプロイする必要があることを意味します。これは、小規模なアプリを 1 つのメガ アプリに結合する場合には機能するようですが、多くのモデルを共有している場合でも、大規模なビジネス アプリに拡張できるとは思えません。

記事Migrating from a single Rails app to a suite of Rails engines and Rails Engine Patterns以外に、これに関する情報はほとんどないようです。経験豊富な Rails 開発者/アーキテクトからのガイダンスをいただければ幸いです。

4

0 に答える 0