複数の小さなアプリを含む大きなAngular 2アプリを作成する


17

React(with Redux)とAngular 2を選択するための長い3か月にわたる議論と研究の末、私の会社のフロントエンドチームは、Angular 2を採用することを決定しました(私たちの問題により適しています)。

現在、多くの異なるフロントエンドテクノロジーで構成されているエンタープライズアプリビジネスに取り組んでいます(バックエンド全体をRESTfulにしています)。すべてを置き換えて、将来のトレーニングと品質管理を容易にする単一のテクノロジーが必要でした。

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

例;

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

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

  • SuperApp

    • ユーザーを認証する
    • パスワードを忘れたウィザード
    • 認証なしでアクセスできる公開ページ
    • 認証されたユーザー

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

        • ホーム
          • サブ製品1
          • サブ製品2
          • サブ製品3
        • プロフィール

          ...

          ...

        • グループ

          ...

          ...

上記表現にそのノート、Sub-product1そしてSub-product2全く異なるビジネスドメインを有する、2つの全く異なる領域です。

私が今考えることができるのは、自分自身に関連するコンポーネントとビューのみを持つ単一のAngular 2プロジェクトとしてSuperAppを作成でき、SuperAppは複数の子アプリのロードも担当しているということです。Sub-product1Sub-product2(自分の有する再び、異なる角度の2つのプロジェクトpackage.jsonwebpack設定、等)をダムコンポーネントを介して、トップレベルのルーティングを提供するシェルと、これらの子アプリを保持するためのプレースホルダとして機能します。

、いったんSub-product1シェル内にロードされ、それがSuperAppがで上陸したことを現在のルートに、独自のルートを追加します。

分離が必要な理由は、これらのさまざまなアプリ(現在はExtJSを使用して構築されている)が専用のチーム(私たちは500人以上の開発者を抱えている会社です)を持っているためです。グランド親アプリに依存せずに好みに依存します。

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

関連する記事へのガイダンスやリンクも歓迎します。


これに対する解決策を見つけましたか?
ダバルマルサック

@DhavalMarthakまだではありませんが、私はまだアイデアを受け入れています。
クシャル

@Kushalこれに対する解決策はありましたか?私は、要件の同じ種類持っている
Keerthivasan

@Keerthivasanはまだありませんが、良い代替案は共有グローバルpackage.jsonを作成し、ページ内であらゆる場所でマイクロアプリを実行することです。同期します。したがって、製品が本当に大きい場合、これはアーキテクチャの選択というよりも政治的な決定です。
クシャル

1
microxchg 2018でフロントエンドモノリスを分解することについていくつかの講演があり、いくつかのアプローチについて話しました。そこには何か役に立つものがあるかもしれません。参照youtube.com/watch?v=rCxj-ONZmxsyoutube.com/watch?v=7MHsPfoonqs
sapientpants

回答:


1

あなたが説明していることは、モジュールサームで知っています。だから私はそのように言及します。

フレームワークに関する知識不足のための角度サポートモジュールかどうかの問題に対処するつもりはありません。また、私の意見では、あなたは本当にこれを望んでいません。私の理解では、あなたのバックエンドが反映されることを期待しています、あなたはできる限り小さなビットにすべてをスライスしたいです(マイクロサービス)。

この場合、ダイアグラム上の各ドットは、独自の独立したアプリでなければなりません。あなたが説明したビューを作成する各責任に従って、彼らはお互いに通信しなければなりません。Googleが認証用に別のurl / tool / systemを持っている方法を見ましたか?Gmailはその責任ではないので気にしません。すべてのツールのスキンであっても、各ツールに配置されるのではなく中心です(これは材料設計で確認できます)。資産は各プロジェクト/システムの外部に存在します。

そうすることで、システムの再利用性と柔軟性をより高いレベルで実現できます。小規模なチームでは、複雑さと時間のためにこれは受け入れられません。今、あなたのケースがどこに該当するかを把握するのはあなたの仕事です。すべてマイクロサービスと分離で、すべて1つのパッケージで、または中間のどこかで。また、モジュールがある場合は、各ドット内で使用するものです。


1

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.