search

tldr-development / go-grpc

Go와 gRPC를 GCP에서 간단하게 서비스 하기 위한 프레임워크 구성
1 stars 0 forks source link

모노레포 구조로 프로젝트 구조 #20

Closed hojin-kr closed 6 months ago

hojin-kr commented 7 months ago

모노레포 구조에 대한 참고

예시의 글은 클라이언트에 대한 내용에 대해서 중점적으로 되어 있지만, 서버 그리고 마이크로서비스 아키텍쳐에 대해서 그리고 고랭에 대해서 모노레포 구조로 프로젝트를 구성함으로써 코드 재사용성과 유사한 형태의 서비스에 대해서 적은 유지보수 비용으로 관리가 가능할 걸로 보고 진행함.

hojin-kr commented 7 months ago

서비스를 나누는 경계에 대해서도 고민이 필요한 구조

hojin-kr commented 7 months ago

공용 코드로 가져가야할 것과 서비스로 나눠져야하는것 명확하게 분리

hojin-kr commented 7 months ago

현재 구조에서는 test를 별도 디렉토리로 나누지 않고 로직과 함께 두는것이 직관성이 좋을것 같다. 

.
├── Dockerfile
├── README.md
├── gcp
│   ├── cloudstorage
│   │   └── cloudstorage.go
│   └── datastore
│       └── datastore.go
├── go.mod
├── go.sum
└── sample
    ├── proto
    │   ├── sample.pb.go
    │   ├── sample.proto
    │   └── sample_grpc.pb.go
    ├── sample.go
    ├── sample_test.go
    └── struct
        └── sample.go

7 directories, 12 files
hojin-kr commented 7 months ago

서비스를 나누는 경계에 대해서는 이번에 fiber-grpc 의 경우는 가능한 다른 어플리케이션에서 공용으로 쓸 수 있는 단위로 보면 좋을것 같다. 어플리케이션 특화된 서비스의 경우는 별개의 이야기이고 ex) Account, Profile 단위로

kaestro commented 7 months ago

모노레포라는 형태로 관리하는 것은 굉장히 훌륭한 아이디어라고 생각해. 관리하는데 어려운 부분은 있겠지만, 네가 이런 협업하는 걸 자동화하는 등의 일을 익숙하게 처리하는 거로 보여서 신뢰도 가고

여기에 제안 하나 해도 괜찮을까? struct라는 directory는 go의 struct라는 type에 종속적이라서 이러면 나중에 interface를 따로 둘 것인지에 대해서 생각해 볼 필요가 있지 않을까 해. 그러면 좀 더 추상적인 표현인 model 디렉토리 명으로 쓰는게 낫지 않을까 싶거든

별개로 나중에 workflow 수정한 것도 내가 나중에 처리할 수 있으면 진행할 때 더 용이하지 않을까 싶은데 이 부분에 대해서 가르쳐 줄 수 있을까?

이대로 올려도 LGTM이고 pull request올리면 승인할게

hojin-kr commented 7 months ago

좋아 그렇게하자,pr은 오픈되어있는거 승인해주면 머지할게