답변감사합니다 ! 제가 그리고있는 아키텍쳐는 현재로선 딱히 아키텍쳐를 생각하지않아도 될 정도로 (심지어 쿠버네티스를 사용하지 않아도 될 정도의) 수준입니다. 하지만 학습용으로서 계속 production환경에 제 웹앱을 배포하면서 배포하면서 pod를 늘려나가는것입니다. 현재 서버는 1대이기때문에 이것이 마스터노드가 될 것이고, 워커노드를 위해 별도의 서버(미니컴퓨터)를 또 구비해서 활용하기엔 마스터노드가 될 서버의 사양이 거의 노트북과 맞먹어서 학습용 및 작은 앱들을 배포하는데 너무 오버스펙이라고 생각해서 혹시나 기존 서버 한대로 마스터노드, 워커노드를 이 강의의 가상화처럼 구현해도 되는지에 대한 질문이었습니다..!
답변 감사합니다. 이해가 너무 잘되었습니다. 여기에 대하여, 추가질문이있습니다. 그렇다면 Blog document만으로 Comment의 최근댓글들만 보여주면, 프론트에서 더보기를 눌렀을때 page를 0이 아닌 1로 설정을하고 불러야하겠네요. 또한 Blog의 내장 Comment 수와 Comment API의 limit과 일치시켜야하구요. API를 사용하는 클라이언트에게 API호출방식을 제대로 전달하지 못하면 휴먼에러가 발생할 확률이 높아질것같은데, 애초에 Blog, Comment Document 를 따로따로 분리한다면 Comment를 작성하는 API에서도 Blog를 처리하는 로직없이 순수 Comment만 관리할 수 있고, 위의 휴먼에러도 줄일수있을것같은데, 이러한 호출하는 방식에 대해서는 어떻게 생각하시나요?
시훈님 저도 여기에 대한 질문이 있습니다. 몽고디비는 이러한 데이터 취합/가공 접근방식이 달라요. 애초에 JOIN과 같은 populate기능 사용을 최소화합니다. 대신에 관계된(JOIN, GROUP BY 등 이런 가공이 완려된) 데이터를 통째로 하나의 문서에 저장하는거죠. 이렇게 하면 JOIN/populate를 아예 사용할 필요가 없어지고 따라서 제일 빨라집니다. 단순히 데이터를 읽어서 백엔드 넘기기만 하면되니깐요. populate를 사용하더라도 10번 populate해야할걸 1~3번만 해도 되죠. 라고 답변을 해주셨는데... 현재 강의에서 예제가 관계형데이터처럼 구조가 되어있는것같아 혼동이됩니다. 답변해주신 내용에 따르면, blog와 comment를 통째로 저장하는게 맞는것같은데, 제 인식이 다르다면 지적을 부탁드리겠습니다
답변 감사합니다 ^^ 회사에서 코틀린을 이용한 스프링부트로 프로젝트를 하고있는데, 도움이 많이 되었습니다. 덕분에 작은 서비스이지만 릴리즈까지했어요~! apply 패턴과 runCatching 패턴에 대해 더 알아보고 적용도 많이해보겠습니다 ^^ 강사님 강의 너무 좋았습니다. 빨리 다음강의가 나왔으면 좋겠네요 !! ㅎㅎ ( 이번강의에서 조금 아쉬웠던점은 테스트코드를 다 작성하지 않은 것이 조금 아쉽네요 ㅠㅠ 의도는 혼자서 공부해보라는 의도셨던것 같았지만... 인터넷강의를 보는 이유가 공부도 공부이지만, 실제 어떻게 사용되는지 보는것때문에 저는 보는편이라 .. 어렵지 않다면 다음 강의때는 전체적인 테스트코드도 한번씩 보여주시면 좋을것같습니다 ! 물론 이번 강의에서 누락된 테스트코드는 개인적으로 다 작성해보았습니다 ^^)