여러 개의 작은 앱으로 큰 Angular 2 앱 구성


17

React (with Redux)와 Angular 2를 선택하는 데 3 개월 간의 긴 토론과 연구 끝에 회사의 프론트 엔드 팀은 Angular 2와 함께하기로 결정했습니다 (우리의 문제에 더 적합하다고 생각되는 경우).

현재 전체 백엔드 RESTful을 보유하고있는 다양한 프런트 엔드 기술로 구성된 엔터프라이즈 앱 비즈니스에 참여하고 있으며,이를 모두 대체하고 단일 기술을 사용하여 향후 교육 및 품질 관리를보다 쉽게 ​​수행하고자했습니다.

우리 제품의 특성상 방대하며, 그 자체로 다른 도메인이며 독립형 앱으로 만들 수 있지만 제품 자체는 단일 URL에 존재하는 모듈이 있습니다.

예;

내 제품을 SuperApp이라고합니다.

UI로서 SuperApp에는 표준 로그인 시스템과 하위 모듈 / 하위 제품 탐색이있어 워크 플로가 다음과 같이 나타납니다.

  • 수퍼 앱

    • 사용자 인증
    • 비밀번호 찾기 마법사
    • 인증없이 공개 페이지에 액세스
    • 인증 된 사용자

      • 네비게이션 시스템

          • 하위 제품 1
          • 하위 제품 2
          • 하위 제품 3
        • 프로필

          ...

          ...

        • 여러 떼

          ...

          ...

위의 표현에서 그주의, Sub-product1그리고 Sub-product2완전히 다른 비즈니스 영역을 갖는 2 개 개의 완전히 다른 영역입니다.

내가 지금 생각할 수있는 것은 SuperApp 을 자신과 관련된 구성 요소와 뷰만있는 단일 Angular 2 프로젝트로 만들 수 있으며 SuperApp은 여러 하위 앱을로드하는 역할도 담당한다는 것입니다. Sub-product1, 벙어리 구성 요소를 통해 Sub-product2(다시 말하면, 다른 Angular 2 프로젝트, 자체 구성 package.json, webpack구성 등), 최상위 라우팅 및 해당 하위 앱을 보유하는 자리 표시자를 제공하는 쉘 역할을합니다.

Sub-product1셸 내에로드 되면 SuperApp이 방문한 현재 경로에 자체 경로를 추가합니다.

분리가 필요한 이유는 현재 ExtJS를 사용하여 구축 된 이러한 다양한 앱에 전용 팀이 있고 (우리는 500 명 이상의 개발자를 보유한 회사 임) 자체 Angular 프로젝트가있는 경우 툴링을 관리 할 수 ​​있기 때문입니다. 그리고 부모님의 앱에 의존하지 않고 취향에 의존합니다.

그러나 공식 Angular 문서 또는 웹에서 중첩 된 Angular 앱을 사용할 수 있는지 여부를 전혀 찾을 수 없습니다 (하위 앱의 종속성이 완전히 격리되고 앱이있는 경우에만 프레임 워크 코드가 공유되는 방식) 필요) 또는 이러한 문제를 해결하기위한 대체 방법이 있는지 여부

관련 기사에 대한 모든 안내 또는 링크도 인정됩니다.


이에 대한 해결책을 찾았습니까?
Dhaval Marthak

@DhavalMarthak 아직은 아직 아이디어가 없습니다.
Kushal

@Kushal 이것에 대한 해결책을 얻었습니까? 나는 같은 종류의 요구 사항을 가지고 있습니다
Keerthivasan

@Keerthivasan 아직 공유되지 않은 글로벌 package.json을 만든 다음 어디에서나 페이지 내에서 마이크로 응용 프로그램을 만드는 것이 좋은 대안이지만 아직 회사의 모든 프론트 엔드 개발 팀이 유지되는 경우에만 조화롭게 작동합니다. 동조. 따라서 제품이 실제로 큰 경우 이는 아키텍처 선택보다 정치적 결정입니다.
Kushal

1
microxchg 2018에서 프론트 엔드 모놀리스를 분해하는 방법에 대한 몇 가지 이야기가있었습니다. 아마도 거기에 유용한 것이있을 것입니다. youtube.com/watch?v=rCxj-ONZmxsyoutube.com/watch?v=7MHsPfoonqs
sapientpants

답변:


1

모듈 서미 에서 내가 알고있는 것 . 그래서 나는 그와 같이 언급합니다.

프레임 워크에 대한 지식이 부족하기 때문에 각도 지원 모듈에 대한 질문은 다루지 않겠습니다. 또한 제 생각에는 이것을 정말로 원하지 않습니다. 내 이해에 따르면 백엔드가 반영하기를 기대하며 모든 것을 가능한 작은 비트 ( 마이크로 서비스 ) 로 슬라이스하려고합니다 .

이 경우 다이어그램의 각 점은 자체 독립 앱이어야합니다. 그들은 당신이 묘사 한 견해를 구성하는 각 책임에 따라 반드시 서로 통신해야합니다. Google에서 인증 할 URL / 도구 / 시스템을 분리 한 방법을 보셨습니까? Gmail은 해당 cuz에 대해 신경 쓰지 않으며 책임이 아닙니다. 모든 툴의 스키닝조차도 각 툴에 위치하는 대신 중앙에 있습니다 (재료 디자인에서이 내용을 볼 수 있습니다). 자산은 각 프로젝트 / 시스템 외부에 존재합니다.

이렇게하면 시스템의 재사용 성 및 유연성이 향상됩니다. 소규모 팀에서는 복잡성과 시간으로 인해이 기능을 사용할 수 없습니다. 이제 귀하의 사례가 어디로 떨어지는 지 알아내는 것이 귀하의 임무입니다. 마이크로 서비스 및 분리, 모두 하나의 pkg 또는 중간 어딘가에 있습니다. 사용 가능한 경우 모듈은 각 점에서 사용할 것입니다.


1

하나의 옵션 : 하위 앱에 "하드 링크"(SPA 링크 대신)를 할 수 있고 각 하위 앱이 사이트 래퍼에 대한 종속성을 공유하도록 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.