대규모 비즈니스 애플리케이션을 위한 대응 아키텍처

대규모 비즈니스 애플리케이션을 위한 대응 아키텍처

그래서 최근에는 대규모 비즈니스 웹 애플리케이션을 구축하기 위한 프런트 엔드 테크놀로지로 React를 선정했습니다.최근이라고 하는 것은, 지금까지의 리액트(Angular)에 대한 경험이 없다는 것을 의미합니다.JS)라는 큰 어플리케이션입니다.즉, 매우 크고, 매우 역동적이며, 많은 다양한 부품과 기능을 갖추고 있습니다.

매우 중요한 역할을 하고 복잡한 논리를 내장한 거대한 컴포넌트가 많이 있습니다.또, 이러한 컴포넌트를 간단하게 플러그 접속해 재사용할 수 있도록 하고 싶기 때문에, 그것들을 외부 환경이나 애플리케이션의 다른 부분으로부터 가능한 한 격리하고 싶다고 생각하고 있습니다.그렇지 않으면 크기와 복잡한 기능 때문에 개발 및 유지보수가 거의 불가능하기 때문입니다.이 때문에 최소한 초기에는 개별 컴포넌트만 개발하면서 Redx를 사용하지 않기로 결정했습니다. 컴포넌트 분리에 영향을 주고 복잡한 컴포넌트가 너무 많으면 애플리케이션 데이터 흐름 논리 전체를 이해할 수 없게 되기 때문입니다.저는 우리의 선택이 틀릴 수도 있다고 생각합니다만, 이미 말씀드렸듯이 우리는 React에 대한 경험이 없기 때문입니다.

이미 언급했듯이 어플리케이션은 매우 역동적입니다.즉, 컴포넌트는 실제로 데이터로 렌더링됩니다.API 엔드포인트와 상호 작용하는 다양한 구성 공급자 클래스를 사용하여 탐색 구성, 페이지, 다양한 형식, 목록 등 애플리케이션 구성 요소를 가져온 다음 해당 구성에서 읽은 구성 요소를 렌더링합니다.

문제는 몇 주 동안 React를 통해 모멘텀을 얻고 적절한 패턴과 일반적인 문제를 해결하기 위해 노력한 후, 우리는 팀원들과 함께 React가 우리에게 적합한 기술이 아닐 수도 있다는 것입니다. 왜냐하면 이 라이브러리는 UI 라이브러리이기 때문이지 프레임워크가 아니기 때문에 우리에게 큰 도움이 되지 않기 때문입니다.다만, 렌더링 룰을 추가해, 필요한 역학과 컴퍼넌트의 독립성을 실현하기 위해서 때때로 위반할 필요가 있습니다.

컴포넌트 분리 및 데이터 플로우 관리를 고려할 때, 각 컴포넌트가 다른 독자적인 모델을 갖는 매우 견고한 데이터 플로우 아키텍처를 가진 프런트 엔드 개발용 언어가 있다고 들었습니다만, 시도해 볼 만한 가치가 있는지는 모르겠습니다.곧 우리의 큰 요구에도 미치지 못할 수도 있기 때문입니다.

이 질문을 쓰는 이유는 대규모 프런트엔드 어플리케이션에서 작업할 수 있는 탄탄한 배경을 가진 사람들에게서 통찰력을 얻고 싶기 때문입니다.React를 사용하여 이러한 애플리케이션을 개발할 수 있는지, React가 이러한 복잡성과 역학에 적합한지, Redux 또는 다른 것이 정말 필요한지, 어떤 경로, 관행, 이데올로기를 따라야 하는지 알고 싶습니다.제 질문을 제대로 이해하셨다면 기술적인 문제라기보다는 아키텍처 측면에서 더 어려움을 겪고 있습니다.아마도 우리는 생산으로 가는 것이 아니라 점점 더 많은 어려움과 복잡함으로 이어지는 길을 걷고 있을 것입니다.

React/Redux가 귀하가 설명한 종류의 애플리케이션을 개발하는 데 사용될 수 있다는 것은 의심의 여지가 없습니다.고객님의 설명에 따르면 구축 중인 것을 구축하기 위한 플랫폼으로 React가 제외될 정도로 독특하게 만드는 것은 없습니다.우리는 React에 100+SPA(Single Page Applications)를 탑재하여 프런트 엔드 전체를 구축하고 있는 대기업 고객과 적극적으로 협력하고 있습니다.이 팀은 100명이 넘는 개발자로 구성된 팀으로, 2-3년의 프로젝트를 진행하고 있습니다.

우리가 이것을 구조화한 방법은 매우 중요했다.

먼저 UI 컴포넌트 라이브러리를 선택합니다.다음은 몇 가지 예입니다.

