spring 2.7.6 에 맞게 제작된 프로젝트 입니다.

1. src/main/java 경로에 resources 폴더를 생성합니다.
2. 아래의 환경변수들을 셋팅해주고, [[blahblah]] 처리된 곳에는 로컬환경에 맞게 설정을 넣어줍니다.

# db config
spring.h2.console.enabled=true
spring.datasource.url=[[DB경로]];
spring.datasource.username=[[DB유저이름]]
spring.datasource.password=[[DB패스워드 없다면 생략가능]]

# jpa config
spring.jpa.hibernate.ddl-auto=update
spring.jpa.generate-ddl=true
spring.jpa.show-sql=true

# swagger config
spring.mvc.pathmatch.matching-strategy=ant_path_matcher

# env
jwt.secret.key=[[시크릿키]]

프로젝트 실행 후, 해당경로로 이동하면 문서를 보실 수 있습니다.

1. 처음 설계한 API 명세서에 변경사항이 있었나요? 변경 되었다면 어떤 점 때문 일까요? 첫 설계의 중요성에 대해 작성해 주세요!

추가된 구현사항으로 인해, 연관된 로직이 발생하면서, 매개변수 형식과 리턴타입에 수정이 있었습니다.
첫 설계 시, 이런 변경사항에 유연하게 대처 할 수 있도록 각 기능간에 의존도를 최대한 낮출 수 있는 방안으로 설계해야 함을 깨달았습니다.

2. ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?

설계도가 있으니, 그것을 기반으로 Entity를 빠르게 구축 할 수 있었습니다. 또한 그것을 기반으로 레파지토리, 서비스도 함께 구축 할 수 있었습니다.

3. JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?

아무래도 DB를 거치지 않다보니, 빠르게 유저를 검증 할 수 있다는 장점이 있었습니다.

4. 반대로 JWT를 사용한 인증/인가의 한계점은 무엇일까요?

토큰을 탈취당했을때나, 만료되었을 경우에 대한 대처가 쉽지 않았습니다. 이러한 한계점을 극복하기 위해 Access Token 과 Refresh Token을 적용하였습니다.
Refresh Token도 똑같이 서버단에서 검증을 할 수 있지만, 그렇게 되면 탈취에 대한 이슈가 동일하게 발생하기에, 어쩔수없이 세션-쿠키 방식과 유사하게 검증을 위한 DB를 생성하게 되었습니다.

5. 만약 댓글 기능이 있는 블로그에서 댓글이 달려있는 게시글을 삭제하려고 한다면 무슨 문제가 발생할까요? Database 테이블 관점에서 해결방법이 무엇일까요?

일단 댓글들과 연결되어있기 때문에, 게시글만 삭제하는 것이 불가합니다. 또한, 댓글 테이블내에서 게시글과 연관된 모든 레코드를 지우는 일이 발생합니다. 따라서 is_removed와 같은 속성을 두어, 이것만 변경하여 삭제된 게시글이라는 라벨링만 해준 뒤, 추후 서비스에 큰 영향이 없는 시간에 완전히 제거해주는 식으로 설계합니다.

6. IoC / DI 에 대해 간략하게 설명해 주세요!

IoC 란 기존에 제어의 흐름이 반대로 바뀌는 것 입니다.
즉, 기존에는 컨트롤러 -> 서비스 -> 레파지토리에 영향을 주는 형식이라, 컨트롤러가 만들어져야 서비스를 구축할 수 있고, 서비스가 구축되어야 레파지토리를 구축해야 했고, 전 단계에 대한 의존성이 높았습니다.
하지만, 모든 서비스는 엔티티와 레파지토리를 기반으로 움직이기 때문에, 먼저 레파지토리를 구축하고 그것을 서비스에서 쓰고, 잘 구축된 서비스를 컨트롤러에서 이용하는 방식으로 의존관계가 반대로 역전하여 사용하게 되었습니다. 잘 만들어진 서비스를 하위 단계가 가져다 쓰는 방식이기 때문에, 기존의 흐름과 반대로 되었다고 하여 제어의 흐름이 역전되었다고 표현하게 되었습니다.

DI는 내부에서 의존관계를 갖는것이 아니라, 외부에서 주입하여 사용하는 것을 의미합니다. 클래스 내부에서 어떤 인스턴스를 만들어사용하게 되면, 해당 클래스가 추후 다른 클래스로 변경되었을 경우, 일일히 찾으며 변경해주어야하는 번거로움이 발생한다. 이를 의존성이 생겼다고 표현하는데, 차라리 가장 부모를 인터페이스로 미리 정의해두고, 이것을 생성자를 통해 받아와 사용하는 방식으로 변경하면, 추후 클래스 변경에도 유연하게 대응할 수 있게됩니다.