5 마이크로 프런트엔드를 실행하는 이유

지금까지 대다수의 사람들은 이런 미약한 일을 들어 본 적이 있다.마이크로서비스 이후, 이것은 대형 시스템의 결합을 해소하는 다음 목표인 것 같다.마이크로서비스와 마찬가지로 이것은 모든 사람에게 적용되지 않는다.
개인적으로 말하자면, 나는 마이크로 전단을 사용하기 전에, 너는 왜 그것들을 사용해야 하는지 먼저 알아야 한다고 생각한다.
분명히 마이크로 프런트엔드에는 여러 가지 해결 방안이 존재한다.나는 모든 방법이 어떤 기술에도 적용된다고 생각한다.
만약 당신이 미전단부터 흥미가 있다면check out Piral.잊지 마라⭐ 그것

1. 독립 팀

만약 네가 여러 팀에서 개발을 진행한다면, 조직 비용은 놀랄 것이다.소통은 적어도 매일 해야 한다.개발과 배치를 통제하는 데 필요한 일치성은 불가능해졌다.
마이크로 전단이 있으면 개발 자원의 확장성이 더욱 쉽게 관리될 수 있다.일반적으로 모든 기능은 독립된 팀에서 개발할 수 있다.각 팀은 필요한 정렬이 필요 없이 자체적으로 피쳐를 게시할 수 있습니다.
일부 마이크로 프론트 방법은 최소한 하나의 공유 구축 시스템이나 하나의 공공 층 (예를 들어 역방향 프록시) 이 필요하다.비록 이런 일들은 여전히 앞당겨 해결할 수 있지만, 그것들은 전체 해결 방안을 처음에 정확하게 설정할 때 더욱 복잡하게 한다.따라서 나의 건의는 초기 설정 후에 이미 유효한 해결 방안을 찾는 것이다.

2, 출시 시간 단축

마이크로 프론트의 독립성도 단일 기능의 출시 시간에 영향을 줄 수 있다.전체적으로 특징 개발에서 점점 느려지지만 미전단은 이 속도를 유지할 것이다.
물론 밑바닥 기술의 재구성과 개선도 이곳에서 이루어져야 하지만, 가능한 속도는 다음과 같은 부분으로 구성된 순환이다

신규 프로젝트 시작

개발 MVP

MVP 운송

교체 MVP(개발 및 출하)

유지 관리 모드 돌입

모든 새로운 기능이 강력하기 때문이다.최초의 기능은 몇 주에서 몇 달이 아니라 몇 분에서 며칠 안에 개발하고 출시할 수 있다.
이미 사용된 자원과 기능을 공유함으로써 출시 시간을 가속화할 수 있다.처음부터 새로운 응용 프로그램을 개발하는 것이 아니다(신분 검증, 로그 기록 등)이 모든 것은 한 공공층에서 제시해야 한다.나의 건의는 공유 구성 요소에서 이미 흔히 볼 수 있는 것을 포함하기 위해 응용 프로그램 케이스 방법을 채택하는 것이다.

3. 기능 표지

하나의 마이크로 프론트 조합(또는 봉합)을 하나의 응용 프로그램으로 하는 것은 매우 좋은 일이다.그러나 제품 소유자들은 기술 조합을 초월하기를 원한다. 그들은 모듈화를 업무 목적에도 사용하기를 원한다.
어떤 프런트엔드 기능은 일부 사용자에게만 사용할 수 있어야 합니까?내 생각엔 그래.물론 관리자 기능은 관리자에게만 사용할 수 있어야 한다.비록 앞부분은 보호층으로 사용해서는 안 되지만, 우리는 사용할 수 없는 것을 보여주고 싶지 않다.
따라서 코드에 다음을 추가합니다.

if (hasFeature('foo')) {
  // ...
}

이것은 매우 나쁜 스타일이다.우리의 코드는 현재 가장 바뀔 수 있는 것들로 가득 차 있다.foo 모두에게 적용된다면?만약 모든 사람이 이 기능을 사용하지 않는다면 어떻게 합니까?만약 내일 새로운 조건이 오랫동안 왔다면, 일부 부분을 바꾸는 것도 평가bar가 유효합니까?
우리는 이미 적당한 모듈화를 했기 때문에 특징 표시를 추가하는 것은 매우 간단하다.우리가 해야 할 일은 기능 표지를 통해 모듈의 조건을 도입하여 공급하는 것이다.그렇습니다.모듈의 기능 단계에서 코드 변경이 없고 공급층에 특성 표시와 관리를 도입하기만 하면 된다.
이런 일은 고전적인 독석에도 적용될 수 있지만, 더 많은 실현 작업이 필요하다.마이크로 전단이 있어서 구조는 이미 그것을 위해 충분한 준비를 마쳤다.나의 건의는 모든 사용자가 조건부 용량 할당을 할 수 있도록 마이크로 프런트엔드 프레임워크를 선택하는 것이다.