• 재료.UI - https://github.com/callemall/material-ui
• 리액트 스트랩 - https://github.com/reactstrap/reactstrap
• 리액트 부트스트랩 - https://github.com/react-bootstrap/react-bootstrap
• Khan Academy React Components https://github.com/Khan/react-components
• https://github.com/elementalui/elemental

컴포넌트는 커스텀 스타일이기 때문에 이들 중 하나를 선택하여 컴포넌트 라이브러리를 구축했습니다.

다음으로 모듈러 아키텍처를 구축했습니다.여기서 각 모듈(SPA)은 메인 컨테이너 컴포넌트와 레독스 스토어를 갖춘 npm 패키지입니다.

마지막으로 각 모듈이 등록되는 중앙 서버 패키지가 있습니다.서버 패키지는 인증, 인가, 로깅, 라우팅 등을 담당합니다.

이 답변의 요점은 대규모 React 어플리케이션의 구조화 방법에 대한 조언이 아니라 React를 사용하여 현재와 유사한 어플리케이션을 개발할 수 있음을 알리는 것입니다.

저도 지금 비슷한 상황이에요.대규모 데스크톱 애플리케이션(ERP, LOB - WinForms, WPF) - 1000개 이상의 모듈, 매우 동적인 모듈(UI의 70% 이상이 입력 데이터/구성에서 생성됨)에 대한 경험이 있습니다.새로운 기능을 추가하는 것은 (소스 코드를 건드리지 않고) 일부 구성을 확장하는 것이었습니다.

저는 현재 웹 기술에 대해 깊이 조사하고 있으며, React는 이에 적합하지 않다고 점점 더 확신하고 있습니다.고객(및 다른 팀원)이 모든 페이지/컴포넌트를 '수동적으로 생성'하여 하나의 글로벌 상태를 원하는 소규모/중규모 애플리케이션에서 매우 뛰어난 반응을 보입니다.단, 대규모 어플리케이션 구축에는 도움이 되지 않습니다.즉, UI 라이브러리(모듈, 라우팅, 폼, 바인딩, http 요청, 정적 타이핑(타이프 스크립트 등)만 지원되며, 놀랍게도 스타일 섀도우잉/캡슐화(예를 들어 CSS Module을 직접 통합해야 합니다)는 지원되지 않습니다.또, 최종적으로는, 라이브러리의 버젼 관리에 항상 신경을 써야 합니다(이러한 라이브러리가 항상 함께 동작하도록 하는 것은, 정말로 시간과 에너지를 소비합니다).

저는 Angular 2/4+에 대해 훌륭한 경험을 가지고 있으며, 현재로선 그러한 어플리케이션에 가장 적합한 테크놀로지라고 생각합니다(WPF를 알고 있다면 매우 유사합니다).이 프레임워크는 개봉 즉시 확장할 수 있도록 준비된 완전한 프레임워크입니다.앱을 독립된 모듈로 분할할 수 있습니다(외부에서 볼 수 있는 컴포넌트 지정).모든 컴포넌트는 퍼블릭 API(정적 타입, 입력/출력)와 캡슐화된 css 스타일(다른 컴포넌트 간의 간섭 없음).글로벌 상태(사용자 로그인, 글로벌 구성 등)의 경우 라이브러리 ngrx/store를 계속 사용할 수 있습니다(Redux 패턴을 구현하고 '효과'와 같은 추가 기능을 제공하며 Angular 에코시스템에 매우 잘 통합됩니다).

Angular에서 (백엔드 구성에서 애플리케이션 전체를 동적으로 생성하는) 정말 이상한 작업을 수행하려고 했는데 예상대로 모든 것이 완벽하게 작동했습니다.

질문에서 문제를 해결했습니다.반응은 보기 라이브러리이지 애플리케이션 프레임워크가 아닙니다.진짜 문제는 React+Redux(또는 기타 상태 관리 시스템)가 대규모 LOB 앱에 적합한지 여부입니다.

저는 이 분야에서 우리 팀의 경험에서 얻은 몇 가지 통찰력을 공유하겠습니다.대형 LOB 앱은 수십 년 동안 MVC/MVP/MVVM 설계 패턴을 사용하여 개발되어 왔습니다.이것들은 소프트웨어를 출하하는 테스트된 실제 패턴입니다.이를 의존성 주입과 결합하면 모듈화되고 테스트 가능하며 유지보수가 가능한 애플리케이션을 사용할 수 있습니다.AngularJS(2.0+)는 이러한 원칙을 기반으로 하며 이를 깊이 활용합니다.이러한 이유로 우리는 Angular를 사용한다.JS를 통해 모든 LOB(Line of Business) 애플리케이션을 지원합니다.

반면 React는 경량, 스프릴리 뷰 렌더링으로 소규모 애플리케이션 및 클라이언트 대면 작업(동적인 조사 또는 단순한 대시보드 등)에 매우 적합합니다.여기서는 보통 React와 VueJs로 눈을 돌립니다. 왜냐하면 전체 Angular는JS 스택은 너무 오버킬되어 너무 무겁습니다.

React에서 더 복잡한 앱을 쓰기 시작하는 것은 정말 힘들 수 있습니다. 저는 그 느낌을 정확히 알고 있습니다!

말씀하신 대로 React는 UI lib이며 이벤트 프레임워크가 아닙니다.그렇기 때문에 일반적으로 이벤트를 처리할 라이브러리가 필요합니다(예: Redux).Redux를 사용하지 않기로 결정했다고 명시하고 있습니다(또한 :는 대문자를 사용하지도 않았습니다).내가 너라면 한 걸음 물러서서 그 결정을 재고할 거야.Redx를 사용하지 않는 이유는 Redx를 사용할 때 컴포넌트를 쉽게 플러그에 꽂아 재사용할 수 없기 때문이라고 합니다.나는 그것이 사실이 아니라고 주장할 것이다.Redux는 React 컴포넌트에서 완전히 분리되어 있습니다.Redux는 수신 이벤트 및 상태 관리만 처리합니다.React 컴포넌트의 관점에서는 소품 데이터를 수신하고 일반 함수를 호출하여 이벤트를 전송합니다.유닛 테스트, 재사용 등을 계속할 수 있습니다.

이 점을 고려하여 Redx를 다시 검토해 보시기 바랍니다.질문이 더 있으시면 기꺼이 도와드리겠습니다!

React , Redux는 복잡한 애플리케이션의 경우 Well structured data object를 생성할 수 있기 때문에 작업을 쉽게 합니다.React와 그 머티리얼을 통해 완전한 UI를 관리할 수 있습니다.이게 왜 옳은 선택인지 몇 가지 이유가 있어

1. 상태 관리,
2. 트리 구조 데이터 처리,
3. 코드를 줄이고,
4. 변경이 이루어진 장소를 알 수 있습니다(액션, 삭감).
5. 컴포넌트는 UI 작업만 처리합니다.

필요한 것은 데이터 구조화입니다.

React와 Redux로 시작할 때의 기분을 완전히 이해하세요.우리 회사에서 React를 시작했을 때도 마찬가지였습니다.처음에 React는 다른 프레임워크와 다른 접근 방식을 가지고 있습니다.네, 물론 프레임워크가 아니라 그냥 라이브러리입니다.리액트 방식으로 생각해야 합니다.즉, 리액트 컴포넌트는 렌더링 상태(처음 그래픽 카드에 씬을 렌더링한 후 렌더링할 수 있는 것과 같습니다), 컴포넌트가 할 수 있는 일은 액션을 디스패치하거나 액션 크리에이터를 호출하는 것뿐입니다.

이 시점에서 상태를 저장하는 현명한 방법이 필요합니다. Redux를 사용하는 것이 좋습니다.

또한 React와 Redx를 조합하여 TypeScript를 사용합니다. 순수 JS보다 더 많은 코드를 작성해야 하지만 대형 프로젝트를 수행할 때는 정적 유형 제어가 매우 중요합니다.

컴포넌트의 논리를 분리하는 것은 반응의 기본 접근법입니다.로직을 분리하여 "Dummy components"라고 쓴 후 이를 Connect와 함께 재사용해야 합니다.소품으로서의 가치관을 전달하거나

Thunk 미들웨어를 액션 크리에이터로 사용하고 있습니다.연결된 컴포넌트는 메서드를 호출하고 로직은 액션 크리에이터에 있기 때문에 좋습니다.앱의 전체 상태에 액세스할 수 있으며, 그 결과 다른 액션을 디스패치할 수 있습니다.

리액트/리덕스에서 마음에 드는 것은 비동기 호출 등을 구현하는 방법입니다.모든 상태를 매핑하는 첫 번째 설계 구성요소

1) 데이터가 없는 것처럼 2) 데이터 로딩 3) 로딩 완료 4) 로딩 오류

그러기 위해서는 현재 상태에서는 세마포 1개만, 렌더 메서드에서는 몇 가지 체크가 필요합니다.다음으로 데이터를 로드하고 진척 상황을 설명하는 진척 상황 디스패치 액션을 기반으로 하는 액션 작성자 1명.

react/redux 앱에서는 단일 데이터 플로우가 제공되므로 새로운 개발 작업이 프로젝트에 착수할 때 좋습니다.

UI에서는 머티리얼 UI를 사용하고 있습니다.네, 이 프레임워크에는 몇 가지 문제가 있지만 대처할 수 없는 것은 없습니다.

