We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heart의 경우 클라우드 플랫폼의 핵심 Business들에 대한 코드들을 관리하게 될 텐데, 해당 코드들을 모두 Mono Repo 형식으로 관리를 할 것인지 여쭤보고 싶습니다.
MSA 아키텍쳐를 사용할거라면 굳이 모노레포를 채택하지 않아도 될 것 같아서 질문 던져봅니다.
The text was updated successfully, but these errors were encountered:
@8471919 맞습니다. 제 생각에도 MSA 아키텍처를 사용하려면 폴리레포를 선택하는게 맞다고 생각합니다.
모노레포를 했던 이유는 1. 기존에 순재님이 만든 레포지토리를 유지하는게 좋지 않을까.. 는 생각에 2. 사람이 많지 않고 비즈니스 로직도 별로 구현안된 상태라 서비스별로 나누면 관리차원에서 어렵다고 생각했습니다.
지금은 사람도 많아졌고 나중에 배포 파이프라인 작성할것 생각하면 레포를 나누는것도 필요하다고 생각합니다.
Sorry, something went wrong.
@8471919 저도 같은 의견입니다. 기존에는 담당자가 1,2명이었지만 인원이 늘어감에 따라 레포 나누는 게 합당할 것 같습니다
저도 폴리레포 구조가 적합하다고 생각합니다. 소수의 팀원이 각각 독립적으로 하나의 레포를 관리하고, 필요한 경우에만 조합할 수 있는 구조가 확장성과 유연성 면에서 좋다고 생각합니다.
특히 Blood가 API 게이트웨이 역할을 담당하는 것으로 이해했는데, 그렇다면 Blood의 요청 대상인 Heart를 MSA로 구성하는 것이 더 효율적일 것으로 보입니다.
예를 들어, 각 Heart 서비스마다 API 요청량이 다를 수 있으므로, 특정 Heart 서비스에 요청이 몰릴 경우 해당 서비스만 선택적으로 스케일 아웃할 수 있습니다
8471919
No branches or pull requests
Heart의 경우 클라우드 플랫폼의 핵심 Business들에 대한 코드들을 관리하게 될 텐데, 해당 코드들을 모두 Mono Repo 형식으로 관리를 할 것인지 여쭤보고 싶습니다.
MSA 아키텍쳐를 사용할거라면 굳이 모노레포를 채택하지 않아도 될 것 같아서 질문 던져봅니다.
The text was updated successfully, but these errors were encountered: