web-dev-qa-db-ja.com

大規模な構成Angular 2つのアプリに複数の小さなアプリを

3か月にわたるReact(Redux付き)とAngular 2のどちらかを選択するための討論と調査の結果、会社のフロントエンドチームはAngular 2(それが問題に適しています)。

私たちは現在、さまざまなフロントエンドテクノロジーで構成されている(バックエンド全体がRESTfulである)エンタープライズアプリビジネスに参入しており、それをすべて置き換え、単一のテクノロジーで将来のトレーニングと品質管理を容易にすることを望んでいました。

私たちの製品の性質を考えると、それは広大で、その中にモジュールがあり、それ自体は異なるドメインであり、スタンドアロンアプリとして作成できますが、製品自体は単一のURLに存在します。

例;

私の製品をSuperAppと呼びましょう。

SuperAppはUIとして、標準のログインシステムと、子モジュール/サブ製品へのナビゲーションを備えており、ワークフローは次のようになります。

  • SuperApp

    • ユーザーの認証
    • パスワードを忘れるウィザード
    • 認証なしでアクセス可能なパブリックページ
    • 認証済みユーザー

      • ナビゲーションシステム

        • ホーム
          • サブプロダクト1
          • サブプロダクト2
          • サブプロダクト3
        • プロフィール

          ...

          ...

        • 団体

          ...

          ...

上記の表現では、Sub-product1Sub-product2は2つのまったく異なる領域であり、まったく異なるビジネスドメインを持っていることに注意してください。

私が今考えることができるのは、それ自体に関連するコンポーネントとビューのみを持つ単一のAngular 2プロジェクトとしてSuperAppを作成できることです。SuperAppは、複数の子アプリ; Sub-product1Sub-product2(繰り返しますが、独自のpackage.jsonwebpack configなどを持つ、異なるAngular 2プロジェクト)がdumb-componentsを介してトップレベルのルーティングとそれらの子アプリを保持するためのプレースホルダーを提供するシェルとして。

Sub-product1がシェル内に読み込まれると、独自のルートがSuperAppが到達した現在のルートに追加されます。

私が分離を望んでいる理由は、これらのさまざまなアプリ(現在ExtJSを使用して構築されています)には専用のチーム(私たちは500人以上の開発者がいる会社です)がいるため、独自のAngularプロジェクトがある場合、祖父母のアプリに依存することなく、ツールや依存関係を好みに応じて管理できます。

しかし、公式のAngularドキュメント、またはWeb上で、ネストされたAngularアプリが存在するかどうかはまったくわかりません(子アプリの依存関係でフレームワークコードが共有されるような方法で)アプリがそれを必要とする場合にのみ完全に分離されて読み込まれます)、またはそのような問題を解決するための代替アプローチがあるかどうか。

任意のガイダンスまたは関連する記事へのリンクも高く評価されます。

17
Kushal

1つのオプション:サブアプリに(SPAリンクを使用する代わりに)「ハードリンク」し、各サブアプリにサイトラッパーの依存関係を共有させることができます。

1
jchook

あなたが説明していることはmodule thermで知っています。だから私はそういうものとして言及します。

angularサポートモジュールがフレームワークに関する知識の欠如に対応しているかどうかの質問には触れません。また、私の意見では、これはあまり望んでいません。私の理解では、そして、私はあなたのバックエンドが反映することを期待しています、あなたはすべてをあなたができる最小のビットにスライスしたいです(マイクロサービス)。

この場合、ダイアグラムの各ドットは独自の独立したアプリでなければなりません。あなたが説明した見解を構成するそれぞれの責任に応じて、彼らは互いにコミュニケーションをとる必要があります。 Googleがどのようにurl/tool/systemを認証するために分離しているかを見ましたか? Gmailはその責任を負いません。すべてのツールのスキンは、各ツールに配置されるのではなく、中心的です(これはマテリアルデザインで確認できます)。アセットは各プロジェクト/システムの外部にあります。

そうすることで、システムの再利用性と柔軟性をさらに高めることができます。小さなチームではこれは複雑さと時間のために受け入れられません。今あなたのケースがどこに落ちるかを理解するのはあなたの仕事です。すべてマイクロサービスと分離で、すべて1つのパッケージで、または中間のどこかで。そして、もし可能であれば、モジュールは各ドットの内側で使用するものです。

1
CesarScur