앱 내 내비게이션에도 Router를 사용하고 있습니다.

처음에는 클라이언트 측 렌더링과 초기 상태로 시작하는 것이 훨씬 쉬우므로 서버 측 렌더링은 피하겠습니다.

시작할 때 이 템플릿은 모든 것이 하나의 프로젝트 JavaScript Services로 동작하는 데 도움이 되었습니다.

그럼 아브라모프 지도도 잘 되고

디자인 컴포넌트에 매우 유용한 스토리북

왜 쓰는지 안 쓰는지 오래 리액션하면 되는데... 내가 할 수 있는 말은...우리에게 좋은 선택이었고, 구걸하는 고통도 있었지만, 지금은 좋은 보답을 할 수 있게 되었다.

우리는 Reactjs를 프런트엔드 테크놀로지로 사용하여 대규모 비즈니스 애플리케이션을 시작했습니다.우리 팀에는 30명 이상의 사람들이 있고 우리 제품에는 15개 이상의 모듈이 있습니다.

이 프로젝트에 대한 저의 접근법은 애플리케이션 및 다른 모든 컴포넌트의 인증, 인가 및 라우팅만 처리하는 공통 리액트 프로젝트를 개발하는 것입니다.

https://www.npmjs.com/package/create-react-hook에서 사용하던 라이브러리를 개발하려면

이 라이브러리는 라이브러리를 테스트하는 데 사용할 수 있는 예제 앱과 함께 템플릿을 생성합니다.

프로젝트의 구조는 다음과 같습니다.

--Library 1(create-react-hook을 사용하여 개발)

--Library 2(create-react-hook을 사용하여 개발)

...

--도서관

- 공통 컨테이너 앱 (리액트 앱 작성으로 개발되어 npm install로 위의 모든 라이브러리를 사용)

이 접근방식의 주요 장점은 개발자가 npm 패키지에만 집중할 수 있고 관련 컴포넌트를 개별적으로 개발하고 테스트할 수 있다는 것입니다.또한 어플리케이션의 다른 부분에 영향을 주지 않고 테스트된 버전의 npm 패키지를 업데이트하고 컨테이너 앱을 재구축하여 전개를 수행할 수 있기 때문에 도입이 매우 쉬워집니다.

우리는 이것을 몇 달 동안 사용하고 있으며, 큰 팀과 문제없이 프로젝트를 진행하고 있습니다.저는 이것이 다른 사람에게도 도움이 될 수 있다고 생각합니다.

여러 은행에서 수년간 운영 중인 엔터프라이즈 리액션 애플리케이션 관련 경험을 공유하기 위해 이 페이지를 작성했습니다.네, 제 말 잘 들으셨어요.핀테크와 관련된 어플리케이션이 얼마나 클지 짐작할 수 있습니다(항상 그렇지는 않습니다).복잡한 로직을 가진 거대한 모듈(70+)을 보유하고 있어 은행이 필요로 하는 많은 작업을 처리할 수 있습니다.모듈은 격리되어 재사용이 가능합니다.각 모듈의 크기를 짐작할 수 있도록 1개의 모듈만 예를 제시하겠습니다.

• 카드 제작 모듈

1. 벌크 카드 생성
2. 벌크 카드 내보내기
3. 벌크 카드 요구
4. 카드 조작
5. 카드 조작 승인
6. 카드 인쇄
7. 새로운 카드 요구
8. 핀 생성
9. 핀 인쇄

이 애플리케이션은 프로젝트가 아닌 제품이며 제품으로서 구성할 수 있습니다.UI도 구성할 수 있습니다.저는 풀스택 개발자로서 이 어플리케이션에 종사해 왔습니다.꽤 오래되었기 때문에 우리가 사용하고 있는 주 관리 라이브러리는 플럭스입니다.국가경영은 발전속도가 느리지만 국가경영에 대한 걱정이 없어 단점이 있다.지금까지 이 애플리케이션은 큰 변화와 달성할 수 없는 것처럼 보이는 것들을 처리할 수 있었습니다.안정성 또한 이 기간 내내 중요한 요소였습니다.

백엔드에서는 Dot Net을 사용하여 Restful 서비스를 구축합니다.이 서비스는 클라이언트의 요구와 실현 가능성에 따라 MSQL Server와 Oracle을 모두 지원합니다.

수많은 respect.js 프로젝트를 마친 후, 저는 블로그 투고에 도메인 지향적이고 실용적인 아키텍처를 요약했습니다.

제가 여러 번 신청한 최고의 프랙티스입니다.즐겨보세요.

http://denislutz.com/domain-architecture-for-react

언급URL : https://stackoverflow.com/questions/42167555/react-architecture-for-a-huge-business-application