ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 프론트엔드 아키텍처의 끝 - Micro frontend in Monorepo
    카테고리 없음 2024. 5. 5. 15:07

     

    출처:https://levelup.gitconnected.com/dont-break-a-monolith-to-microservices-let-it-evolve-into-one-1cbef53a4482

     
     
    현재 재직 중인 회사의 프론트엔드 구조는 Monolithic Architecture로 각 device 환경(PC, Mobile)에 따라 각 repository로 개별 구성되어있다.

    문제점은...

    프로젝트 규모가 커질수록 구조적 한계로 인해 다음과 같은 문제가 따른다.

    • 중복 작업. 간단한 텍스트 수정이나 기능 수정 등.. 대부분의 작업이 각 레파지토리에 중복되어 코드가 쌓이게 된다. 비지니스 로직(function, hook, utils, config, etc...)은 한 공간(shared 폴더 같은)에서 관리되는게 편리하며 효율적이다.
    • CI/CD 빌드, 배포 시간 증가로 인한 개발속도 저하. 작은 일부의 소스 코드가 변경하더라도 프로젝트 전체가 배포되어야 하므로 많은 시간을 기다려야 한다. 만약 배포중 어떠한 이유로 실패라도 했다면? 또 다시 기다려야 한다..
    • High Code Coupling. 각 서비스에 독립적으로 존재하는 코드, 서비스들의 공유되는 코드(shared)의 구분이 모호해질 수 있고, 한 서비스에서 다른 서비스의 코드를 의존하게 될 수 있으며 스파게티 코드가 될 수 있다. 이러한 예측할수 없는 의존성 들은 한 서비스를 독립적으로 보기 어렵게 하고 서비스 고도화를 힘들게 한다. 또한 스파게티 코드들로 인해 다른 팀원이 시스템을 이해하는데 어려움을 줄 수 있다.
    • 협업시 어려움. 팀원들이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌성이 높고 기능 변경시 다른 팀에 영향을 줄 수 있다.
    • 유연하지 않은 확장성. 특정 서비스만 확장해야 할 경우 어플리케이션 전체를 확장해야 한다.
    • Ownership 결여. 시스템이 커지면 팀별 혹은 팀원에게 책임성을 부여하는것이 이상적이다.(ex - 결제는 A팀, 유저관리는 B팀) 하지만 monolithic 구조로는 이러한 서비스들의 경계가 모호하다.

    이러한 구조에서 프로젝트를 고도화하거나 관리해 나가는데 있어 문제성은 심각해지고 비효율적인 유지보수, 서비스 유지비용 증가, 팀 내 생산성 저하를 초래하게 된다.
    PC, Mobile device뿐 아니라 App도 개발해야 한다면 상황은 심각해진다.


    Microfrontends (multi repository)

    각 서비스별로 repository를 두게되면 각 서비스에 관련된 코드들이 한 공간에 의존성 없이 밀집해 있어 유지보수가 용이하고, 서비스 확장또한 쉬우며, 해당 서비스를 맡은 팀(혹은 개인)은 라이브러리 선택, 사용할 버전 등.. 선택에 있어 자율성을 얻게 되고 더 책임감 있게 일할 수 있으며 다른서비스와 관계없이 빠르게 배포 및 대응 할 수 있다. (더 애자일 하다)

    But...

    각 서비스에서 공통적으로 사용되는 Shared code(util, hook, config) 는 지속적으로 유지 관리가 필요한데 이 공통소스를 한 repository에 두고 npm 으로 배포하여 각 서비스에서 import 할 수 있지만, 초기 개발시 빈번한 수정이 발생하면 이 과정 또한 고통스러울 수 있다.


    Monorepo의 장점과 Microservice의 장점을 합친다면 어떻게 될까?

    Microfrontends In Monorepo

    micro frontend(service 마다 하나의 repository) 는  새로운 서비스 구축시 마다 프로젝트 셋팅을 매번 처음부터 다시 해야하고 그 관리 또한 쉽지 않다.
    monorepo의 동일한 코드 베이스에서의 공통코드 공유에 대한 장점 활용하면 micro frontends의 이점을 그대로 살리면서 약점을 보완할 수 있다.
    빠른 빌드타임, 서비스 마다의 고립화된 개별 팀 개발, 여러 repository의 관리비용 저하, 버전관리 등..

    많은 기업에서 도입중이다.
    Google, Facebook, Microsoft, Uber, Airbnb, Twitter 에서도 각 기업의 환경과 전략에 맞는 여러 큰 규모의 monorepos를 운영하고 있다.

    Tip

    monorepo with turborepo(next js)의 boilerplate plate를 활용하면 빠르게 프로젝트를 셋팅 할 수 있다.
    https://vercel.com/templates/next.js/monorepo-turborepo

    Monorepo with Turborepo – Vercel

    Learn to implement a monorepo with a single Next.js site that has installed two local packages.

    vercel.com


     Reference

    https://datamify.medium.com/monolithic-architecture-advantages-and-disadvantages-e71a603eec89

    Monolithic Architecture. Advantages and Disadvantages

    Monolithic Architecture is a traditional way of building applications. This software architecture principle has both advantages and…

    datamify.medium.com

    https://javascript-conference.com/blog/microfrontends-in-the-monorepo/

    Microfrontends in the Monorepo - International JavaScript Conference

    Great combination or a contradiction in terms? Microfrontends, each usually placed in its own repository, can find a home together in a monorepo. Monorepos simplify tasks that arise around microfrontends, but have a few intentional limitations. In order fo

    javascript-conference.com

    반응형
Designed by Tistory.