Cookie Parking SERVER.log - 2

이번 편은 2번째 이야기 입니다.

 

안녕하세요 !

오늘은 동아리에서 진행한 프로젝트 Cookie Parking 서비스를 제작하면서

베타 버전 기준으로 서버에 대한 기록을 목적으로 이야기를 해 나아가려고 합니다.

 

TMI지만 저는 한 동아리에 오랫동안 활동을 하면서, 다양한 경험을 해보았습니다.

처음의 모습과는 많이 다른 모습으로 현재는 블로그를 운영하고 있어요.

많은 활동을 하면서 백앤드 개발자를 목표로 공부를 하고 있고,

 

동아리의 마지막 활동으로 Cookie Parking 서비스를 제작했습니다.

 

 

" 여러분들을 보관하고 싶은 컨텐츠들을 어떻게 관리하세요? "

 

이 전에 보관하고 싶은 컨텐츠들을 카카오톡 나와의 채팅방에 저장을 해둔다던지,

크롬 북마크에 저장해두거나, Mac 메모에 저장을 해두기도 했는데요.

혹은 페이스북에서 본 좋은 글들은나에게 공유로 해서 쌓아둔 컨텐츠가 장난이 ... 아니었죠. ..

너무 많아 관리도 안되고 어떤 글이 읽은 건지 읽지 않은 건지 구별하기도 어려웠어요.

 

이 문제점은 많은 사람들이, 특히 인사이트를 찾아다니는 많은 분들이 공감하실 것 같아요.

이런 문제점들을 해결하고 기존의 서비스들을 보완한 서비스가 바로 쿠키파킹입니다.

 

 

쿠키파킹은 크롬 익스텐션으로 구성된 북마크 서비스입니다.

아래에 서비스에 대한 더 자세한 내용들이 있으니 확인해주세요 ㅎㅎ

 

Cookie Parking | Dooribun

@dooribun | Linktree

 

 

오늘은 쿠키파킹을 제작하면서 서버의 작업들을 적어볼 예정인데요.

짧은 시간이지만, 어떻게 변화했는지 어떤 기술을 왜 사용했는지 소개해보겠습니다.

 

---

 

지난 포스팅에는 서버 Architecture 와 ORM에 대해서 이야기를 나눠 보았습니다.

이번에는 레이어를 분리하면서 불편함을 겪었던 의존성 주입에 대한 이야기와

앱잼 멘토님께서 추천해주신 CQRS에 대해 이야기해보고자 합니다.

 

🍫  TypeDI

 

TypeDI 를 왜 사용하게 되었는지 알려드리자면 

코드를 적다 보니 app.ts 나 각종 파일들에서 기능을 수정을 하게 되면 다른 파일까지 수정해야 하는 점이 있었습니다.

예를 들어 datagateway를 추가할 때마다 app.ts를 수정해야 하는 점? 이 있었어요.

 

그래서 의존성 주입을 도맡아 할 수 있는 TypeDI을 도입하게 되었습니다. 

 

✔️ IoC Container 

 

짧게 이야기해보자면 로직(서비스나 객체 등 .. )을 만들 때,

로직 안에 특정 서비스를 포함하고 있으면 그 로직은 확장시키기 어렵죠.

그래서 특정 서비스를 외부에서 받아와 처리를 하는 방식을 IoC라고 합니다.

제어의 역전이라고 해서, 의존성의 방향을 바꿔버리는 거죠.

재밌는 개념이라 더 자세히 찾아보시면 더 좋을 것 같아요.

 

Inversion of Control을 위해 외부에서 객체를 생성해서 주입합니다.

IoC Container은 객체의 생성을 책임지고 관리하며, 의존성을 관리해줍니다.

 

그래서 TypeDI도 container.get()을 사용해서 주입할 객체를 가져옵니다.

TypeDI를 사용하고 난 후 더 깔끔하고 각각의 기능을 분명하게 만들어 줄 수 있었습니다.

 

 

📒 CQRS

쿠키파킹은 SOPT라는 동아리에서 앱잼이라는 3주 해커톤에서 시작한 프로젝트입니다.

해커톤의 마무리로 진행되는 데모데이 때에는 각 분야의 멘토님들을 초청해 서비스를 보고 피드백을 주십니다.

 

또, 멘토님께 질문을 할 수 있는 시간을 가질 수도 있었죠.

멘토님께서 속하신 모두싸인이라는 서비스가 AWS 활용 우수 사례로 알려진 바를 토대로 아래와 같은 질문을 했습니다.

 

 

모놀리틱에서 마이크로서비스로 전환하기에 어떤 시점이 적합다고 생각하시나요?

 

지금 생각해보니. ... 이 질문에 대한 대답을 '규모가 커질 때'라고 하신 것만 기억이 나네요 ... 

만약 이 글을 보신 분들께서 의견이 있다면 댓글 남겨주시면 감사하겠습니다.

 

데모데이 발표 때, 멘토님께서 CQRS에 대한 도입을 여쭤보셨습니다.

사실 CQRS라는 개념을 잘몰라서 친구의 도움을 받아 간신히 대답했죠 ...

 

 

✔️ CQRS ? 

Command and Query Responsibility Segregation - 명령과 조회의 책임 분리라는 의미입니다.

간단하게 설명하면 CRUD의 기능 중에 CUD와 R을 분리시킨 개념입니다.

데이터를 생성/수정/삭제하는 것과 읽기 접근을 분리 시키라는 의미이죠.

 

분리를 시켜두게 되면, Read 성능을 높일 수도 있고 독립적으로 확장시킬 수도 있습니다.

반면에, 수정된 데이터와 읽기의 어느정도의 불일치가 발생할 수 있습니다.

 

DB를 분리시켜두지는 않았지만, 현재 코드 레벨의 분리를 적용해둔 상태입니다.

멘토님 덕분에 새로운 개념을 알게되었는데, 

알아가는데 굉장히 재밌더라고요.

 

이 글을 읽는 분들도 한 번쯤 찾아보시면 재밌게 배우실 수 있는 개념이라고 생각해요.

 

아래는 참고한 내용입니다. 

docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs

CQRS 패턴 - Azure Architecture Center

 

그럼, 쿠키파킹의 서버이야기는... 여기서 마치도록 하겠습니다.