[Board] 1차 제출입니다!

build.gradle

@@ -1,6 +1,6 @@
 plugins {
     id 'java'
-    id 'org.springframework.boot' version '3.4.3'
+    id 'org.springframework.boot' version '3.3.3'
     id 'io.spring.dependency-management' version '1.1.7'
     id 'org.asciidoctor.jvm.convert' version '3.3.2'
 }
@@ -39,6 +39,15 @@ dependencies {
     testImplementation 'org.springframework.boot:spring-boot-starter-test'
     testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc'
     testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
+
+    // jwt
+    implementation 'com.auth0:java-jwt:4.2.1'
+
+    // swagger
+    implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.5.0'
+
+    // password encoder
+    implementation 'org.springframework.security:spring-security-crypto'
 }
 
 tasks.named('test') {

docs/code_review.md

@@ -0,0 +1,130 @@
+# /api 는 클래스 레벨보다는 yml로 따로 빼는 건 어떨까요?
+
+---
+## 문제점
+
+* 개발할 때는 /api 경로로 접근하지만 배포 환경에서는 /prod 경로로 접근한다고 가정한다. -> @RequestMapping("/api")를 전부 /prod로 바꿔야 한다.
+* 또한 URI.create(~~) 부분도 모두 수정해야 한다.
+
+## 해결
+
+* application.yml 파일에 경로를 미리 설정한다.
+* URI 부분은 ServletUriComponentsBuilder의 fromCurrentRequestUri() 메서드를 사용하여 해결한다. -> 해당 메서드는 현재 요청을 보내는 경로를 받아오는 기능을 제공한다. 
+
+# 에러 코드 재사용성
+
+---
+## 문제점(현재 에러 코드 구조)
+
+~~~
+public class GlobalExceptionHandler {
+    @ExceptionHandler(GlobalException.class)
+    public ResponseEntity<GlobalErrorResponse> handleException(GlobalException e) {
+    }
+}
+
+@Getter
+public enum GlobalErrorCode {
+
+}
+
+@Getter
+public class GlobalException extends RuntimeException {
+
+    private final GlobalErrorCode errorCode;
+
+    public GlobalException(GlobalErrorCode errorCode) {
+    }
+}
+~~~
+
+* 현재 이 3단계 구조로, 특정 관심사 패키지마다 exception 을 관리하고 있음
+* 이렇게 할 경우, 패키지마다 계속해서 exception 을 생성 및 관리해야함 -> 코드 재활용이 안됌.
+
+## 해결책
+
+* common 패키지에, 공통적으로 사용되는 errorCode 를 interface화 시킴.
+* 이후 interface(errorCode) 를 사용한 BaseException 클래스를 생성 -> 다른 패키지 exception 에서 BaseException 상속받아 사용할 수 있음
+* 그렇기에 exception handler 도 하나로만 관리 가능
+
+## 결론
+
+* ErrorCode 인터페이스 하나 파서 관리
+* BaseException 생성, 그리고 이 클래스를 이용한  BaseExceptionHandler 생성 -> 핸들러 하나만 사용 가능
+* MemberException, ArticleException 등등 BaseException 을 상속받아 BaseExceptionHandler 에서 에러 처리 가능
+* ErrorCode 추가될때마다 exception 을 추가할 필요가 없어짐.
+
+---
+
+# Offset Paging
+
+--- 
+## 장점
+* 구현이 쉽다 -> JPA에서 바로 Pageable 객체로 페이징 가능
+* 페이지 번호가 있는 프론트 구현 시, 잘 맞는다.
+
+## 단점
+* OFFSET 100000 같이 뒤 페이지로 갈수록 느려짐 → 인덱스가 있어도 느림 // 해당 문제는 커서 기반 페이징을 통해 해결 가능 -> offset 은 처음부터 모든 column을 조회해서 속도가 느리지만 커서 기반 페이징은 특정 id 를 기준으로 해당 부분부터 조회하기에 빠르다
+* 페이징 도중 데이터가 추가/삭제되면 순서가 뒤틀릴 수 있음 (같은 댓글이 여러 번 보이거나 사라짐)
+
+
+# ```@ManyToOne``` vs 간접참조
+
+---
+
+## @ManyToOne
+
+* 객체를 통째로 다루기 떄문에 저장이 간편하다.
+* 그렇기에 객체에 직접적으로 바로 접근이 가능하다.
+* 하지만 연관관계 이슈 때문에 객체 조회 시 N+1 문제가 발생할 수 있다.
+* 따라서 관계에 따라 접근 전략을 모색해야 한다.
+
+## 간접참조
+
+* id 값만 저장하면 된다.(단순하고 가볍게 관리 가능)
+* 따라서, id 값을 통해 조회를 또 다시 해야한다.
+* 하지만 이는 객체지향과는 조금 거리가 멀다.(객체가 아닌, 단순 id 값만 가지고 있기 때문이다.)
+
+# ORM의 탄생 배경
+
+---
+
+* ORM 은 DB를 테이블처럼 다루지 말고 객체 처럼 다루자는 목표로 등장.
+
+
+# 객체 관계에 따른 차이
+
+---
+
+## 단방향 매핑 (OneToMany or ManyToOne 한쪽만)
+
+* Comment → Article만 있는 구조 or Article -> Comment 만 있는 구조
+* 조회나 저장할 때 한쪽에서만 조작 가능
+~~~
+@Entity
+public class Comment {
+    @ManyToOne(fetch = FetchType.LAZY)
+    @JoinColumn(name = "article_id")
+    private Article article;
+}
+
+댓글을 저장할 때 어떤 게시글에 달리는지는 필요함 → Comment → Article
+하지만 Article 입장에서는 굳이 댓글들을 알고 있을 필요 없음
+~~~
+
+## 양방향 매핑
+* Article → Comment, Comment → Article 모두 존재
+* 양쪽이 서로를 참조하는 구조
+~~~
+// Article
+@OneToMany(mappedBy = "article", cascade = CascadeType.ALL)
+private List<Comment> comments;
+
+// Comment
+@ManyToOne(fetch = FetchType.LAZY)
+@JoinColumn(name = "article_id")
+private Article article;
+
+게시글 상세 페이지에서 댓글도 같이 조회하고 싶다 or 게시글 삭제 시 댓글도 자동 삭제되게 하고 싶다
+~~~
+

docs/spring_annotation.md

@@ -0,0 +1,87 @@
+## **Java Bean Validation: `@NotNull`, `@NotEmpty`, `@NotBlank` 차이점**  
+
+---
+
+### 1. @NotNull
+
+* null 값만 허용하지 않음
+* 빈 값("")과 공백(" ")은 허용됨
+
+### 2. @NotEmpty 
+
+* null 값과 빈 값("") 모두 허용되지 않음
+* 공백(" ")은 허용됨
+
+### 3. @NotBlank 
+
+* null 값, 빈 값(""), 공백(" ") 모두 허용되지 않음
+
+**회원 가입 시, @NotBlank 어노테이션 활용하는 것이 좋을 것 같음**
+
+
+## **Lombok의 생성자 어노테이션 비교 (`@AllArgsConstructor`, `@RequiredArgsConstructor`, `@NoArgsConstructor`)**
+
+---
+
+### 1. @AllArgsConstructor 
+
+* 클래스의 모든 필드를 초기화하는 생성자를 자동 생성
+* @NonNull 필드가 null이면 NullPointerException 발생
+
+### 2. @RequiredArgsConstructor 
+
+* final 필드 및 @NonNull 필드만 포함하는 생성자를 생성
+* 초기화된 final 필드는 생성자에서 제외됨
+
+### 3. @NoArgsConstructor 
+
+* 매개변수가 없는 기본 생성자를 생성
+* final 필드가 있을 경우 force = true 옵션 필요
+
+### JPA 에서 기본 생성자가 필요한 이유(protected 쓰는 이유까지)
+
+1. JPA는 데이터베이스에서 조회한 결과를 기반으로 엔티티 객체를 생성해야 합니다.
+2. Reflection을 이용하여 객체를 만들기 때문에, 기본 생성자가 반드시 필요합니다.
+3. 외부에서 기본 생성자를 직접 호출하는 것을 막기 위해 protected 사용합니다.
+3. 만약 기본 생성자가 없으면 InstantiationException 오류 발생!
+
+
+## @RequestParam vs @PathVariable 차이점
+
+---
+
+### 1. @RequestParam
+
+*  `@RequestParam`은 **쿼리 문자열**에서 값을 추출합니다. - (쿼리 파라미터)
+* 예시
+~~~
+@GetMapping("/foos")
+@ResponseBody
+public String getFooByIdUsingQueryParam(@RequestParam String id) {
+    return "ID: " + id;
+}
+~~~
+
+해당 요청을 처리하는 URL는 다음과 같습니다. - > `http://localhost:8080/spring-mvc-basics/foos?id=abc`
+
+* @RequestParam은 URL 디코딩되어 값을 추출합니다. 
+`http://localhost:8080/foos?id=ab+c` -> `ab c` 를 추출합니다. (+ 가 공백으로 디코딩 됌)
+* @RequestParam은 필터링이나 검색 조건을 전달할 때 유용합니다.
+
+### 2. @PathVariable
+
+* `@PathVariable`은 **URI 경로**에서 값을 추출합니다. - (URI 경로)
+* 예시
+~~~
+@GetMapping({"/myfoos/optional", "/myfoos/optional/{id}"})
+@ResponseBody
+public String getFooByOptionalId(@PathVariable(required = false) String id){
+    return "ID: " + id;
+}
+~~~
+
+해당 요청을 처리하는 URL 은 다음과 같습니다. -> `http://localhost:8080/spring-mvc-basics/myfoos/optional/abc`
+
+* @PathVariable은 URI 경로에서 값을 추출하기 때문에 값이 인코딩되지 않습니다.
+`http://localhost:8080/foos/id=ab+c` -> `ab+b` 값을 정확하게 추출합니다.
+* @PathVariable은 주로 리소스를 식별할 때 유용합니다.

docs/spring_cs.md

@@ -0,0 +1,23 @@
+## @Transactional(readOnly = true) 를 사용한 경우 vs 사용하지 않은 경우
+
+---
+
+### 1. @Transactional(readOnly = true)를 사용하지 않은 경우
+
+1. 트랜잭션이 시작됩니다.
+2. SELECT 쿼리를 실행하여 데이터 조회합니다.
+3. 트랜잭션이 쓰기 모드이므로 변경 감지(Dirty Checking)가 활성화됩니다.
+4. 조회한 엔티티를 영속성 컨텍스트(Persistence Context)에 저장합니다.
+5. JPA가 Book 엔티티를 관리하기 시작합니다.
+6. 트랜잭션이 종료되면, 변경된 엔티티가 있으면 UPDATE 쿼리를 실행합니다.
+7. 변경이 없어도 flush()가 호출되면서 DB와 동기화 수행합니다. → 불필요한 성능 저하 가능
+
+
+### 2. @Transactional(readOnly = true) 사용한 경우
+
+1. 트랜잭션이 시작됩니다. (READ ONLY)
+2. SELECT 쿼리를 실행하여 데이터 조회합니다.
+3. 쓰기 관련 기능(변경 감지, flush, dirty checking)이 비활성화 됩니다.
+4. JPA가 엔티티를 관리하지 않습니다. (영속성 컨텍스트 제외)
+5. 트랜잭션이 종료됩니다.
+