JwtProvider 를 Component 로 선언하신 이유가 궁금합니다.

Spring은 되게 정형화되어있는 프레임 워크라고 생각합니다. 하지만 저는 개발 스타일이 좀 더 자유로움을 추구하고 직접 구현하는것을 좋아해요 그래서 Spring을 작업 할 때 남들이 하는 형태로 작성을 많이 하지는 않습니다 ㅎㅎ 1번 항목에 대해서는 단순한 유틸리티로써 제공을 하기 위해서 사용을 하였습니다. 어차피 객체 상태에 의존적이지도 않고 순수하게 값만 받아서 처리를 하고 있기 떄문에 좀 더 직관적이라고 생각을 하였습니다. 또 굳이 빈 주입을 받지 않고 독립적으로 동작하기 떄문에 의존성도 제거하며 외부 자원을 참고하는 부분도 없다고 생각을 했던거 같습니다. 그리고 가장 중요한것은 제가 이런식의 스타일을 좋아합니다 ㅎㅎ 2번 항목에 대해서는 음 크게 생각나는 부분은 없는거 같아요. 일단 의존성이 많이 떨어진다는 장점이 있겠고, 필요에 따라서 DI 가능성도 가능한 형태가 아닌가 싶습니다. 그런데 아무래도 이러한 형태는 테스트 하기가 어렵다는 단점이 있습니다. 아무래도 static이 상태를 가지고 있지 않기 떄문에 특정 상태를 테스트하는 케이스에 대해서는 쉽지 않을 수 있으니 상황에 맞춰서 사용하시면 좋을 꺼 같습니다.어느정도 도움이 되셨을까요?? 감사합니다 :)

안녕하세요 연관관계에 대해 질문이 있습니다.

앗 그렇게 크리티컬하게 발생 가능한 형태의 데이터가 아니라서 그냥 간단하게 설명드리고 넘어갔었습니다.상황에 따라서 Hibernate에서 Lazy Loading을 마음대로 지원하지 않는것은 꽤나 복잡한 문제입니다. ㅠㅠ 질문자님께서 생각하시는 부분이 맞으실 겁니다. 아무래도 현재는 제가 Spring을 주 언어로 사용하는 환경이 아니다 보니 기억이 나지 않고 긴가민가 해서 좀 더 실제 테스트 케이스와 예시가 있는 링크를 찾아왔습니다. 해당 부분을 참고하시면 더 좋은 정보를 얻어 가실 수 있을 겁니다.https://wanbaep.tistory.com/25 강의를 듣느데에 있어서 불편함을 드린거 같아서 죄송합니다. 질문 주셔서 감사합니다 :)

안녕하세요 MySqlConfig 설정에 대해 질문이 있습니다.

좀 더 명확하게 하고자 하여 작성을 하였습니다. 제가 혼자 개발을 한다면 제가 모든 부분을 관리하고 알고있기 때문에 상관이 없겠지만 아무래도 협업을 하는것이 개발자의 역할 중 하나이기 떄문에 코드가 길어지고 중복된 함수들이 생성이 되더라도 다른 사람이 볼 때 최대한 큰 문제 없이 보고 이해 할 수 있는것이 좋다고 생각합니다. 이러한 관점에서 작성이 되었고, 큰 뜻은 없습니다. 습관적으로 작성을 한것이니 편하신대로 작업 하셔도 무방 할 꺼같습니다.감사합니다 :)

수업이랑 살짝 관계없는데 신경써주시면 좋을점입니다.

안녕하세요 강의 관련하여 말씀해 주셔서 감사합니다! 해당 강의를 촬영하면서 라이터?? 같은걸 사용하지는 않았는데 관련하여 이상한 소음이 들어간거 같습니다. 다음부터 추가적으로 확인하고 관리하도록 하겠습니다. 불편을 드려서 죄송합니다. 감사합니다 :)

MySQL을 미리 설정을 해놔야할까요?

안녕하세요 JPA에서 기본적으로 MySQL에 대한 Dependency를 입력을 하였다면 기본적인 yaml 설정과 코드를 입력해주셔야 합니다.Spring에서는 기본적은 규칙이 Dependency를 사용한다고 명시를 하였다면, 무조건 사용한다고 가정하여 코드가 동작합니다. 그러기 떄문에 Spring에서는 불필요한 Dependency를 최대한 배제하면서 사용해야 한다는 장점이면서 단점이 존재합니다.해당 부분을 고려하시며 강의 수강해 주시면 많은 도움이 되실꺼 같습니다. 추가적인 질문이 있다면 편하게 주시면 감사하겠습니다 :)

./gradlew clean build 하면 오류가 생깁니다.

사실 Java 버전에 대한 문제는 버전을 맞춰주는 방법이 가장 효과적입니다.JVM 버전을 변경을 못하시는 이유가 있으실까요?

템플릿의 대한 정보는 sesclient에 왜 넘겨주나요?

템플릿을 통해서 어떤 이메일 형태를 보낼지가 결정이 되기 떄문입니다.해당 데이터를 DB에 보관을 하셔도 되고, 그냥 소스상에서 HTML 형태로 구성을 하셔도 됩니다. 그거는 개발하시는 상황에 따라서 달라지는 부분이라 고려해보시고 편하게 적용해보시면 될 꺼 같아요.

혹시 대규모로 메일 발송을 해야할 땐 어떤 조치를 해야하나요?

음 제가 어떤 상황인지를 정확하게 인지를 하지 못해서 저는 다음과 같은 상황을 가정해보겠습니다. 대량의 메일발송이 진행이 된다면, 일부 크론잡 스케줄러를 통해서 주기적으로 원하는 대상을 인식하고 메일을 전송한다고 가정해볼게요. 그러면 일단 원하는 데이터는 긁어왔을것이고, 원하는 이메일 형식도 긁어왔다고 가정을 하겠습니다.예를들면, A라는 사용자에게는 A라는 이메일을 전송을 해야하고B라는 사용자에게는 B라는 템플릿의 이메일을 전송을 해야 합니다.이 두가지 모두 DB를 통해서 관리가 되거나, 굳이 DB 데이터가 필요가 없다면, 내부 HTML파일의 형태에서 관리를 하셔도 됩니다. 이렇게만 가져오면, 그렇게 큰 문제가 없다고 생각을 합니다. 저는 단순히 API 요청에 따라서 메일을 전송하는 형태라서 Bulk형태로써 전송을 하지는 않아서 해당 부분에 대해서 잘 모르는 부분이 있을 수 있는데 Bulk형태의 메시지를 전송하는 Method를 지원해준다면, 해당 메서드를 활용하면 되고없다면, 단순히 긁어온 데이터에 대해서 템플릿을 주입해서 사용하는 형태로 구성하시면 될 꺼 같습니다.하나씩 보내도 문제가 안되는 이유는, 일단 발생하는 부하가 내부 DB와 같은 내부 시스템이 아니고 AWS에서 발생을 하며, AWS에서는 전송하는 메일 당 비용이 부과가 될 것이기 떄문입니다.

작동하는 방법

넵넵 맞습니다. 동시에 실행시키실 필요는 없지만, 작동을 시켜보시려면 둘다 결국 필요하시니 둘다 실행시켜주시면 될 꺼같습니다.안전하게 서버 실행 이후, Clinet를 실행시키면 좀 더 편하게 실행 가능하실꺼 같아요.

Package 구성

이건 개인적인 스타일이라고 생각하셔도 됩니다.외부에 빼는 방법도 있겠지만, 저는 항상 개발할때마다 API의 경우에는 domain에서만 repository를 주로 사용을 하기 떄문에, 내부에서 관리를 하는 편입니다.