4. 단일 책임

비록 마이크로서비스는 모든 해결 방안이 아니지만, 그것들 자체가 제창된 것이다.그렇습니다. 많은 (심지어 대다수) 상황에서 그들은 당연히 좋은 해결 방안이지만 일반적인 상황에서 전체적이거나 다른 형식의 서비스에 대한 구조는 적어도 똑같이 좋을 수 있습니다.
그러나 백엔드에 전문적인 서비스(한 팀이 책임진다)가 있는 것은 좋은 시작이다.현재 서로 다른 마이크로 전단으로 전체를 교체하는 것은 좋은 연장이다. 왜냐하면 절단팀의 추가 차원은 여러 방면에서 사용할 수 있기 때문이다.
하나는 창고 전체에서 시작될 수도 있다.따라서 백엔드 모듈(마이크로서비스)을 담당하는 팀도 백엔드 모듈(마이크로프론트)을 책임진다.너무 좋아요.
기술적인 측면에서 볼 때 서비스와 그 전단은 틀림없이 두 가지 다른 일이지만 업무적인 측면에서 볼 때 그것들은 관련이 있고 심지어 같다.팀을 담당하는 단일한 업무 능력이나 기능을 가지는 것은 틀림없이 장점이다.
그 중 하나는 전형적인 사용자 체험이 왕왕 여러 가지 업무 기능과 관련된다는 것이다.따라서 나는 하나의 프레임워크를 사용하는 것을 권장한다. 이 프레임워크는 다른 마이크로 프론트에서 어떤 마이크로 프론트에서 온 구성 요소를 동적으로 사용할 수 있도록 한다.이러한 관계는 반드시 매우 약해야만 단독 특징 표시를 허용할 수 있다.

5. 기술의 자유

지난 2년 동안 전단 기술은 이미 상당히 안정되었다.물론 Svelte 블록을 둘러싼 기술이 있다. 예를 들어 React 다시 도전을 받을 수 있지만 솔직히 말하자면 나는 아직 어떤 우세도 확신하지 못했다.현재 단일 코드 라이브러리에서 개발하는 것은 매우 매력적이다.
개인적으로 어떤 틀의 미래에 대해 어떻게 생각하든지 간에 사실은 여러 가지 방법이 존재하고 은탄은 존재하지 않는다.따라서 우리는 서로 다른 배경을 가진 사람을 찾을 수 있을 뿐만 아니라 (네, 심지어 어떤 사람들은 발전하고 있다Angular!),그러나 다른 기술을 사용하는 기존 응용 프로그램도 포함된다.
마이크로 프런트엔드 솔루션에서 이 모든 서로 다른 응용 프로그램들이 협동하여 작업할 수 있다.Angular로 작성된 페이지는 React 마이크로프론트 구성 요소를 사용할 수 있으며, 반대로도 사용할 수 있습니다.사용자 데이터 저장 모드 대화 상자는 Vue로 작성할 수 있으며 다음 페이지는 Svelte로 작성됩니다.
일관된 사용자 환경은 어려운 문제가 됩니다.많은 문제가 생겼다.가장 중요한 것은 다음과 같습니다.

우리는 여기서 일반 CSS만 공유합니까?

행동은 어떻습니까?

웹 구성 요소가 정말 이 문제를 해결할 수 있습니까?

따라서 기술의 자유는 시종 미전단 개발의 최저 이유로 여겨져야 한다.나의 건의는 처음부터 깨끗한 방법이 있어야 하지만, 그들의 통신 전략을 포함하여 적어도 여러 개의 프레임워크를 지원하는 프레임워크를 선택해야 한다는 것이다.

결론

미전단은 은탄이 아니다.상황이 적당할 때 그들은 도움과 가치를 제공할 수 있다.만약 상술한 원인이 당신에게 모두 중요하지 않다면, 당신은 미전단 해결 방안을 필요로 하지 않을 가능성이 매우 높다.
마이크로 프런트엔드 솔루션을 사용할 경우 check out Piral 을 확인하십시오.