## Transaction

`Transaction`이란 데이터베이스에서 상태를 변화시키기 위해 수행하는 작업의 단위를 뜻합니다. 
크게 4가지 특징이 있고 이를 ACID라 합니다.1

1.	원자성(Atomicity)

트랜잭션에서 정의된 연산들은 모두 성공적으로 실행되던지 아니면 전혀 실행되지 않아야 합니다.

2.	일관성(Consistency)

트랜잭션이 실행 되기 전의 데이터베이스 내용이 잘못 되어 있지 않다면 트랜잭션이 실행된 이후에도 데이터베이스의 내용에 잘못이 이쓰면 안됩니다.

3.	독립성(Isolation)

트랜잭션이 실행되는 도중에 다른 트랜잭션의 영향을 받아 잘못된 결과를 만들어서는 안됩니다.

4.	지속성(Durability)

트랜잭션이 성공적으로 수행되면 그 트랜잭션이 갱신한 데이터베이스의 내용은 영구적으로 저장됩니다.

## Transactional 어노테이션

Spring에서는 `@Transactional` 어노테이션을 사용해서 선언적 트랜잭션을 사용합니다. 
서비스의 한 메서드를 Transaction 단위로 만들어 주는 역할을 합니다. 
위에서 설명한 트랜잭션의 4가지 특징을 서비스에서 보장해줍니다. 
선언하는 방법은 메서드에 선언하거나, 서비스에 선언을 합니다. 
서비스에 선언을 할 경우 서비스 내의 메서드들이 전부 영향을 받게 됩니다.

-	롤백

트랜잭션의 원자성 특징으로 연산들은 모두 실행되던지 혹은 전혀 실행되지 않아야 합니다. 
따라서 서비스에서 Exception이 발생할 경우에 결과가 commit되지 않고 모두 rollback 됩니다.

```java
@Service
@RequiredArgsConstructor
public class TransactionService {

	private final UserRepository userRepository;

	@Transactional
	public void transactionTest(Long id) throws Exception {
		User user = userRepository.findById(id).orElseThrow();
		userRepository.delete(user);
		throw new Exception("익셉션 발생");
	}

}
```

위의 예시에서 user 엔티티를 삭제하여서 delete 문을 통해 데이터가 삭제되어야 하지만, `Exception`이 발생하게 되면 삭제되지 않게 됩니다.

### 주의할 점

```java
@Service
@RequiredArgsConstructor
public class TransactionService {

	private final UserRepository userRepository;

	public void transactionParent(Long id) {
		transactionChild(id);
	}

	@Transactional
	public void transactionChild(Long id) throws Exception {
		User user = userRepository.findById(id).orElseThrow();
		userRepository.delete(user);
		throw new Exception("익셉션 발생");
	}
}
```

위의 코드가 실행되면 어떻게 동작할까요? 
`@Transactional`의 동작에 의해서는 user가 delete되지 않고 rollback되어야 정상입니다. 
하지만 위의 코드가 실행된다면 rollback이 되지 않고 user가 삭제됩니다. 
그 이유는 `@Transactional` 어노테이션은 Proxy 방식으로 동작하기 때문입니다. 
Spring은 proxy로 접근해서 기존 코드를 가로채 앞 뒤로 transaction을 처리하는 코드를 생성해줍니다.

```java
@Service
public class TransactionService {
	
	@Transactional
	public void test() {
		...
	}
}
```

위의 코드가 있다면 실제로 동작하는건 프록시로부터 아래의 코드처럼 동작합니다.

```java
public class TransactionProxy {
	private final TransactionManager manager = TransactionManager.getInstance();

	public void transactionLogic() {
		try {
			manager.begin(); // 트랜잭션 전처리
			est(); // 코드 동작
			manager.commit();
		} catch (Exception e) {
			manager.rollback();
		}
	}
}
```

그런데 이 Proxy모드는 오직 외부로부터의 method 호출이 발생한 경우에만 인터셉트 되어서 트랜잭션 관리가 가능해집니다. 
그렇기 때문에 내부에서 호출할 경우에는 해당 메서드의 `@Transactional`이 적용되지 않으니 유의하면서 코드를 작성해야 합니다.

### readOnly 옵션

`readOnly`옵션은 Transaction내에서 조회를 하겠다고 선언하는 옵션입니다. 
이 옵션을 사용해야하나? 라 하면 사용하는 것이 좋다. 입니다. 
첫번째로는 readOnly옵션이 있을 경우 영속성 컨텍스트가 엔티티를 관리하지 않게 됩니다. 
즉 1차캐시에 스냅샷을 만들어 두지 않기 때문에 단순 조회만 사용할 경우에 성능이 올라가게 됩니다. 
두번째로는 혹시모를 데이터 변경을 방지할 수 있습니다. 
만약 업데이트문을 사용하지 않을것인데 엔티티의 내용이 변경되거나 return이 된다면 데이터 변경이 일어날수도 있는데,(물론 이미 잘못 설계된 코드입니다.) 이를 방지하여 줍니다. 
세번째로는 선언만으로 직관적으로 조회 서비스인걸 알 수 있습니다. 
CUD 로직이 없음을 알기에 알아보기 쉬워지고 신뢰성이 보장됩니다. 
네번째로는 MySql을 사용할 경우에는 읽기 전용으로 master가 아닌 slave를 호출해서 DB 서버의 부하를 줄여줍니다. 
이러한 이유들로 단순 조회쿼리를 사용할 경우에도 readOnly 옵션을 사용하는 것이 좋습니다.

```java
@Service
@RequiredArgsConstructor
public class TransactionService {
	private final UserRepository userRepository;

	@Transactional(readOnly = true)
	public UserDto getUserStatus(Long id) {
		User user = userRepository.findById(id).orElseThrow();
		return user.toDto();
	}
}
```

Spring에서 제공하는 Transactional 어노테이션의 역할 및 사용법

Transactional 어노테이션

## 더티 체킹

더티 체킹(Dirty Checking)이란 상태 변경을 감지한다는 의미입니다. 
JPA에서 엔티티를 다룰 때 한 엔티티의 변경이 일어나면, 그 변경을 감지하여서 자동으로 Update를 데이터베이스에 반영하여 줍니다. 
JPA Repository에는 Update를 위한 메서드가 따로 존재하지 않는데, 이는 더티 체킹을 통해 업데이트를 하는것이 일반적이기 때문입니다.

-	더티 체킹 범위

더티 체킹은 한 Transaction 내부에서만 이뤄지는데, Transaction은 `EntityManager`를 이용해 Transaction을 생성하여 이용하거나, JPA Data에서는 `@Transactional` 어노테이션을 이용해 생성합니다. 
영속성 컨텍스트는 Entity를 보관할 때 최초의 상태를 저장하는데 이를 스냅샷이라고 합니다. 
영속성 컨텍스트가 Flush되는 시점에 스냅샷과 현재의 엔티티를 비교해 상태가 달라진 Entity를 찾아 Update 쿼리를 생성하여 줍니다. 
영속성 컨텍스트가 Flush 되는 시점은 1. `Transaction commit` 2. `EntityManager flush` 3. `@Modify(flushAutomatically = true)`가 있습니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService {
	private final EntityManagerFactory entityManagerFactory;

public void dirtyCheckEntityManager(Long id, String nickName) {
	EntityManager em = entityManagerFactory.createEntityManager();
	EntityTransaction transaction = em.getTransaction();
	transaction.begin(); // 트랜잭션 시작
	User user = em.find(User.class, id);
	user.changeNickName(nickName); // 엔티티 변경
	transaction.commit();
}
}
```

위의 예시는 EntityNabager를 이용해 transaction을 생성하고 그 안에서 Entity를 조회하고, 그 값을 변경하였습니다. 
Transaction내에서 User 엔티티가 조회된 순간에 EntityManager가 관리를 시작하고, 해당 엔티티의 변경을 감지하고, `transaction.commit();` 으로 감지된 변경사항을 Update문을 통해 변경합니다. 
직접 Update문과 관련된 메서드나 쿼리를 작성하지 않아도 자동으로 Update가 이뤄집니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService {
	private final UserRepository userRepository;

	@Transactional
	public void dirtyCheckTransactional(Long id, String nickName) {
		User user = UserRepository.findById(id).get();
		user.changeNickName(nickName);
	}
}
```

JPA Data에서는 `@Transactional` 어노테이션을 통해 자동으로 트랜잭션 관리를 합니다. 
해당 메서드 안에서 User엔티티를 조회하고, 그 순간 EntityManager에서 엔티티를 관리합니다. 
이후 메서드가 끝날 때 변경을 감지하고 Update 쿼리를 사용합니다. 
당연히도 위의 코드에서 `@Transactional 어노테이션을 제외하면 엔티티의 nickName값은 변하지만 DB에는 영향을 주지 않습니다.

-	더티 체킹 대상

더티 체킹은 모든 엔티티를 대상으로 하진 않습니다. 
영속성 컨텍스트가 관리하는 엔티티들만 대상으로 더티 체킹을 하는데, `detach`된 엔티티(준영속)나 DBㅔ 반영되기 전 새로운 엔티티(비영속)를 대상으로는 더티 체킹을 하지 않습니다.

```java
@Service
@RequiredArgsConstructor
public class DirtyCheckService{
	private final UserRepository userRepository;

	@Transactional
	public void dirtyCheckTest(Long id, Long id2, String nickName) {
		User user = userRepository.findById(id).get(); // 조회를 통해 영속된 Entity
		User user2 = User.builder().nickName(nickName); // 비영속 상태인 새로운 Entity
		user2.changeNickName(nickName + "11"); // Dirty Check를 수행하지 않아 변경점이 DB에 저장되지 않음
		User user3 = userRepository.findById(id2);
		User user4 = userRepository.save(user3); // save를 통해 eturn 받는 Entity는 영속이 됨. 반대로 기존의 Entity는 detach 상태가 됨.
 user3.changeNickName(nickName + "22"); // 준영속상태이기에 Dirty Check를 수행하지 않음
 user4.changeNickName(nickName + "33"); // 영속 상태이기 때문에 Dirty Check를 수행하여 Update문 생성
	}
}
```

## 더티 체킹 vs JPQL

많은 수의 row를 Update해야할 때는 더티 체킹보다 벌크 연산용으로 쿼리를 사용하는 것이 좋습니다. 
더티 체킹을 활용할 경우, 한 Row마다 Update문이 나가기 때문인데 이를 활용하여 빠른 속도로 Update를 마칠 수 있습니다.

```java
public interface UserRepository extends JpaRepository<User, Long> {
	@Modifying(clearAutomatically = true, flushAutomatically = true)
	@Query("update User u set u.age = u.age + 1 where u.id in :ids")
	void updateAgePlus(@Param("ids") List<Long> ids);
}
```

JPA에서 업데이트를 하는 방법과 더티체킹의 의미

JPA의 더티체킹(Dirty Checking)과 Update

JPA Repository에는 save메서드가 있습니다. 
이는 어쩔때는 INSERT문을 사용하고, 어쩔때는 UPDATE문을 사용합니다. 
이를 결정해주는건 `isNew`메서드를 사용하여서 해당 Entity가 새로 생긴건지 기존의 것인지를 구분합니다.

## SimpleJpaRepository 구현체

```java
// SimpleJpaRepository.java
@Transactional
public <S extends T> S save(S entity) {
	if (entityInformation.isNew(entity)) {
		em.persist(entity);
		return entity;
	} else {
		return em.merge(entity);
	}
}
```

위는 JPA Repository의 구현체인 SimpleJpaRepository에서 save메서드의 구현입니다. 
`isNew`메서드로 Entity가 새롭게 만들어진 것인지, 기존의 것인지를 구분하고 새로운것이면 `persist`를 아니면 `merge`를 수행합니다.

### isNew

```java
// AbstractEntityInformation.java
public boolean isNew(T entity) {
	ID id = getId(entity);
	Class<ID> idType = getIdType();

	if (!idType.isPrimitive()) {
		return id == null;
	}

	if (id instanceof Number) {
		return ((Number) id).longValue() == 0L;
	}

	throw new IlleaglArgumentException(String.format("Unsupported primitive id type %s!", idType));
}
```

위는 AbstractEntityInformation에서의 `isNew`메서드 구현체 입니다. 
ID의 타입이 기본 타입일 경우 0일 때, 참조 타입일 경우 null인 경우에 true를 반환합니다. 
이는 `@GeneratedValue`에 맞춰서 구현되어 있기 때문인데, 해당 어노테이션을 사용할 경우에는 INSERT시에 id값을 주지 않기 때문입니다. 
사실상 `@GeneratedValue`를 사용하지 않는 Entity면 false를 리턴하게 됩니다.

### persist vs merge

-	persist

	`persist`는 최초로 새엇ㅇ된 Entity를 영속화 합니다. 
	flush메서드가 호출될 때 `INSERT`문을 사용하게 됩니다.

-	merge

	`merge`는 `detached`상태의 Entity를 다시 영속화 합니다. 
	`detached`란 한번이라도 영속화가 되었지만 현재는 영속화가 되어있지 않은 상태 입니다. 
	다시 영속화 하는 과정에서 id값을 통해 `SELECT`문으로 값을 확인하게 됩니다. 
	flush메서드가 호출될 때 `SELECT`의 결과가 있다면 `UPDATE`를 없다면 `INSERT`를 사용합니다.

여기서 주의해야할 점은 `merge`입니다. 
`save`의 구현체를 보면 `persist`의 경우에는 기존의 Entity를 return하지만, `merge`의 경우에는 새로운 Entity를 return 합니다.

```java
@Transactional
public void test() {
	User user = User.builder()
			.id("id")
			.name("이름")
			.build();

	User insertUser = userRepository.save(user); // INSERT
	System.out.println(user == insertUser); // false

	insertUser.updateName("새로운 이름");
	User updateUser = userRepository.save(insertUser); // UPDATE
	System.out.println(insertUser == updateUser); // false
}
```

위의 테스트 코드를 동작하면 insertUser와 user도 서로 다르고, updateUser도 서로다른 Entity인 것을 확인할 수 있습니다. 
이 때 이전에 있던 Entity들은 더이상 영속성 관리 대상이 아니게 됩니다. 
그에 따른 dirtyCheck도 수행하지 않게 됩니다.

```java
@Transactional
public void test() {
	User user = User.builder()
			.id("id")
			.name("이름")
			.build();

	User insertUser = userRepository.save(user); // INSERT

	insertUser.updateName("새로운 이름");
	User updateUser = userRepository.save(insertUser); // UPDATE

	insertUser.updateName("또다른이름"); // dirtyCheck로 인한 UPDATE가 발생하지 않음.
	// updateUser.updateName("또다른이름"); 으로 하면 UPDATE가 제대로 발생함.
}
```

또다른 테스트 코드를 실행해보면 insertUser의 name을 변경하여도 dirtyCheck로 인한 UPDATE문이 발생하지 않는 것을 확인할 수 있습니다. 
따라서 `save`이후에 어떠한 로직을 수행할 경우 반드시 return 값을 새로이 받아서 사용하는 것이 좋습니다. 
만약에 `@GeneratedValue`를 사용한다면 결과가 달라질 수 있습니다.

```java
@Entity
@Builder
public class Board {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private id;

	private String content;
}
````

```java
@Transactional
public void test() {
	Board board = Board.builder()
				.content("내용").build();

	Board insertBoard = boardRepository.save(board);
	System.out.println(board == insertBoard); // true
	board.updateContent("새로운 내용"); // dirtyCheck로인한 UPDATE가 발생함
}
```

위의 테스트 코드에선 `persist`로 인해 같은 엔티티를 return하였고, 그 결과로 dirtyCheck가 수행된것을 확인할 수 있습니다.

## SELECT 없이 INSERT 하기(Persistable 구현)

한개나 두개의 row를 INSERT하는 경우라면 SELECT문이 발생해도 큰 지장이 없습니다. 
하지만 만약 1000개의 row를 INSERT하게 된다면 1000번의 SELECT문이 발생할 것이고, 이는 성능적으로 장애를 일으킬 수 있습니다. 
JPA에서는 이를 방지하기 위해 `isNew`메서드를 오버라이드 해와 직접 구현할 수 있습니다.

```java
public class User implements Persistable<String> {
	@Id
	private String id;

	@Override
	public String getId() {
		return id;
	}

	@Override
	boolean isNew() {
		return false;
	}
}
```

### Auditing 활용

지난번의 [Auditing 포스트](/post/back-end/auditing)의 Auditing기능을 활용할 수 있습니다. 
`@CreatedDate`는 entity가 INSERT될 때 자동적으로 입력이 됩니다. 
이를 이용하여서 필드값이 null일 경우에 isNew가 false임을 return하면 됩니다.

```java
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@Getter
public abstract class Auditalbe {
 ......
	@CreatedDate
	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	protected LocalDateTime createDateTime;
 ......
}
```

```java
public class User extends Auditable implements Persistable<String> {
	@Id
	private String id;

	@Override
	public String getId() {
		return id;
	}

	@Override
	boolean isNew() {
		return createDateTime = null;
	}
}
```

이렇게 구현할 경우 createDateTime이 null일 경우 SELECT문 없이 INSERT를 사용합니다.

## 마치며

JPA Repository의 save메서드를 분석하여 보았습니다. 
save 메서드를 통하여서 UPDATE를 할 경우, null인 데이터들은 그대로 null로 update가 될 수 있습니다. 
다음번에는 이를 방지하기 위한 방법과 dirtyCheck로 인한 UPDATE를 알아보겠습니다.

JPA Repository에서 save 메서드가 INSERT, UPDATE를 결정하는 방법과, SELECT없이 INSERT하는 방법

JPA의 save 메서드 동작과정과 SELECT 없이 INSERT하기

객체를 생성하는 방법에는 생성자 패턴, 메소드 패턴 등등이 있는데, 그 중에 빌더 패턴이 있습니다.

## Builder패턴 만들기

Lombok을 사용할 경우 빌더 패턴을 만들어서 사용하기 매우 편해집니다. 
하지만 그 이전에 Lombok없이 빌더 패턴의 구조를 만들어보도록 하겠습니다.

```java
public class User {
	private string id;
	private String password;

	User(String id, String password) {
		this.id = id;
		this.password = password;
	}

	public static User.UserBuilder builder() {
		return new User.UserBuilder();
 }

 public static class UserBuilder {
 private String id;
 private String password;

 public UserBuilder () { } //NoArgsConstructor

 public User.UserBuilder id(String id) {
 this.id = id;
 return this;
 }

 public User.UserBuilder password(String password) {
 this.password = password;
 return this;
 }

 public User build() {
 return new User(this.id, this.password);
 }
 }
}
```

위의 구조를 보면 User클래스와 그 내부 static 객체인 UserBuilder클래스를 생성하였습니다. 
User 클래스에서는 빌더 클래스에서 사용될 생성자가 하나 필요합니다. 
그리고 빌더클래스를 생성해주는 static builder 메서드를 만듭니다. 
빌더 클래스에선 기본 생성자 하나와 자기 자신을 return 하는 필드를 채우는 메서드들을 만듭니다. 
마지막으로는 User 클래스의 생성자를 이용해 자신의 필드들로 객체를 생성합니다.

```java
User user = User.builder()
		.id("홍길동")
		.password("1234").build();
```

빌더 패턴을 완성하였다면 위의 예시와 같이 객체를 생성할 수 있게 됩니다. 
위의 코드들을 Lombok을 사용하면 단 하나의 어노테이션으로 만들 수 있습니다.

```java
@Builder
public class User {
	private String id;
	private String password;
}
```

위의 class에 `@Builder` 어노테이션을 이용하면 위와 완전히 동일한 코드가 됩니다. 
또한 `@Builder` 어노테이션은 생성자에다가도 사용하여 특정 필드들만을 대상으로 구현할 수 있습니다.

```java
public class User {
	private String id;
	private String password;
	private String name;

	@Builder
	User (String password, String name) {
		this.password = password;
		this.name = name;
	}
}
```

Lombok은 매우 강력하지만, 모르고 쓰면 독이 된다 생각합니다. 
잘 알고 적용하는 것이 중요한데 그 이유를 설명하겠습니다.

### @Builder의 기능

`@Builder` 어노테이션은 빌더 클래스를 만들고 메서드를 제공해주는 기능만 있지 않습니다. 
Builder 어노테이션의 설명을 보면 아래와 같이 나와있습니다.

![builder size:600*150](/back-end/builder.png)

해석하면 클래스에 `@Build` 어노테이션을 사용할 경우 모든 필드를 인수로 사용하는 생성자를 제공해줍니다.(`@AllArgsConstructor(access = AccessLevel.PRIVATE)`) 
하지만 항상 제공하는 것이 아니라 생성자를 하나도 작성하지 않고, `@XArgsConstructor` 주석이 없을 경우 에만 제공해줍니다. 
만약 생성자가 있다면 Lombok은 모든 필드를 인수로 사용하는 생성자가 있다고 가정하고 코드를 생성하게 됩니다. 
즉 해석에 따르면 아무런 생성자 없이 `@Build`어노테이션 하나만 사용하거나, 그렇지 않은 경우에는 반드시 `@AllArgsConstructor`와 함께 이용해야 합니다.

### 생성자의 접근 단계

빌더 패턴을 사용할 때 생성자의 접근 단계또한 중요합니다.

-	기본생성자는 protected

`@NoArgsConstructor(access = AccessLevel.PROTECTED)`를 이용하여 기본성생자를 protected하게 합니다. 
그 이유는 무분별한 객체 생성을 막는 것인데 서비스에서 기본생성자를 통해 객체를 만들고 setter로 필드를 채울 경우에 완전하지 않은 객체가 될 가능성이 크기 때문입니다.

-	@Build 기반 생성자는 private

빌더 패턴을 사용할 객체는 `build()`를 통해서만 객체 생성을 제공하는 것이 좋습니다. 
또한 `@AllArgsConstructor`로 인해 변하기 쉬운 코드를 방지할 수 있습니다. 
따라서 아래와 같이 사용하는게 좋습니다.

```java
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@Builder
public class User {
	private String id;
	private String password;
	private String name;

	// 따로 생성자를 사용할 경우
	@Builder
	protected User (String password, String name) {
		this.password = password;
		this.name = name;
	}
}
```

## 사용하는 이유 (ResponseEntity)

Rest API 컨트롤러에서는 응답을 만들 때 ResponseEntity를 사용합니다. 
이 객체의 경우에는 생성자 패턴, 메서드 패턴, 빌더 패턴 모두 사용이 가능한데, 이 객체를 통해 예시를 들어보겠습니다.

```java
// 생성자 패턴 사용 1
return new ResponseEntity<TestDto>(testDto, HttpStatus.OK);
// 생성자 패턴 사용 2 (header 추가)
HttpHeaders httpHeaders = newHttpHeaders();
httpHeaders.add("token", "test");
return new ResponseEntity<TestDto>(testDto, httpHeaders, HttpStatus.OK);
// 생성자 패턴 사용 3 (상태코드만 보내줄 경우
return new ResponseEntity(HttpStatus.OK);
```

생성자 패턴을 이용한 구현입니다. 
코드를 보았을 때 코드의 직관성이 떨어지고, 코드를 확장할 외부의 라이브러리를 사용할 경우 생성자의 모양을 알아야만 사용할 수 있습니다.

```java
// 메서드 패턴 사용 1
return ResponseEntity.ok(testDto);
// 메서드 패턴 사용 2 (header 추가)
ResponseEntity<TestDto> response = ResponseEntity.ok(testDto);
response.getHeaders().add("token", "test");
return response;
// 메서드 패턴 사용 3 (상태코드만 보내줄 경우)
return Response.ok(null);
```
메서드 패턴을 이용한 구현입니다. 
메서드 패턴은 간단한 기능만 수행할 경우에는 거기에 맞는 코드를 작성하여 코드가 간결해지나, 코드를 확장할 경우 코드가 복잡해지거나 알맞는 메서드를 찾아야 합니다.

```java
// 빌더 패턴 사용 1
return Response.ok().body(testDto);
// 빌더 패턴 사용 2 (header 추가)
return ResponseEntity.ok()
	.header("token", "test")
	.body(testDto);
// 빌더 패턴 사용 3 (상태코드만 보내줄 경우)
return ResponseEntity.ok().build();
```

빌더 패턴을 이용한 구현입니다. 
필드명만 알면 코드에 일관성이 유지되고 유지보수가 쉬워집니다. 
위의 각 3가지 예시는 완전히 동일한 동작을 하는 코드입니다. 
상황에 따른 장단점은 있겠지만 확장을 할 경우에는 builder 패턴을 유용하게 사용할 수 있습니다. 
또한 코드를 한눈에 알아보기 쉽게 되어서 분석이 쉬워집니다. 
그리고 이 차이는 DTO같은 객체들을 직접 다룰 때 더 크게 나타납니다.

## 필드 기본값 주기

Lombok에는 `@Builder.Default`가 있습니다. 
이를 활용해 쉽게 필드의 기본값을 줄 수 있습니다.

```java
@Builder
public class User {
 private String id;
 private String name;
 @Builder.Default
 private String nation = "Korea";

}
```

하지만 이 방식은 class에 어노테이션을 붙일 경우에만 사용이 가능합니다. 
생성자에 `@Builder` 어노테이션을 사용할 경우에는 기본값이 들어가지 않습니다. 
따라서 아래와 같이 구현함으로서 기본값을 줄 수 있습니다.

```java
public class User {
 private String id;
 private String name;
 private String nation;

 @Builder
 private User (String id, String name) {
 this.id = id;
 this.name = name;
 this.nation = "Korea"; // 초기값을 줄 수 있습니다.
 }

}
```

생성자에서 직접 값을 초기화 함으로서 기본값을 줄 수 있게 됩니다.

## 필수 파라미터 확인하기

또한 생성자를 이용하여서 필수로 들어가야할 파라미터가 존재하는지 확인할 수 있습니다.

```java
public class User {
 private String id;
 private String password;
 private String name;

 @Builder
 private User(String id, String password, String name) {
 Assert.notNull(id, "id must not be null");
 this.id = id;
 this.password = password;
 this.name = name;
 }
}
```

## 마치며

Builder 패턴은 필드 수가 많을수록 큰 강점을 가지고 있습니다. 
실수를 줄여주고 확실한 객체를 만들기 쉽습니다. 
하지만 Builder 패턴 자체를 구현하기 위해서 들어가는 코드의 양이 많아지고,
또한 생성자 방식처럼 아예 필수 필드들을 처음부터 받을 수 있지 않아서 그에 따른 단점 또한 존재합니다. 
장,단점을 파악하고 사용하였을 때 빌더 패턴의 강점을 이용할 수 있다 생각합니다.

객체를 생성자가 아닌 Builder패턴으로 생성하기

Builder 패턴 사용하기

MSA에서는 각 설정파일(.yml, .properties) 들을 서비스 내부에서 관리하는것이 아니라, Config server를 두어서 설정값을 넘겨줍니다. 
이로 인해 여러 서비스에서 하나의 설정파일을 공유할 수도 있고, 혹은 설정 값을 변경할 때 중앙에서 쉽게 관리할 수 있게 됩니다. 
뿐만 아니라 dev, prod 환경 등을 구분하여 설정파일을 제공해줄 수 있어서 개발환경과 배포환경을 쉽게 구분하여 구성할 수 있습니다. 
Spring Cloud에선 Cloud Config Server를 통해 중앙 서버에서 Config설정을 관리하는 서비스를 만들 수 있습니다. 
[공식 홈페이지](https://cloud.spring.io/spring-cloud-config/refresence/html)

## Cloud Config Server 구성

build.gradle에 `Spring cloud` 의존성을 추가하고 Application 클래스에 `@EnableConfigServer`어노테이션을 추가함으로서 Cloud Config Server로 사용할 수 있습니다.

```groovy
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter'
	implementation 'org.springframework.cloud:spring-cloud-config-server'
}
```

```java
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
	public static void main(String[] args) {
		SpringApplication.run(ConfigServerApplication.class, args);
	}
}
```

## 저장소

Config Server에서 yml을 관리할 저장소는 크게 2가지가 있습니다. 
첫번째로는 config server의 로컬 파일 시스템을 활용하는 방법과, 두번째로는 다른 git repository를 이용해 그곳으로 부터 가져올 수 있습니다.

### 로컬 파일 시스템

```yml
spring:
	profiles:
		active: native
	cloud:
		config:
			server:
				native:
					search-locations: classpath:configs/
```

`spring.profiles.active` 속성을 native로 한다면 설정파일을 외부가 아닌 파일 시스템 혹은 프로젝트 내부 소스에서 제공하겠다는 의미입니다. 
`spring.cloud.config.server.native.search-locations` 속성은 설정파일들을 가져올 위치를 정할 수 있습니다. 
classpath를 이용해 현재 서비스의 `/src/main/resources/`로 부터 설정파일을 가져올 수 있습니다.

![config-directory](/back-end/config-directory.png)

위처럼 configs 폴더로부터 설정파일을 가져오게 됩니다.

### Git 저장소

```yml
server:
	port: 8881

spring:
	cloud:
		config:
			server:
				git:
					uri: https://github.com/show5116/...git
					username: test
					password: test
					search-paths: configs
```

git repository를 만들어서 username과 password를 통해 접근하고, 그 repository의 search-paths의 위치로 부터 설정 파일들을 가져올 수 있습니다.

## Client에서 사용

각 Client서비스에서는 Cloud Config Server로부터 설정정보를 가져와서 빌드시에 설정파일을 적용해줍니다. 
설정파일은 정해진 순서대로 읽게 되고, 같은 속성이 존재할 경우 마지막에 읽는 속성값으로 적용됩니다.

```groovy
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-config'
}
```

```yml
spring:
	application:
		name: auth-service
	cloud:
		config:
			uri: http://localhost:8881# config server uri
	profiles: 
		active: dev,test
```

### yml 파일 명 규칙

저장소로부터 yml파일을 가져오는 요소는 총 3가지가 있습니다.

-	`{application}` `spring.application.name`에 매핑됩니다.
-	`{profile}` `spring.profiles.active`에 매핑됩니다. (쉼표로 구분)
-	`{label}` git의 경우 branch로 매핑됩니다.

위의 yml파일과 같이 설정하였을 경우 우선 순위를 가지고 속성이 적용됩니다.

1.	config server `{application}-{profile}.yml`
2.	config server `{application}.yml`
3.	config server `application-{profile}.yml`
4.	각 프로젝트 `application-{profile}.yml`
5.	config server `application.yml`
6.	각 프로젝트 `application.yml`

만약 profile이 여러개일 경우 쉼표(,)를 기준으로 앞의 profile을 우선으로 적용합니다. 
실제로는 위의 우선순위의 반대로 yml파일을 불러오며, 만약 먼저 불러온 속성과 겹치는 속성이 뒤에 있을 경우 그 값을 덮어 쓰면서 기존의 값은 사라지게 됩니다.

## 마치며

위의 설정을 이용하여 실제로 dev, prd 환경에 맞게 설정값들을 쉽게 가져올 수 있습니다. 
더하여서 config server 자체를 숨기는 방법도 있고, 혹은 git private repository를 이용하여 ssh key를 통해 설정 값을 가져올 수 도 있고 무중단 설정값 변경 등 onfig server의 활용방법은 많습니다. 
각 어플리케이션마다 특징이나 환경이 다르니 공식 문서를 참조하면서 알맞게 적용하는 것이 좋을 수 있습니다.

Spring Cloud Config를 이용하여 중앙에서 설정파일을 관리해보자.

Spring Cloud Config

JPA에서는 Audit기능을 제공해줍니다. 
Audit은 감시하다 라는 뜻으로, 이 기능을 활용하면 생성일, 수정일, 생성한 사람, 수정한 사람의 정보를 남길 수 있습니다. 

## @MappedSuperclass

![mappedSuperclass size:800*400](/back-end/mapped-superclass.png)
`@MappedSuperclass` 어노테이션은 부모클래스에 선언하여서 상속받는 Entity들은 모두 상속받은 컬럼을 가지게 해줍니다. 
이 어노테이션을 사용한 클래스는 `엔티티`가 아니고, 상속관계 매핑이 아닙니다. 
위의 이미지와 같이 BaseEntity란 부모클래스가 id와 name이란 컬럼을 가지고 있다면, Member와 Seller Entity는 이를 상속받아 두개의 컬럼을 가지게 됩니다.

```java
@MappedSuperclass
@Getter
public abstract class BaseEntity {
	@Column(name = "create_user", columnDefinition = "varchar2(50)", nullable = false, updatable = false)
	private String createUser;

	@Column(name = "change_user", columnDefinition = "varchar2(50)", nullable = false)
	private String modifyUser;

	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	private LocalDateTime createDateTime;

	@Column(name = "change_time", columnDefinition = "date", nullable = false)
	private LocalDateTime modifyDateTime;

}
```

위에는 createUser, modifyUser, createDateTime, modifyDateTime 4개의 컬럼을 가진 추상클래스를 만들었습니다. 

```java
@Entity
@Table(name = "users")
public class User extends BaseEntity {
 ......
}
```

이런방식으로 해당 4개의 컬럼이 필요한 Entity에서 BaseEntity를 상속받으면 4개의 컬럼을 가지게 됩니다. 
대부분의 Entity는 생성시간과 수정시간을 저장해두면 좋으니 상속받아 구현하면 좋습니다.

## Audit 사용하기

`@MappedSuperclass`을 이용해 추상클래스를 구현하였다면, 이젠 Audit 기능을 사용하여서 INSERT, UPDATE시에 저 컬럼들에 값을 자동으로 넣도록 할 수 있습니다.

### Config

Audit을 위한 Configuration 파일을 생성해줍니다. 
`@EnableJpaAuditing`어노테이션은 사용한 어플리케이션에 JPA Audit 기능을 제공해주게 되는 어노테이션입니다. 
메인 어플리케이션 클래스에서 사용하여도 상관없지만, Test코드를 이용할 때와 또한 정확하게 기능을 구분하기 위해 따로 사용하는 것이 좋습니다.

```java
@Configuration
@EnableJpaAuditing
public class AuditingConfig implements AuditorAware<String> {

	@Override
	public Optional<String> getCurrentAuditor() {
		HttpServletRequest currentRequest = WebHelper.getCurrentRequest();
 String memberId = currentRequest.getHeader("member-id");
 memberId = memberId.isEmpty() ? "System" : memberId;
		return Optional.of(memberId);
	}
}
```

```java
public class WebHelper {
	public static HttpServletRequest getCurrentRequeset() {
		return ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
	}
}
```

`AuditorAware`을 implements하면 `getCurrentAuditor` 메서드를 구현하게 됩니다. 
해당 클래스는 추후에 createUser와 modifyUser에 들어가게 될 값을 정해줍니다. 
현재 HttpServletRequest를 가져오고, RequestHeader를 통해 member-id를 넣어줍니다. 
혹여 member-id가 없는 상황(Spring 스케쥴러를 통한 상황, 혹은 회원 가입 등..)에선 System이란 아이디를 넣어줍니다.

### 추상클래스 변경

앞에서 만들었던 추상클래스를 변경해주도록 하겠습니다. 
`@EntityListeners` 어노테이션은 JPA Entity에서 이벤트가 발생할 때마다 특정 로직을 실행시킬 수 있게 해주는 어노테이션입니다. 
AuditingEntityListener.class의 값을 주면 @PrePersist로 Audit 기능을 수행하게 해줍니다.

```java
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
@Getter
public abstract class Auditalbe {
	@CreatedBy
	@Column(name = "create_user", columnDefinition = "varchar2(50)", nullable = false, updatable = false)
	protected String createUser;

	@LastModifiedBy
	@Column(name = "change_user", columnDefinition = "varchar2(50)", nullable = false)
	protected String modifyUser;

	@CreatedDate
	@Column(name = "create_time", columnDefinition = "date", nullable = false, updateable = false)
	protected LocalDateTime createDateTime;

	@LastModifiedDate
	@Column(name = "change_time", columnDefinition = "date", nullable = false)
	protected LocalDateTime modifyDateTime;

}
```

- @CreatedDate

Entity가 INSERT될 때 생성 시간을 넣어줍니다. 
JPA에서 제공하는 `@CreateDate` 말고 Hibernate에서 제공하는 `@CreationTimestamp`이란 어노테이션도 존재합니다. 
둘의 차이점은 `@CreateDate`는 위에서 한 것과 같이 `@EnableJpaAuditing`과 `@EntityListeners`를 필요로 합니다. 
반면에 `@CreationTimestamp`는 그러한 설정없이 동작이 가능합니다. 
그 이유는 JPA는 JPA 고유 메모리 공간(context)을 이용해 Entity 객체들을 관리하는데 관리되는 객체들이 변경되면 데이터에 반영하는 형식이라 변화를 감지해야 하기 때문입니다.

- @LastModifiedDate

Entity가 UPDATE될 때 수정 시간을 넣어줍니다. 
마찬가지로 Hibernate에서 제공하는 `@UpdateTimestamp`이란 어노테이션이 존재해서 대신 사용해도 됩니다.

- @CreatedBy

Entity가 INSERT될 때 `getCurrentAuditor`메서드를 통해 얻어온 값을 넣어줍니다.


- @LastModifiedBy

마찬가지로 Entity가 UPDATE될 때 `getCurrentAuditor`메서드를 통해 얻어온 값을 넣어줍니다.

JPA의 Auditing과 MappedSuperclass를 이용하여 INSERT와 UPDATE시 시간과 저장한 사람의 정보를 담습니다.

JPA의 Auditing 기능 INSERT, UPDATE시 시간 저장하기

JPA에서는 데이터를 삭제하는 방법이 여러가지 있습니다. 
논리적 삭제(UPDATE문)을 통한 방법도 있지만 해당 글은 물리적 삭제(DELETE문)에 대한 글입니다.

## JpaRepository


```java
public interface UserRepository extends JpaRepository<User, String> {
}
```

```java
@Entity
@Table(name = "users")
@NoArgsConstructor(acessLevel = Accesslevel.PRIVATE)
public class User {
	@Id
	@Column(name = "user_id")
	private String id;

	......
}
```

JPA에서 제공하는 JpaRepository는 인터페이스를 만드는 것 만으로도 다양한 CRUD 메서드들을 제공해줍니다. 
[JpaRepository](/post/back-end/jpa-repository)참조 
그 중에서도 delete 관련된 메서드들이 존재하는데, 해당 메서드들에 대해서 먼저 알아보고 각 맞는 사용법에 대해 설명드리겠습니다.

### delete

`delete(T entity)`는 가장 기본적인 delete 메서드 입니다. 
매개변수로 entity를 받고 아래의 쿼리로 단일 조회를 마친 후 해당 row가 있다면 delete하고, 없다면 아무런 일이 일어나지 않습니다.

```sql
SELECT member.*
 FROM member
 WHERE member.id = ?
```

```java
@Service
@RequiredArgsConstructor
public class MemberService {
	private final MemberRepository repository;

	@Transactional
	public deleteOne(String id) {
		Member member = repository.findById(id).get();
		repository.delete(member);
	}
}
```

단일 데이터 삭제를 할때는 유용하게 사용됩니다. 
조회 쿼리가 나가는게 부담도 없고 사용하기도 편합니다. 
JpaRepository의 구현체인 SimpleJpaRepository에는 아래와 같이 구현되어 있습니다.

```java
// SimpleJpaRepository.java
@Transactional
public void delete(T entity) {
	
	Assert.notNull(entity, "Entity must not null!");
	// isNew() 메서드는 엔티티의 ID 유무를 확인해 DB에 들어간 값인지 아닌지를 판단합니다.
	if (entityInformation.isNew(entity)) {
		return;
	}

	T existing = em.find(entityInformation.getJavaType(), entityInformation.getId(entity));

	if (existing == null) {
		return;
	}
	em.remove(em.contains(entity) ? entity : em.merge(entity));
}
```

### deleteAll

`deleteAll(Iterable<? extends T> entities)` 이 메서드는 위의 delete메서드를 반복하는 것과 같은 역할을 합니다. 
실제로 JpaRepository의 구현체를 보면 delete를 반복하여서 구현한 것을 확인할 수 있습니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteAll(Iterable<? extends T> entities) {
	Assert.notNull(entities, "Entities must not be null");

	for (T entity : entities) {
		delete(entity);
	}
}
```

결국 이 메서드도 삭제를 진행하기 전에 모든 데이터를 SELECT를 하고 DELETE를 실행하여서 데이터의 row가 많을 경우 실행시간이 오래걸릴 수 있습니다. 
매개변수를 넣지 않을경우에는 해당 Entity의 모든 데이터를 삭제합니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteAll() {
	for (T element : findAll()) {
		delete(element);
	}
}
```

### deleteById

`deleteById(ID id)`는 id값으로 Entity를 조회하고 있다면 삭제합니다. 
Entity가 없다면 `EmptyResultDataAccessException` 익셉션이 던져집니다.

```java
// SimpleJpaRepository.java
@Transactional
public void deleteById(ID id) {
	Assert.notNull(id, ID_MUST_NOT_BE_NULL);

	delete(findById(id).orElseThrow(() -> new EmptyResultDataAccessException(
String.format("No %s entity with id %s exists!", entityInformation.getJavaType(), id), 1)));
}
```

여기까지의 delete 메서드들을 보았을 때 모두 SELECT를 하여서 존재 유무를 확인한 후에 DELETE를 하였습니다. 
따라서 다수의 데이터를 삭제할때는 당연히 수행시간이 늦어질 수 밖에 없습니다. 
일부러 ID가 없을경우 익셉션을 내야하는 경우가 아니라면 (그런 경우가 있는지도 모르겠지만..) 단건이 아닌 데이터들에 위의 메서드들을 사용하는 것은 안좋은 방법이라 생각합니다.

### deleteInBatch

**주의 2022년 기준으로 해당 메서드는 <del>deprecated</del> 되었고, deleteAllInBatch(Iterable entities)로 대체되었습니다.(로직은 동일)** 
`deleteInBatch(Iterable entites)`는 위의 메서드들과는 달리 SELECT문을 사용하지 않습니다.

```java
SimpleJpaRepository.java
@Transactional
public void deleteInBatch(Iterable<T> entities) {
	Assert.notNull(entities, "Entities must not be bull!");

	if (!entities.iterator().hasNext()) {
		return;
	}

	applyAndBind(getQueryString(DELETE_ALL_QUERY_STRING, entityInformation.getEntityName()), entities, em)
		.executeUpdate();
}
```

위의 `getQueryString` 으로 가져오는 쿼리문은 delete문입니다.

```java
// QueryUtils
public static final String DELETE_ALL_QUERY_STRING = "delete from %s x";
```

그리고 또한 `applyAndBind`는 아래와 같이 구현되어 있습니다.

```java
public static <T> Query applyAndBind(String queryString, Iterable<T> entities, EntityManager entityManager) {
	...
	Iterator<T> iterator = entities.iterator();
	...
	StringBuilder builder = new StringBuilder(queryString);
	builder.append(" where");

int i = 0;
	
	while (iterator.hasNext()) {
		iterator.next();

builder.append(String.format(" %s = ?%d", alias, ++i));

		if (iterator.hasNext()) {
			builder.append(" or");
		}
	}
}
```

로직에 따르면 or절을 계속해서 이어붙이면서 where 절을 완성시킵니다. 
실제 쿼리는 아래와 같이 나가게 됩니다.

```sql
DELETE FROM meber
 WHERE member.id = ? OR member.id = ? ...
```

결과적으로 이 메서드는 단 한번의 delete 쿼리를 만들어서 삭제를 하기 때문에 위의 메서드들보다 빠르게 삭제가 가능합니다. 
하지만 이 메서드도 완벽하진 않습니다. 
그것은 바로 JPA 내부의 문제점인데, 쿼리를 생성할 때 너무 많은 or절을 생성할 경우 `StackOverFlow`익셉션이 발생하는 현상이 있습니다. 
따라서 한번의 많은 데이터를 DELETE할 때 갑작스레 에러가 발생할 수 있습니다.

### deleteAllInBatch

`deleteAllInBatch()`는 매개변수 없이 테이블의 모든 데이터를 삭제합니다. 
위처럼 where절을 생성하지도 않고 SELECT 절을 사용하지도 않습니다. 
하지만 실제 서비스에선 사용할 일이 거의 없을것입니다.

```java
//SimpleJpaRepository.java
@Transactional
public void deleteAllInBatch() {
	em.createQuery(getDeleteAllQueryString()).executeUpdate();
}
```

## Bulk delete 해결방법

결국 가장 좋은 방법은 순정이라고, 직접 delete 쿼리를 작성하는 방법입니다.

```java
pulibc interface MemberRepository extends Repository<Member, String> {
	@Modifyung(clearAutomatically = true, flushAutomatically = true)
	@Query("delete from Member m where m.id in :ids")
	void deleteAllByIds(@Param("ids") Iterable<String> ids);
}
```

위와 같이 in절을 이용해 커스텀 쿼리문을 작성하면 빠른 성능으로 삭제를 할 수 있습니다.

### @Modifying

위와 같은 벌크 연산을 실행하게 될 시에는 영속성 컨텍스트를 무시하고 쿼리가 실행됩니다. 
따라서 이미 제거된 엔티티를 조회할 가능성이 생길 수 도 있는데 `@Modifying` 어노테이션은 DB와 데이터 싱크를 맞춰주는 역할을 합니다. 
`@Modifying` 어노테이션은 JPA Entity의 Life Cycle을 무시하고 쿼리가 실행됩니다. 
그래서 영속성 관리를 위한 clearAutomatically 속성과 flushAutomatically 속성이 있습니다.

-	clearAutomatically

	이 속성은 쿼리 메서드 실행 후, 영속성 컨텍스트를 clear해주는 속성입니다. 
	이 속성을 true로 하면 삭제된 Entity를 조회할 일이 사라지게 됩니다.

-	flushAutomatically

	이 속성은 쿼리를 실행하기 전, 영속성 컨텍스트의 변경사항을 DB에 lush할 것인지 결정하는 속성입니다. 
	default는 false이나, Hibernate의 FlushModeType이 default로 AUTO값이기에 따로 설정하지 않으면 flushAutomatically가 false이든 true이든 항상 쿼리 실행 전에 flush가 나가게 됩니다.

Spring data Jpa에서 delete를 하는 여러 가지 방법과 대량 데이터 삭제할 때 더 좋은 방법

JPA delete (bulk delete)

## JpaRepository

Spring Data JPA를 사용하면 기본적인 CRUD쿼리는 직접 작성하지 않고 공통 인터페이스를 통해 사용합니다. 
JpaRepository는 공통 인터페이스로서 `save()`, `saveAll()`, `findById()`, `delete()` 등등.. 간단한 메서드가 이미 정의되어 있습니다. 
해당 메서드들의 구현체는 `SimpleJpaRepository`에 구현되어 있어서 인터페이스를 생성하는 것 만으로도 CRUD가 가능합니다.

```java
@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
	...
	@Transactional
	public <S extends T> S save(S entity) {
		if (entityInformation.isNew(entity)) {
			em.persist(entity);
			return entity;
		} else {
			return em.merge(entity);
		}
	}
}
```

위의 코드는 실제 구현체에서 save 메서드에 대한 구현 로직입니다.

### 기본 사용법

1.	Entity 생성

```java
@Entity
@Getter
@NoArgsConstructor(access = Accesslevel.PRIVATE)
@AllArgsConstructor(access = Accesslevel.PROTECTED)
@Builder
public class Test {
	@Id
	@GenerationValue(straregy = GenerationType.IDENTITY)
	private Long id;

	private String name;

	public updateName(String name) {
		this.name = name;
	}
}
```

2.	Repository 새엇ㅇ
Repository를 생성합니다. 
이 때 Bean에 등록할 @Repository 어노테이션은 사용하지 않아도 됩니다. 
구현체 클래스에서 이미 어노테이션이 선언 되어있기 때문에 상속받는 것 만으로도 Bean에 올라갑니다.

```java
// 제네릭 좌측은 Entity 클래스를, 우측에는 해당 Entity의 Id 타입을 넣어줍니다.
public interface TestRepository extends JpaRepository<Test, Long>
```

3.	메서드 사용

```java
@Service
@RequiredArgsConstructor
public class TestService {
	private final TestRepository testRepository;

	@Transactional(readOnly = true)
	public Test getTestEntity(long id) {
		Optional<Test> testWrapper = testRepository.findById(id);
		Test test = testWrapper.orElseThrow();
	}

	@Transactional
	public void insertTestEntity(String name) {
		Test test = Test.builder()
				.name(name).build();
		testRepository.save(test);
	}

	@Transactional
	public void updateTestEntity(long id, String newName) {
		Optional<Test> testWrapper = testRepository.findById(id);
		Test test = testWrapper.orElseThrow();
		test.updateName(id);
	}

	@Transactional
	public void deleteTestEntity(long id) {
		testRepository.deleteById(id);
	}
}
```

위의 예시처럼 select, insert, update, delete문을 간단하게 구현 가능합니다. 
이외에도 페이징 쿼리나 bulk 연산 쿼리들도 기본 메서드로 구현되어 있습니다. 
각 기능들에 대해선 추후에 포스팅 하겠습니다.

### 메서드 정의하기

JpaRepository는 특수한 명명 규칙으로 메서드를 정의하여 사용할 수 있습니다. 
특정 검색조건이나 orderBy, 혹은 특정row 갯수만 조회한다던가 메서드 이름으로 여러 방법으로 활용할 수 있습니다. 
이에 대해서도 추후에 자세하게 포스팅하겠습니다.

```java
public interface TestRepository extends JpaRepository<Test, Long> {
	public List<Test> findAllByName(String name);
}
```

### @Query 어노테이션

@Query 어노테이션을 이용해서 JPQL 문법을 활용해 쿼리를 직접 작성할 수 있습니다. 
nativeQuery = true 속성을 통해 nativeQuery도 사용 가능합니다.

```java
public interface TestRepository extends JpaRepository<Test, Long> {
	@Query("select t.username from Test t")
 public List<String> findAllName();

 @Query("select t from Test t where t.name = :name")
 public Optional<Test> findTestByName(String name);
}
```

## JpaRepository의 계층

![Repository-interface size:800*400](/back-end/repository-interface.png')

위에서 사용한 JpaRepository는 PagingAndSortingRepository를 상속받았고, 그 위에는 CrudRepository 최종적으로는 Repositry interface로부터 상속받았습니다. 
JpaRepository는 최하층으로서 CrudRepository에선 Crud 메서드를, PagingAndSortingRepository에선 Paging 쿼리를 그리고 JpaRepository에선 flush메서드 등이 구현됩니다. 
최 상단인 Repository를 상속받으면 구현이 되어있는 메서드가 전혀 없습니다. 
따라서 사용할 메서드를 직접 선언해줘야만 합니다.

```java
public interface TestRepository extends Repository<Test, Long> {

 public Test save(Test test);

 public void delete(Test test);

 public Optional<Test> findById(Long id);
}
```

실제 JpaRepository에서 사용하는 메서드와 같은 타입, 같은 이름으로 선언해주면 동일한 로직을 수행하는 메서드가 구현되게 됩니다.

## Repository를 사용하면 좋은 이유

그렇다면 왜 Repository 인터페이스를 언급했을까요? 
실제로 JpaRepository를 사용해도 서비스에는 문제는 없습니다. 
하지만 JpaRepository를 사용할 경우에는 실제로 사용하지 않는 메서드들이 너무 많이 만들어집니다. 
그에 따라 Repository를 사용할 경우 상대적으로 얻게되는 장점들이 있습니다.

1. 필요한 메서드들만 구현하고 외부로 노출

 repository만 보더라도 어떤 역할들을 하는지 한눈에 알아볼 수 있게 됩니다. 
 또한 IDE에서는 해당 메서드들을 사용하고 있는 위치를 쉽게 추적도 가능하게 해줍니다.

2. 메서드의 재사용성

 필요한 메서드들만 구현할 경우 메서드들의 재사용성이 늘어납니다. 
 이에 따라서 쿼리 캐싱의 가능성이 높아지게 됩니다.

이러한 점들로 인하여 Repository를 사용하면 조금 더 Repository의 역할에 집중할 수 있게 해줍니다. 
물론 JpaRepository를 상속받으면 코드의 수도 적어지고 구현하기 쉬워지니 무엇이 무조건 맞다고는 할 수 없습니다.

JpaRepository의 간단한 사용법과 그냥 Repository를 사용할 때의 이점

JpaRepository의 사용법 그리고 Repository

[JWT 로그인 방식 구현 포스트](/post/back-end/access-token)에선 access token을 발급받는 과정까지 구현하였습니다. 
하지만 access token 하나만 가지고는 보안에서 한계가 존재하는데 이를 refresh token으로 극복할 수 있습니다.

## refresh token

JWT는 무상태(Stateless) 방식을 사용합니다. 
즉 서버가 클라이언트의 상태를 보존하지 않게 되는데, JWT가 만약 탈취당할 경우 서버는 이를 알지 못합니다. 
즉 누군가에게 토큰을 탈취당하면 아이디 비밀번호를 모르더라도 서비스를 제약 없이 사용할 수 있게 됩니다. 

refresh token이란 이런 단점을 보안하기 위해 새로운 하나의 토큰을 더 사용하는 것입니다. 
access token의 유효시간을 짧게 하고, 이 유효기간이 지날 경우에는 refresh token을 이용해서 새로운 access token을 발급하여 사용할 수 있게 합니다. 
즉 refresh token의 유효기간은 로그인 유지 시간이 되고, access token은 그 시간 내에 OTP처럼 계속해서 발급받는 토큰이 됩니다.

## refresh token의 탈취

하지만 refresh token도 마찬가지로 탈취당하면 위험합니다. 
탈취한 refresh token을 이용해서 새로운 access token을 발급받을 수 있고, 새로이 발급받은 access token으로 서비스를 이용할 수 있습니다. 
결국 access token 하나만 사용할 때와 마찬가지로 탈취당하게 된다면 refresh token을 사용한 의미가 없게 될 수 있습니다. 
그래서 이러한 현상을 막기 위해 refresh token에는 새로운 접근이 필요합니다.

### 서버에서 refresh token을 관리

refresh token을 발급하고 서버의 로직으로 이를 관리합니다. 
하지만 서버가 클라이언트의 상태를 가지게 되므로 더이상 무상태(Stateless)가 아니게 됩니다. 
서버에서 refresh token을 관리하는 방법으로는 세션을 이용하거나 데이터베이스를 이용합니다. 
세션의 경우에는 사용자가 많아질수록 부담이 심해지고 관리가 힘들어집니다. 
거기에 더불어 무상태(Stateless)에서 완전하게 벗어나게 되므로 JWT를 사용하는 이점을 잃게 됩니다. 
따라서 데이터베이스를 사용하는 것이 더 좋다 생각합니다. 
이 또한 무상태(Stateless)는 벗어나지만 적어도 access token의 유지 시간동안은 서버의 접근을 필요로 하지 않기 때문에 어느정도는 포기하지 않을 수 있습니다.

-	access token 저장 위치

access token은 탈취당할 경우 유지시간이 짧더라도 그 시간동안은 서비스를 이용할 수 있습니다. 
javascript의 비공개(private) 변수를 이용하면 가장 안전하게 지킬 수 잇습니다. 
비공개 변수에는 공격자가 접근할 방법이 없으니 XSS나 CSRF 공격으로부터 자유롭습니다. 
하지만 javascript의 변수라서 단점이 존재하는데, 페이지 이동이나 새로고침을 하게 되면 해당 변수는 사라지게 됩니다. 
따라서 페이지에 접근할 때 access token을 새로 발급받는 로직을 추가해야 합니다.
React 프레임워크처럼 CSR만 사용한다면 그나마 덜하지만 Next 프레임워크처럼 SSR을 사용한다면 access token을 자주 재발급 받게 될 수 도 있습니다.

-	refresh token 저장 위치

refresh token을 저장할 수 있는 저장소의 종류는 3가지가 있습니다. 
로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage) 그리고 쿠키(Cookie)가 있습니다. 
`로컬 스토리지`와 `세션 스토리지`는 둘 다 자바스크립트로 저장하고 가져올 수 있습니다. 
따라서 XSS공격을 통해 토큰을 탈취당할 가능성이 존재합니다. 
이 둘은 둘다 새로고침이나 페이지 이동에도 저장소가 유지되나, 세션 스토리지는 새로운 탭으로 열릴 경우 저장소를 공유하지 않습니다. 
`쿠키`의 경우에는 자바스크립트로도 접근이 가능하고, 서버로부터 접근도 가능하여서 XSS공격과 CSRF공격에 모두 취약합니다. 
그래도 쿠키는 이러한 공격으로부터 비교적 안전하게 사용할 수 있는 옵션들이 존재합니다. 
`HttpOnly`가 true일 경우 쿠키는 자바스크립트로 접근이 불가능하게 되어 XSS로부터 비교적 안전합니다. 
`Secure`옵션은 Https로만 쿠키가 전해지기 때문에 Https설정을 할 경우에 안전해집니다. 
`SameSite`옵션은 크로스 사이트(Cross-site)로 전송하는 요청에 대하여 쿠키를 제한합니다. 
SameSite옵션은 Strict모드와 Lax모드가 있습니다. 
`Strict`모드는 같은 도메인 범위에서만 해당 쿠키를 사용하게 되며, `Lax`모드는 기본적으로 Strict모드와 비슷하나 사용자가 페이지 이동이나 혹은 Form을 통한 Get 요청시에는 크로스 사이트에도 사용합니다. 
SameSite옵션을 활용하면 CSRF공격으로 부터 어느정도 안전하게 됩니다. 
결론으로는 access token을 private 변수에 사용하게 될 경우 그리고 후술할 RTR방식까지 사용하게 될 경우 access token은 탈취 불가능해지고 refresh token만 탈취해서는 할 수 있는 것이 없게 됩니다. 
비교적 쿠키가 안전하다고는 하나 쿠키도 공격자들이 마음만 먹으면 XSS나 CSRF공격을 완전하게 막을 순 없습니다. 
따라서 개인적으로는 저장소는 선택의 영역이라 생각합니다.

-	access token 유지 시간

access token의 유지 시간은 짧으면 짧을수록 보안이 강화됩니다. 
하지만 그만큼 서버에 접근하는 횟수가 많아지기 때문에 사용자가 많을수록 부담이 될 가능성이 있습니다. 
짧으면 분단위, 길면 시간단위로 설정합니다.

-	refresh token 유지 시간

refresh token도 마찬가지로 유지 시간이 짧을수록 보안은 강화됩니다. 
하지만 유지시간은 곧 로그인 유지시간이니 짧으면 짧을수록 사용자들이 UX적으로 불편함을 느낄 수 있습니다. 
시간단위나 날짜단위로 설정합니다.

### Refresh Token Rotation(RTR)

데이터베이스에 refresh token과 access token을 1:1로 설계합니다. 
그러면서 refresh token과 access token이 1:1이 되기에 refresh token도 1회용으로만 사용이 가능해집니다. 
새로운 access token을 발급받을 때 동시에 refresh token도 발급받음으로서 기존의 refresh token은 폐기합니다. 
이 과정을 `Refresh Token Rotation`이라고 합니다. 
만약 누군가가 refresh token을 탈취하더라도 사용 전에 refresh token이 이미 발급되면 사용이 불가능해집니다. 
또한 refresh token을 탈취 당하더라도 access token이 같이 탈취 당하지 않는 이상 사용이 불가하고, 혹여나 둘다 탈취당했다 하더라도 기존 사용자의 refresh token이 폐기 됨으로써 기존 사용자가 재발급을 요청할 경우 토큰이 유출되었음을 감지할 수 있게 됩니다.

-	IP 정보와 함께 사용

사용자의 IP를 받아서 데이터베이스에 같이 저장합니다. 
토큰의 유효성을 검사할 때 IP정보도 확인함으로서 조금 더 안전하게 사용이 가능합니다.

-	로그인 유지 시간 갱신

RTR방식을 사용할 경우 refresh token을 재생성 할 때 마다 만료 시간 클레임을 다시 정해줄 수 있습니다. 
그에 따라 refresh token 재발급 할 때 마다 계솏해서 새로운 만료 시간을 줄 수도 있고, 혹은 초기의 만료시간을 다시 주면서 처음 로그인 시 기준으로 만료시간을 정해줄 수도 있습니다.

## 구현

위에서 서술한 방식을 토대로 구현해보도록 하겠습니다. 
refresh token은 쿠키에 저장할 경우에는 서버쪽 코드에서 저장해야하고, 로컬 스토리지에 저장할 경우에는 자바스크립트 코드에서 저장해야 합니다. 
저는 실제로 자바스크립트 코드로 구현하여서 서버쪽에선 respnose에 추가해주었습니다.

### 엔티티

```java
@Entity
@Table(name = "token")
@NoArgsConstructor(access = Accesslevel.PROTECTED)
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class Token {
	@Id
	@Column(name = "user_id")
	private String id;

	@Column(name = "access_token")
	private String accessToken;

	@Column(name = "refresh_token")
	private String refreshToken;

	@Column(name = "ip_address")
	private String ipAddress;

	@OneToOne
	@MapsId
	@JoinColumn(name = "user_id")
	private User user;

	public void updateUser(User user) {
		this.userId = user.getId();
		this.user = user;
	}
}
```

```java
@Entity
@Table(name = "users")
@NoArgsConstructor(access = Accesslevel.PROTECTED)
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class User {
	@Id
	@Column(name = "user_id")
	private String id;

	@Column(name = "password")
	private String password;

	@Column(name = "user_name")
	private String name;

	@OneToOne(cascade = CascadeType.ALL, mappedBy = "user")
	@PrimaryKeyJoinColumn
	private User user;

	public void updateToken(Token token) {
		this.token = token;
	}
}
```

### controller

refreshToken을 이용해 새로운 accessToken을 발급받을 로직을 추가해줍니다. 
@RequestMapping 의 Method를 지정하지 않아서 Get, Post, Delete 등 어떠한 Method로 넘어오더라도 발급이 가능하도록 합니다. 
이렇게 한 이유는 API-Gateway에서 access-token 인증에 실패할 경우 API 주소만을 변경해주기 때문에 기존의 Method방식으로 그대로 넘어오기 때문입니다. 
그러면 화면에서는 사용자가 눈치채지 않게끔 access-token을 자연스럽게 발급받을 수 있습니다.

```java
@RestController
@RequiredArgsConstructor
public class SignController {
	private final SignService signService;

	@PostMapping("/auth/sign/in")
	public ResponseEntity<SignInResponse> signIn(HttpServlet request, @RequestBody SignInRequest requestBody) {
		return ResponseEntity.ok(signService.signIn(request, requestBody));
	}

 @RequestMapping(value = "/auth/sign/refresh")
 public ResponseEntity<SignResponse> refreshToken(
	 HttpServletRequest request,
	 @RequestHeader("Refresh-Token") String refreshToken
 ) {
	 return ResponseEntity.ok(signService.refreshToken(accessToken, refreshToken));
 }
}
```

```java
// SignResponse
@NoArgsConstructor
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class SignInResponse {
	private String memberName;

	// 기존의 token을 accessToken으로 수정
	private String accessToken;

	// 새로운 refreshToken 추가
	private String refreshToken;
}
```

### Service

[JWT 로그인 방식 구현 포스트](/post/back-end/access-token)에서 구현한 로그인 로직에 refresh token도 발급하도록 수정하겠습니다. 
또한 refreshToken을 새로 발급받는 서비스를 구현합니다. 
IP주소가 다를경우 로그인을 차단하였지만, 서비스에 따라서 핸드폰 인증을 거치게 하는 방식으로 구현도 가능합니다.

```java
@Service
@RequiredArgsConstructor
public class SignService {

	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());
	private static final String AUTH_TOKEN_HEADER_PREFIX = "Bearer ";

	private final BCryptPasswordEncoder passwordEncoder;
	private final JwtUtil jwtUtil;
	private final UserRepository userRepository;
	// 새롭게 Token Repository를 추가합니다.
	private final TokenRepository tokenRepository;

	@Transactional
	public SignResponse signIn(HttpServletRequest request, SignInRequest requestBody) {
		User loginUser = userDao
			.findById(requestBody.getId())
			.filter(user -> passwordEncoder.matches(AesCryptUtil.decrypt(requestBody.getPassword()), user.getPassword()));

		String accessToken = jwtUtil.createAccessToken();
		// refreshToken도 같이 발급해줍니다.
		String refreshToken = jwtUtil.createRefreshToken(loginUser);

		this.updateToken(loginUser, accessToken, refreshToken, request);

		logger.info("{} login success", requestBody.getId());

		return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.accessToken(accessToken)
			.refreshToken(refreshToken)
 .build();
	}

 @Transactional
	public SignResponse refreshToken(HttpServletRequest request, String refreshToken) throws Exception {
 String subRefreshToken = refreshToken.subString(AUTH_TOKEN_HEADER_PREFIX.length());
 // refreshToken이 만료될 시 여기서 Exception 발생
 String userId = jwtUtil.getTokenField(subRefreshToken, PrivateClaimKey.USER_ID, String.class);

		User loginUser = userRepository.findById(userId).orElseThrow();

 if (loginUser.getToken() == null) {
 // 무언가 잘못된 요청으로 refreshToken이 폐기될 경우 입니다.
 throw new Exception("잘못된 요청 시도가 있었습니다. 본인이 아닐 시 문의 바랍니다.");
 } else if (!refreshToken.equals(loginUser.getToken().getRefreshToken())) {
 // 이미 폐기된 refreshToken을 통해 인증을 시도할 경우입니다.
			tokenRepository.delete(loginUser.getToken());
			throw new Exception("잘못된 인증 값입니다. 여러 매체에서 로그인 시도한 경우가 아닐 시 해킹 가능성이 있으니 확인 바랍니다.");
		} else if (!WebHelper.getIpAddress(request).equals(loginUser.getToken().getIpAddress())) {
		 // IP 주소가 처음 로그인 시도한 곳과 다를 경우입니다.
 tokenRepository.delete(loginUser.getToken());
			thorw new Exception("다른 IP주소에서 접근을 시도하셨습니다. 다시 로그인 해주세요.");
		}

 String newAcessToken = jwtUtil.createAcessToken(loginUser);
		String newRefreshToken = jwtUtil.createRefreshToken(loginUser);

		this.updateToken(loginUser, newAccessToken, newRefreshToken, request);

 return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.accessToken(newAcessToken)
			.refreshToken(newRefreshToken)
 .build();
	}

	public void updateToken(User user, String accessToken, String refreshToken, HttpServletRequest request) {
		String ipAddress = WebHelper.getIpAddress(request);

		if(user.getToken() != null) {
			tokenRepository.delete(user.getToken());
		}

		Token token = Token.builder()
			.accessToken(accessToken)
			.refreshToken(refreshToken)
			.ipAddress(ipAddress)
			.build();

		token.updateUser(user);
		user.updateToken(token);

		userRepository.save(user);
		tokenRepository.save(token);
	}
}
```

### JwtUtil

refresh Token을 발급할 메서드를 추가해줍니다. 
또한 TokenField interface를 활용하여서 특정 클레임을 parsing 하는 메서드를 만들었습니다.

```java
@Component
public class JwtUtil {

	@Value("${jwt.signKey}")
	private String jwtSignKey;

	public String createAccessToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("accessToken", body, 30);
	}

 	public String createRefreshToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("refreshToken", body, 60 * 24 * 2);
	}

	public String createToken(String subject, Map<String, Object> body, int expirationTime) {
		LocalDateTime currentTime = LocalDateTime.now();

		Claims claims = Jwts.claims(body);

		return Jwts.builder()
			.setClaims(claims)
			.setSubject(subject)
			.setIssuer("https://oms-tech-blog.netlify.app")
			.setIssuedAt(Date.from(currentTime.atZone(ZoneId.systemDefault()).toInstant()))
			.setExpiration(Date.from(currentTime.plusMinutes(expirationTime).atZone(ZoneId.systemDefault()).toInstant()))
			.signWith(SignatureAlgorithm.HS512, jwtSignKey)
			.compact();
	}

	public <T> T getTokenField(String token, TokenField tokenField, Class<T> type) {
		return Jwts
			.parser()
			.setSigningKey(jwtSignKey)
			.parseClaimsJws(token)
			.getBody()
			.get(tokenField.getValue(), type);
	}
}
```

### WebHelper

WebHelper를 통해 ip주소를 가져오는 메서드를 만듭니다.

```java
public class WebHelper {
	public static String getIpAddress(HttpServletRequest request) {
		String ip = request.getHeader("X-Forwarded-For");

		if(ip == null || ip.length() == 0) ip = request.getHeader("Proxy-Client-IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("WL-Proxy-Client-IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("HTTP_CLIENT_IP");
		if(ip == null || ip.length() == 0) ip = request.getHeader("HTTP_X_FORWARDED_FOR");
		if(ip == null || ip.length() == 0) ip = request.getRemoteAddr();

 return ip;
	}
}
```

## 마치면서

token을 활용한 인증 방법에는 고민할 거리가 정말 많았습니다. 
access token이나 refresh token의 저장 위치부터, 그리고 front-end에서 새로고침할 경우에 새로이 발급받으면서도 만료시에는 사용자가 눈치채지 않게 하면서 구현하는 방법까지. 
구현 방법도 다양했으나 UX적으로 편리할 수록 보안은 조금씩 약해질 수 밖에 없었고, 반대로 완전한 보안또한 존재하지는 않았습니다. 
하지만 보안에 대해 계속해서 고민하고 고쳐가면서 더욱 발전하는거라 생각합니다.

JWT를 활용하여 refresh token을 구현하고 보안을 강화합니다.

JWT Refresh Token 구현

## MPA (SSR)

MPA(Multiple Page Application)은 HTML, CSS, Javascript로 만들어지던 초기의 웹 형태입니다. 
과거에는 MPA라는 단어나 개념이 존재하지 않았지만 SPA의 개념이 등장하면서 만들어진 단어입니다. 
각 페이지를 서로 다른 html 파일로 이루어져 있어서 메뉴 이동과 같은 페이지를 접근할 때 새로운 html파일을 받아오는 형식입니다. 
이 방식은 새로운 html파일을 받아오는 동안 로딩 시간을 필요로 했는데, 그 로딩시간동안 페이지가 깜빡 거리게 됩니다.

## SPA의 탄생 (CSR)

MPA방식에서는 모바일 어플리케이션처럼 부드럽지도 않고, 모든 페이지에서 공통되는 부분(헤더, 푸터, 등…)도 계속해서 새로이 불러들어야만 했습니다. 
따라서 기존의 방식에서 특정 부분만 변하고 새로 그리는 방식인 SPA가 탄생하게 되었습니다. 
SPA(Single Page Application)는 MPA와는 달리 단 하나의 페이지로만 웹 어플리케이션을 만듭니다. 
이 구현방식을 CSR(Client Side Rendering)이라 하는데 메뉴 이동을 할 때 모바일 앱처럼 자연스럽게 이동하여 사용자들에게도 친숙하였습니다. 
개발자들에게도 React, Angular, Vue와 같은 기술들이 생겨나면서 기존의 JQuery를 통한 MPA방식보다 코드 관리도 수월해지고(컴포넌트 단위 개발) 구현하기도 쉬워졌습니다. 
또한 Front-End와 Back-End의 관심사를 완전히 분리시켜 REST API방식을 채용하고 개발 속도가 향상되었습니다. 
하지만 이 CSR에도 문제점이 존재합니다. 
페이지 하나만을 이용해 어플리케이션을 구성하기에, 어플리케이션의 크기가 커질수록 초기 로딩시간이 오래걸리게 됩니다. 
또한 javascript를 통해 동적으로 페이지를 변환시키기에 검색엔진은 이 사이트의 내용을 인식하지 못합니다. 
이에 아예 불가능하진 않아도 SEO(Search Engine Optimization)을 적용하기 힘들고, 또한 적용하더라도 불리해서 구글이나 네이버와 같은 검색엔전에서 노출되기 어려웠습니다.

## 다시 MPA (SSR)

SPA의 치명적인 단점들을 해결하면서, 동시에 초기 MPA에서 가졌던 단점들을 해결하는 방식으로 Next.js와 같은 프레임워크들이 등장하기 시작했습니다. 
SPA 방식에서 사용하던 컴포넌트 단위의 개발을 지원하고, 페이지 깜빡임을 pre-rendering기법과 특별한 기술들(nextjs의 Link태그)을 활용해 SPA처럼 부드럽게 구현하였습니다. 
해당 기술들은 Next js 관련 포스팅을 통해 다음번에 다루겠습니다.

렌더링의 간단한 역사와 종류에 대한 설명입니다.

렌더링 종류(CSR, SSR)

[지난 포스트](/post/back-end/api-gateway-zuul-filter)에서는 Netflix Zuul의 ZuulFilter를 활용해 토큰을 검증하는 과정까지 설명하였습니다. 
하지만 토큰을 검증하기 전에는 당연히 토큰을 발급하는 과정이 필요한데, 이번 포스트에선 그 과정에 대해 다루겠습니다.

## jjwt

Spring에서 JWT를 사용하기 위한 라이브러리 입니다. 
JWT에 대한 사전 지식이 부족할 경우 [JWT 포스트](/post/front-end/jwt)를 참조해주세요.

```groovy
dependencies {
	implementation 'io.jsonwebtoken:jjwt:0.9.0'
}
```

사용하기 위해선 gradle이나 maven에 의존성을 추가해야 합니다. 
jjwt를 활용해서 JWT를 생성하거나 혹은 분석할 수 있습니다.

## 로그인 구현

### controller

로그인 컨트롤러를 구현합니다. 
화면단에서 넘어오는 requestBody와 추후에 refresh-token 파트에서 사용할 HttpServletRequest를 받아와줍니다.

```java
@RestController
@RequiredArgsConstructor
public class SignController {
	private final SignService signService;

	@PostMapping("/auth/sign/in")
	public ResponseEntity<SignInResponse> signIn(HttpServletRequest request, @RequestBody SignInRequest requestBody) {
		return ResponseEntity.ok(signService.signIn(request, requestBody));
	}
}
```
### requestDto

requestDto에는 로그인시에 입력하는 아이디와 비밀번호가 포함되어 있습니다.

```java
@Getter
@AllArgsConstructor
public class SignInRequest {
	private String id;

	private String password;
}
```

### responseDto

responseDto에는 프론트엔드로 보내줄 token값과, 상태관리에서 사용할 멤버 이름이나 아이디, 권한 등을 보내줄 수 있습니다. 
해당 데이터들은 Redux와 같은 상태 관리를 통해 클라이언트에서 사용이 가능합니다.

```java
@NoArgsConstructor
@AllArgsConstructor(access = Accesslevel.PRIVATE)
@Builder
@Getter
public class SignInResponse {
	private String memberName;

	private String token;
}
```

### Service

서비스에서는 [decrypt과정](/post/front-end/aes)을 통해 암호를 해독하여 일치하는지 확인합니다. 
그 후 access token을 만들어 보내줍니다. 

```java
@Service
@RequiredArgsConstructor
public class SignService {

	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());
	private static final String AUTH_TOKEN_HEADER_PREFIX = "Bearer ";

	private final BCryptPasswordEncoder passwordEncoder;
	private final JwtUtil jwtUtil;
	private final UserRepository userRepository;

	@Transactional
	public SignResponse signIn(HttpServletRequest request, SignInRequest requestBody) {
		User loginUser = userDao
			.findById(requestBody.getId())
			.filter(user -> passwordEncoder.matches(AesCryptUtil.decrypt(requestBody.getPassword()), user.getPassword()))
			.updateLoginTime();

		String accessToken = jwtUtil.createAccessToken();

		logger.info("{} login success", requestBody.getId());

		return SignInResponse.builder()
			.memberName(loginUser.getMemberName())
			.token(accessToken).build();
	}
}
```

### JwtUtil

JWT를 생성할 때는 어플리케이션의 성격에 맞게 claim값들을 설정할 수 있습니다. 
등록된 클레임(Registered Claim)은 Jwts객체에 setter가 존재하여 이를 통해 설정할 수 있습니다. 
만료 시간(Expiration Time) 클레임은 설정해주어서 만료 시간이 지날 경우 토큰이 폐기되도록 하는 것이 좋습니다. 
jwtUtil에서는 이들을 통해 access-token을 생성해줍니다. 
HashMap을 이용해 body claim을 넣어줄 수 있습니다.

```java
@Component
public class JwtUtil {

	@Value("${jwt.signKey}")
	private String jwtSignKey;

	public String createAccessToken() {
		Map<String, Object> body = new HashMap<>();
		body.put(PublicClaimKey.NAME.getValue(), user.getName());
		body.put(PrivateClaimKey.USER_ID.getValue(), user.getId());

		return this.createToken("accessToken", body, 30);
	}

	public String createToken(String subject, Map<String, Object> body, int expirationTime) {
		LocalDateTime currentTime = LocalDateTime.now();

		Claims claims = Jwts.claims(body);

		return Jwts.builder()
			.setClaims(claims)
			.setSubject(subject)
			.setIssuer("https://oms-tech-blog.netlify.app")
			.setIssuedAt(Date.from(currentTime.atZone(ZoneId.systemDefault()).toInstant()))
			.setExpiration(Date.from(currentTime.plusMinutes(expirationTime).atZone(ZoneId.systemDefault()).toInstant()))
			.signWith(SignatureAlgorithm.HS512, jwtSignKey)
			.compact();
	}
}
```

### enum

공캐 클레임(Public Claim)이나 비공개 클레임(Private Claim)들은 enum등을 활용해서 구현 할 수 있습니다. 
TokenField interface를 이용하면 Claim을 parse하거나 set해줄 때 TokenField 타입을 활용할 수 있습니다.

```java
public interface TokenField {
	String getValue();
}
```

```java
public enum PublicClaimKey implements TokenField {
	NAME("name"),
	NICKNAME("nickname");

	private String value;

	PublicClaimKey(String value) {
		this.value = value;
	}

	public String getValue() {
		return value;
	}
}
```

```java
public enum PrivateClaimKey implements TokenField {
	USER_ID("userId");

	private String value;

	PrivateClaimKey(String value) {
		this.value = value;
	}

	public String getValue() {
		return value;
	}
}
```

원래 refresh token 발급 까지 설명하고 구현하려 하였으나 생각보다 양이 많아져서 한번 더 나누게 되었습니다. 
[다음 포스터](/post/back-end/refresh-token)에서는 access token의 한계점과 refresh token에 대해서 설명하고 구현하도록 하겠습니다.

JWT를 활용해서 access token을 발급하여 로그인을 하는 기능을 구현합니다.

JWT 로그인 방식 구현

[공식문서](https://ko.reactjs.org/docs/conditional-rendering.html) 
React의 jsx 문법에서는 중괄호 `{}` 내에는 자바스크립트의 표현식(Expression)이 들어갈 수 있습니다.

```tsx
const Plus = () => {
	const num1 = 1;
	const num2 = 2;

	return (
		<div>
			{num1} + {num2} = {num1 + num2}
		</div>
	);
};
```

하지만 문장(Statement)이 아닌 표현식이다 보니, if문이나 if-else문, switch문 등이 들어갈 수 없고, 또한 배열이 필요할 때 for문 또한 들어갈 수 없습니다. 
따라서 jsx에서 어떠한 방법으로 조건식을 만들고 그걸로 렌더링을 표현하는지에 대해 알아보도록 하겠습니다.

## 함수 이용

복잡한 렌더링 규칙을 가질 때 사용하는 방법입니다. 
if문 if-else문 등등.. 자유롭게 함수를 작성하고 해당 함수를 불러들이는 방법으로 구현이 가능합니다.

```tsx
interface OwnProps {
	num1: number;
	num2: number;
	condition: '+' | '-' | '*' | '/';
}

const Calculator = ({ num1, num2, condition }: OwnProps) => {

	const Result = () => {
		if(condition = '+') {
			return {num1 + num2};
		} else if(condition = '-') {
			return {num1 - num2};
		} else if(condition = '-') {
			return {num1 * num2};
		} else {
			return {num1 / num2};
		}
	}

	return (
		<div>
			{num1}
			{condition}
			{num2}
			=
			<Result />
			{/*혹은 {Result() } 로 표현하여도 같습니다.*/}
		</div>
	);
};
```

해당 방법의 장점은 복잡한 연산이나 규칙이 필요할 때 함수로 관리를 함으로서 코드 관리가 용이해지고 구현하기도 쉬워집니다. 
하지만 간단한 조건부 렌더링도 전부다 함수를 이용하면 코드가 길어지고 한눈에 보기 어려워 질 수 있습니다.

## if문

간단한 if문에는 논리연산자 `&&` 를 사용합니다. 
`&&`은 논리곱으로 양쪽이 둘다 `true` 일 경우에만 true가 됩니다. 
JavaScript에서 논리곱의 결과는 true && expression === true 가 되고, false && expression === false 가 됩니다. 
예를들면 false && 'banana' === false 이고, true && 'banana' === 'banana'가 됩니다. 
이러한 성질을 이용하여 if문 처럼 사용하여 렌더링을 수행할 수 있습니다.

```tsx
interface OwnProps {
	admin: boolean;
}

const Main = ({ admin }: OwnProps) => {
 return (
 <div>
 <Content />
 {admin && <Admin />}
 </div>
 )
}
```

위의 컴포넌트에서는 만약 admin값이 true이면 Admin컴포넌트가 렌더링 될 것 이고, 
그 반대로 false라면 Admin컴포넌트는 렌더링 되지 않을 것입니다.

## if-else문

if-else문에는 삼항연산자를 사용하여서 나타내줍니다. 
로그인이 되어있을 땐 로그아웃 버튼을, 반대의 경우에는 로그인 버튼을 렌더링 할 수 있습니다.

```tsx
interface OwnProps {
	login: boolean;
}

const LoginMenu = ({ login }: OwnProps) => {
	return <div>{login ? <LogoutButton /> : <LoginButton />}</div>;
};
```

## for문

for문은 javascript의 [Array.map()](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/map) 메서드를 활용하여 구현해줍니다. 
배열 내의 요소 각각에 대해 새로운 결과 배열을 반환하는 메서드입니다. 
`Array.forEach()`와는 return값이 있나 없나 차이만 존재합니다. 
`arr.map(callback(currentValue[, index[, array]])[, thisArg])` callback함수의 인자로 currentValue와 index 그리고 array가 포함됩니다.

```ts
const fruits = [
	apple: {
		kor: '사과',
		en: 'apple',
	},
	banana: {
		kor: '바나나',
		en: 'banana',
	},
];

const korNames = fruits,map((fruit, index) => fruit.kor);

console.log(korNames); // ['사과', '바나나']
```

위의 예시처럼 기존의 배열로 새로운 배열을 만들 수 있습니다. 
JSX에서도 마찬가진데 배열을 이용해 React.ReactNode배열 결과를 만들어 냅니다.

```tsx
const nameList = ['철수','영희','길동'];

const NameCard = () => {
	return (
 <div>
 {nameList.map((name, index) => (
 {name}
 ))}
 </div>
 );
}
```

### Key

[공식문서](https://ko.reactjs.org/docs/lists-and-keys.html) 
표현식으로 배열 컴포넌트를 생성할 때 각종 IDE나 혹은 eslint에서 key를 넣어주지 않으면 경고문이 나옵니다. 
key에는 문자열이 들어갈 수 있습니다. 
key는 리스트 컴포넌트가 생성될 때 React에서 리스트이 요소들을 식별하기 위한 요소입니다. 
다른 기능은 존재하지 않으며 오로지 리렌더가 일어날 때 해당 key의 컴포넌트들을 비교하며 효율적인 리렌더링을 수행합니다. 
key를 사용할 때에는 조심해야할 점이 2가지 있습니다.

-	key는 형제끼리 같은 값을 가지면 안됩니다.

```tsx
const Example = () => {
	const [list1, setList1] = useState([1,2,3,4,5]);
	const [list2, setList2] = useState([5,6,7,8,9]);

	return (
		<div>
			{list1.map((item) => (
				
					{item}
				
			))}
			{list2.map((item) => (
				{item}
			))}
			}
		</div>
	);

	const onClickList1 = (event) => {
		// 클릭된 요소를 삭제합니다.
		setList1((prev) => prev.filter((element) => element !== event.target.innerText);
	};
}
```

만약 위와 같은 컴포넌트가 있을 때, 총 10개의 엘리먼트들이 생깁니다. 
여기서 key값을 배열의 값으로 주었더니 `5` 라는 key값이 겹치게 됩니다. 
React는 setState를 진행하고 리렌더가 일어날 때 key가 5인 엘리먼트가 사라져야 한다는걸 압니다. 
하지만 key가 5인 엘리먼트는 2개가 있고, 그 결과로 어떻게 동작할지 예상할 수 없게 되버립니다. 
**주의 같은 렌더 함수 내에서 두개 이상의 리스트 엘리먼트가 존재할 때 반드시 서로 다른 고유한 key값을 주어야 합니다.**

-	index 사용을 지양해야 합니다.

리스트 엘리먼트가 한번 렌더된 후 변경사항이 아예 없다면 index를 key로 주어도 무방합니다. 

```tsx
list.map((item, index) => <Item {...item} key={index} />);
```

하지만 위처럼 key에 index로 값을 부여하고 해당 리스트가 추가되거나 삭제되거나 순서가 바뀔 가능성이 있을 때 마찬가지로 사람이 예측하지 못한 동작이 일어날 수 있습니다. 
그 이유는 React는 key값에 따라 컴포넌트의 변화점을 찾기 때문입니다.

### 배열이 존재할 때

Post라는 컴포넌트가 있을 때, 해당 컴포넌트는 댓글을 배열로 받게 될겁니다. 
이럴 경우 댓글을 for문으로 렌더링 시켜줘야 합니다. 
key값으로는 엘리먼트가 가진 고유한 id값을 주면 좋습니다.

```tsx
interface OwnProps {
	title: string;
	content: string;
	comments: Comment[];
}

const Post = ({ title, content, comments }) => {
	return (
		<div>
			<h2>{title}</h2>
			<Content>{content}</Content>
			{comments.map((comment, index) => (
				<Comment index={index} key={comment.id}>
					{comment}
				</Comment>
			))}
		</div>
	);
};
```

### 배열이 존재하지 않을 때

배열이 존재하지 않는 경우에는 `Array(배열 숫자).fill(null).map((item) => … )` 이와 같은 형태로 배열을 생성해서 사용할 수 있습니다. 
`fill(value)` 메서드는 배열의 값들을 value로 채워주는 역할을 합니다. 
fill 메서드를 사용하지 않으면 배열의 값은 undefined 으로 되어있고, undefined는 map의 대상이 되지 않습니다. 
따라서 메모리를 가지지 않는 `null`로 초기화 해주는게 좋습니다.

```tsx
interface OwnProps {
	num: number;
}

const MultipleTable = ({ num }: OwnProps) => {
	return (
		<div>
			{Array(9)
				.fill(null)
				.map((item, index) => (
					{num * (index + 1)}
				))}
		</div>
	);
}
```

하지만 위의 방법에는 key로 고유한 데이터를 줄 수 없습니다. 
배열의 변화 가능성이 있을 경우에는 이 방법은 좋지 않은 방법입니다. 
배열을 새로이 만들어서 코드를 작성하는 것이 좋습니다. 
커뮤니티에서는 일부는 uuid와 같은 난수를 사용해 key를 부여하는 방법도 좋다고 합니다. 
하지만 개인적인 생각으로는 리렌더 될 때마다 새로운 uuid값을 제공해야 하고, 새로운 JSX element들을 만들어줘야 하니 비효율적 이라고 생각합니다.

React JSX 문법에서 if문, else문, for문의 사용법입니다.

리엑트 JSX 조건문 렌더링

요즘에는 많은 웹 서비스들이 SPA를 구현하면서 프론트엔드와 백엔드 사이의 역할이 확연하게 나뉘고, 
동시에 세션을 사용하기 힘들어지면서 token을 이용한 인증이 많이 구현됩니다. 
그러면서 가장 많이 사용하는 인증 방식이 JWT를 통한 인증 방식입니다.

## JWT

[공식문서](https://jwt.io/introduction)
JWT는 Json Web Token의 약자로 Json을 이용해 정보를 안전하게 다루기 위한 개방형 표준 (RFC 7519) 방법입니다. 
내용들은 Claim들로 이루어 지는데, 각 Claim들은 Json처럼 이름과 값의 쌍으로 이루어져 있습니다. 
예를 들면 Claim의 이름이 name이면 값은 유영진이 될 수 있습니다. 
이 Claim들을 이용해서 필요한 데이터들을 Json 형태로 담아 토큰으로 변경합니다.

## Base64Url

Base64 인코딩은 `+`, `/`, `=`이 포함됩니다. 
Base64는 2진 데이터를 6bit 단위로 쪼개고 해당 문자열을 ASCII 값으로 치환해주는데 `+`는 62, `/`는 63에 해당합니다. 
또한 Base64는 3byte씩 쪼개서 인코딩을 하는데 이 때 3byte가 안되는 경우에는 padding 문자열로 빈 공간을 채우게 됩니다. 
여기서 Base64는 `=`을 padding문자열로 사용합니다. 
따라서 URI의 파라미터로 사용할 수 없게 되는데, JWT는 토큰값을 URI 파라미터로 사용할 수 있도록 Base64Url 인코딩을 사용합니다. 
Base64Url에서는 `-`(minus)는 62, `_`(underline)은 63에 해당합니다. 
하지만 padding문자열은 그대로 `=`을 사용합니다. 
그 이유는 패딩 문자열은 문자열 맨 마지막에 존재하게 되니 브라우저가 제어문자로 인식하지 않고 그냥 문자로 인식하기 때문입니다.

## 구조

JWT의 구조는 3개의 파트로 나뉘고, 각 파트는 점으로 구분합니다. 

-	Header
-	Payload
-	Signature

따라서 JWT는 아래와 같은 모습이 됩니다. 
`xxxxx.yyyyy.zzzzz`

### Header

헤더(Header)는 토큰의 타입과 알고리즘 2가지로 구성되어 있습니다. 
토큰의 타입은 JWT, 알고리즘은 HMAC이나 SHA256, RSA같은 알고리즘으로 들어갑니다.

```json
{
	"alg": "HS256",
	"typ": "JWT"
}
```

### Payload

페이로드(Payload)는 토큰에 담을 클레임(Claim)들을 담는 부분입니다. 
클레임의 종류는 아래 3가지가 있습니다.

#### Registered claims(등록된 클레임)

필수는 아니지만 유용하고 상호 작용이 가능한 클레임들이 미리 정의되어 있습니다. 
해당 클레임들을 등록된 클레임 부분에 정의해줍니다. 
[등록된 클레임 종류](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1)

-	iss

	iss는 발급자(issuer) 클레임 입니다. 
	보통은 어플리케이션에 따라 어플리케이션 이름이나 URI등을 넣습니다. 
	문자열을 값으로 가집니다.

-	sub

	sub는 주제(Subject) 클레임 입니다. 
	주제 클레임값은 지역적이나 전역적으로 고유한 값을 가집니다. 
	문자열을 값으로 가집니다.

-	aud

	aud는 수신자(audience) 클레임 입니다. 
	수신자 클레임은 JWT가 의도한 수신자인지를 식별합니다. 
	해당 클레임으로 의도한 수신자가 아닐경우 JWT를 거부할 수 있습니다. 
	aud에는 단일 문자열이나 혹은 문자열 배열이 들어올 수 있습니다.

-	exp

	exp는 만료 시간(Expiration Time) 클레임 입니다. 
	JWT가 만료되는 시간을 설정할 수 있습니다. 
	exp시간이 현재시간보다 지나게 되면 JWT를 거부합니다. 
	시간은 NumericDate형식으로 `1480849147370`같이 지정합니다.

-	nbf

	nbf는 Not Before클레임 입니다. 
	JWT가 처리되면 안되는 이전 시간을 설정할 수 있습니다. 
	nbf시간이 현재시간보다 더 크면 JWT를 거부합니다. 
	마찬가지로 NumericDate형식으로 지정합니다.

-	iat

	iat는 발급 시간(Issued At)클레임 입니다. 
	JWT가 발급되는 시간을 식별합니다. 
	이 클레임으로 JWT의 수명을 결정할 수 있습니다. 
	마찬가지로 NumericDate형식으로 지정합니다.

-	jti

	jti는 JWT ID 클레임 입니다. 
	해당 클레임은 JWT에 고유 ID를 제공합니다. 
	해당 클레임을 사용할 때 각 JWT는 겹치지 않는 고유한 ID값을 가지도록 방지해야 합니다. 
	ID값ㅇ로 구분하여 JWT를 거부할 수 도 있습니다. 
	문자열을 값으로 가집니다.

#### Public claims(공개 클레임)

공개 클레임은 사용자들이 클레임을 마음대로 정의하면서 사용할 수 있습니다. 
하지만 충돌을 방지하고자 [IANA JSON Web Token Registry](https://www.iana.org/assignments/jwt/jwt.xhtml)에 등록된 이름으로 사용하거나, 혹은 해당 이름을 포함한 URI로 정의해야 합니다.

#### Private claims(비공개 클레임)

비공개 클레임은 사용자들 간에 협의하에 사용하는 사용자 정의 클레임 입니다.

```json
{
	"sub": "1234567890",
	"name": "John Doe",
	"admin": true
}
```

위의 페이로드에선 sub는 지정된 클레임, name은 공개 클레임, admin은 비공개 클레임에 해당합니다.

### Signature

서명(Signature)부분은 헤더에 지정된 알고리즘을 가져와서 그 알고리즘에 맞게 서명해야 합니다. 
서명은 헤더의 인코딩값과 정보의 인코딩값을 합친 후 주어진 비밀키로 해쉬를 하여 생성합니다. 
예르들어 HMAC SHA256 알고리즘을 사용한 경우는 아래와 같이 만들어집니다. 
`HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)` 
서명은 도중에 메시지가 변경되었는지 확인하는데 사용하며, 개인 키로 서명된 토큰의 경우는 JWT 발신자를 확인할 수 있습니다.

## 결과

결과로는 페이로드가 인코딩되고 암호로 서명된 JWT가 생성됩니다.
![jwt-result size:800*400](/front-end/jwt-result.png)
위의 이미지처럼 JWT는 Encode됩니다. 
[jwt debug](https://jwt.io/) 해당 페이지로부터 직접 JWT의 encode, decode 결과를 볼 수 있습니다.

JWT (Json Web Token)

[지난번 포스트 API Gateway](/post/back-end/api-gateway)에 이어 활용하는 내용입니다. 
Netflix Zuul을 API Gateway로 사용하면서 ZuulFilter를 활용하여 JWT인증을 구현합니다. 
Gateway에 인증을 구현함으로서, 각 서비스는 자신의 역할에만 집중하여 로직을 구현할 수 있고, 공통된 인증 시스템을 구현할 수 있습니다.

## Filter 작성

```java
@Configuration
public class JwtFilter extends ZuulFilter {
	
	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());

	@Override
	public String filterType() {
		return FilterConstants.PRE_TYPE; // "pre"를 return합니다.
	}

	@Override
	public int filterOrder() {
		return 0;
	}

	@Override
	public boolean shouldFilter() {
		return true;
	}

	@Override
	public Object run() {
		return null;
	}
}
```

**shouldFilter**와 **run**부분은 아래에서 작성하고, 
filterType은 API 서버로 라우팅 되기 전에 인증을 수행하고 그에 따라서 라우팅을 취소하거나 해야하니 **pre**로 해줍니다. 
filterOrder는 0으로 가장 먼저 등록되게 하겠습니다.

## shouldFilter

shouldFilter부분은 인증을 수행할지 말지를 결정해야 합니다. 
대부분의 로직은 인증을 수행해야 하지만 회원가입, 로그인 아이디 찾기 등 토큰을 발급받기 전에 수행해야할 로직들은 인증을 하면 안됩니다. 
또한 HTTP Method의 OPTIONS는 통신 옵션만 요청하여 가능 여부만 검사하니 이 또한 인증을 하지 않습니다.

```java
@Override
public boolean shouldFilter() {
	RequestContext context = RequestContext.getCurrentContext();

	if ("OPTIONS".equals(context.getRequest().getMethod())) {
		return false; // OPTIONS는 인증을 하지 않습니다.
	}

	List<String> whiteList = getWhiteList();
	// HttpServletRequest의 getRequestURI는 쿼리 param을 제외한 컨텍스트 경로부터 가져옵니다.
	if (whiteList.contains(context.getRequest().getRequestURI())) {
		return false;
	}

	return true; 
}

private List<String> getWhiteList() {
	return List.of("/auth/sign", "/auth/user/id");
}
```

**getWhiteList** 메서드를 이용해서 인증을 거치지 않을 URI들을 가져옵니다. 
해당 기능은 DataBase 구조에 따라서 Service를 거쳐서 DB로 부터 가져와도 되고, 
혹은 Enum을 활용하거나 혹은 위의 예시처럼 직접 String을 넣어도 됩니다. 
Http Method까지 포함하여 객체를 만들어 비교하는 방법도 가능합니다. 
여기선 테스트 코드로 직접 String을 넣었습니다.

## run

이 부분에선 실제 인증 과정을 작성해줍니다. 
API 요청으로부터 JWT 토큰을 가져오고 해당 토큰을 parse해서 문제가 있는지 확인합니다.

```java
@Configuration
public class JwtFilter extends ZuulFilter {
	private final Logger logger = (Logger) LoggerFactory.getLogger(this.getClass());

	// Value 어노테이션은 properties나 yml파일로부터 설정값을 가져옵니다. cloud config server를 만들어 값을 숨길 수 있습니다.
	@Value("${jwt.signKey}")
	private String jwtSignKey;
	......
}
```

field부분에 JWT의 signKey를 가져오는 코드를 추가합니다.

```java
@Override
public Object run() throws ZuulException {
	try {
		RequestContext requestContext = RequestContext.getCurrentContext();
		String jwt = requestContext.getRequest().getHeader("Authorization")
			.substring(7); // "Bearer "의 크기만큼 제거
	
		Claims claims = Jwts.parser().setSigningKey(jwtSignKey).parseClaimsJws(jwt).getBody();
	} catch (ExpiredJwtException ex) {
		// 토큰의 기간이 지난 경우입니다. Refresh 토큰을 활용할 경우 여기서 처리할 수 있습니다.
		this.requestRefreshToken();
	} catch (UnsupportedJwtException | MalformedJwtException | SignatureException ex) {
		// jwt의 구조가 잘못되거나, 서명에 실패할 경우입니다. 
		logger.warn("Bad Request" + ex.getMessage());
		throw new ZuulException("Bad token", HttpStatus.BAD_REQUEST.value(), ex.getMessage());
	} catch (Exception ex) {
		logger.warn("Something wrong in gateway" + ex.getMessage());
		throw new ZuulException("Something wrong in gateway", HttpStatus.INTERNAL_SERVER_ERROR.value(), ex.getMessage());
	}
	return null;
}

private void requestRefreshToken() {
	// auth 서비스로 URI를 변경하여서 refresh 토큰을 얻는 시도를 하도록 변경합니다.
	RequestContext context = RequestContext.getCurentContext();
	context.getRequest().setAttribute(WebUtils.INCLUDE_REQUEST_URI_ATTRIBUTE, "/auth/refresh");
}
```

토큰에 대해 인증을 수행하고 expired 될 경우에는 refresh 토큰을 얻을 수 있는지 auth 서비스에 요청합니다. 
그 이외의 인증에 실패할 경우에는 Exception을 일으켜서 요청을 취소하고 로그를 남깁니다. 
다음 포스트에는 auth 서비스에서 로그인을 통해 토큰을 발급받고, 또한 refresh 토큰을 발급받는 과정을 설명하겠습니다.

Netflix Zuul의 ZuulFilter를 이용하여 JWT 인증 구현합니다.

Netflix Zuul을 활용하여 JWT 인증 구현

처음에 MSA프로젝트에 투입되었을 때 Front-end에서는 Request Header를 넣어주는 코드가 없었는데, 
로컬 환경이 아닌 개발 환경에서만 Request Header가 들어가서 당황했었던 적이 있었습니다. 
API Gateway는 각각의 요청을 일괄처리 해주는 Gateway(관문) 역할을 하면서 다양한 역할을 수행할 수 있는 MSA에서 중요한 서비스입니다. 

## 특징

-	인증 및 권한 부여
-	서비스 검색 통합
-	응답 캐싱
-	정책, 회로차단기 및 QoS 다시 시도
-	속도 제한
-	부하 분산(load balance)
-	로깅, 추적, 상관 관계
-	헤더, 쿼리 문자열 및 청구 변환
-	IP 허용 목록에 추가

## Netflix Zuul

Spring Cloud의 Netflix Zuul은 Spring 2.4버전 이후부터는 더이상 지원하지 않습니다. 
현재 OMS에서는 Netflix Zuul을 Gateway로 사용중이며, 그 이후 버전의 프로젝트에서는 Spring Cloud Gateway를 적용해야 합니다.

## Setting

### Eureka

먼저 Gateway를 만드려면 Eureka Server에 등록을 해야 합니다. 
Gateway는 이를 통해 Eureka로부터 serviceId와 그곳의 EndPoint를 알게 되고,
적절하게 Load Balance를 할 수 있습니다.

```java
@SpringBootApplication
@EnableZuulProxy
@EnableEurekaClient
public class GatewayApplication {
	public static void main(String[] args) {
		SpringApplication.run(GatewayApplication.class, args);
	}
}
```

```yml
 ## bootstrap.yml
eureka:
	client:
		serviceUrl:
			defaultZone: http://localhost:8081/eureka/
		registerWithEureka: true
		fetchRegistry: true
```

### zuulRoutes

zuul Routes는 정해진 path 규칙에 따라서 알맞는 서비스 명으로 보내줄 수 있습니다.

```yml
 ## application.yml
zuul:
	ignored-services: '*'
	sensitive-headers:
	routes:
		auth-service:
			path: /auth/**
			serviceId: auth-service
			stripPrefix: false

		main-service
			path: /main/**
			service: main-service
			stripPrefix: false
```

-	ignored-services

	자동 생성에서 제외할 서비스들을 지정해줍니다.

-	sensitive-headers

	내부에서 사용되는 헤더값이 노출되는 것을 막아줍니다.

-	routes

	path에 맞는 조건의 API 요청들을 eureka에 등록된 serviceId로 zuul이 검색하여 알맞는 서비스에 API요청을 보내줍니다.

- stripPrefix

 false일 경우에는 API가 서비스로 넘어갈때 **앞의 내용들도 넘어갑니다. 
 반면에 true이면 넘어가지 않습니다.

## ZuulFilter

ZuulFilter는 Gateway에서 서비스로 요청을 보내기 전, 거치게 되는 서비스입니다. 
이곳에서 Jwt토큰을 확인하는 로직 등을 넣을 수 있습니다.

```java
@Configuration
public class TestFilter extends ZuulFilter {
	@Override
	public String filterType() {
		return "pre";
	}

	@Override
	public int filterOrder() {
		return 0;
	}

	@Override
	public boolean shouldFilter() {
		return true;
	}

	@Override
	public Object run() {
		return null;
	}
}
```

-	filterType

	filterType은 필터의 타입, 적용 시점을 설정하는 메서드입니다. 
	총 4가지의 타입이 있습니다.

	1.	pre

		API 서버로 라우팅 되기 전에 수행하는 필터(인증, 로깅 등..)

	2.	routing

		요청에 대한 라우팅을 제어하기 위해 수행하는 필터(Ribbon)

	3.	post

		API 서버로 라우팅 된 후 수행하는 필터(HTTP Header 추가 및 데이터 수집)

	4.	error

		앞 단계 필터들에서 발생된 오류 수행 필터(Exception)

-	filterOrder

	filterOrder는 여러개의 filter를 사용할 때, filter의 등록 순서를 정해줍니다. 
	0부터 순서대로 Filter가 적용됩니다.

-	shouldFilter

	shouldFilter는 해당 필터를 적용시킬지 말지 결정해주는 메서드입니다.

	```java
	// RequestContext는 요청되는 API 정보를 담고 있는 객체 입니다.
	RequestContext context = RequestContext.getCurrentContext();

	String url = context.getRequest().getRequestURI();
	if(whiteList.contains(url)) return false;
	return true;
	```

	위의 예시처럼 whiteList의 값이 들어올 경우 filter를 미적용 시키는 방법으로 사용할 수 있습니다.

-	run

	실제 동작을 하는 부분입니다. 
	어떠한 인증을 하거나 혹은 request에 새로운 값을 추가해줄 수 도 있고, Exception을 일으켜서 예외처리 등에도 사용할 수 있습니다.

Netflix Zuul을 이용한 API Gateway의 역할과 구성 방법

Netflix Zuul(API Gateway)

## AES

암호화를 하는 방식에는 단방향 암호화, 비밀키 암호화, 공개키 암호화가 있는데, 그중 AES는 비밀키 암호화 입니다. 
많은 곳에서 AES를 사용하고 있습니다.

## Padding

패딩(Padding)이란 데이터를 블럭으로 암호화할 때 평문이 항상 블럭크기의 갯수가 될 수 없습니다. 
따라서 평문의 마지막 블록을 암호화 되기 전에 어떠한 데이터로 남은 공간을 채워주는 방식입니다. 
AES에서는 PKCS 패딩을 사용하는데, 이 방식은 예를들어 16바이트의 평문 중 3바이트가 비어있다면 3바이트를 모두 05로 채우는 방식입니다. 
PKCS#5와 PKCS#7 두가지가 있는데, 구현 되는 방식은 둘다 같고 다만 PKCS#5는 8바이트 고정, PKCS#7은 바이트가 고정되어있지 않습니다. 

### Mode

모드(Mode)는 블럭 암호화 순서 및 규칙에 대한 표준입니다. 
모드에 따라서 IV(초기화 벡터)를 사용할 수도 있고, 사용하지 않을수도 있습니다. 
일반적으론 CBC(Cipher-Block Chaining)모드가 가장 많이 사용됩니다. 
이 모드는 최초 평문 1블럭과 IV를 XOR 연산한 다음 암호화하고, 다음 평문 1블럭은 앞에서 암호화된 결과 블럭과 XOR하여서 다시 암호화 하는 방식입니다.

### PBKDF2

PBKDF는 Password-Based Key Derivation Function입니다. 
만약에 키 값을 탈취당했을 때를 고려하여서 키 값을 늘려버리고 암호화의 횟수를 여러번으로 늘려서 움호화의 수행 시간을 오래 걸리게 해줍니다. 
이 과정을 키 확장이라 하고, 외부 공격으로 부터 비교적 안전하게 해줍니다. 
salt와 반복횟수를 지정해주어서 새로운 결과값을 만들어냅니다. 
`salt`란 해시함수를 돌리기 전에 임의의 문자열ㅇㄹ 덧붙이는 것을 의미합니다.

## cryptoJS

cryptoJS는 javascript의 표준 및 보안 암호화 알고리즘 구현 라이브러리입니다. 
일반적인 사용법은 `CryptoJS.AES.encrypt('변화할 데이터','비밀키', { mode: '모드', padding: '패딩', iv: '초기화벡터' })`의 구조로 사용됩니다.

```js
const key = {
	iv: '...', // 32바이트(크기)의 문자열 초기화 벡터
	sa: '...', // 32바이트(크기)의 문자열 salt
	pa: '...', // 32바이트(크기)의 문자열 비밀키
};

const encrypt = (value: string, use: boolean = true) => {
	if(!use) return value;
	return ((CryptoJS) =>{
		return CryptoJS.AES.encrypt(
			value,
			// 비밀키에 PBKDF2를 적용하여 비밀키를 암호화합니다.
			// CryptoJS.PBKDF2('암호키', 'salt', { keySize: 키사이즈, iterations: 반복횟수 })
			CryptoJS.PBKDF2(key.pa, CryptoJS.enc.Hex.parse(key.sa), { keySize: 4, iterations: 1000 }),
			// mode는 default로 'CBC', padding은 default로 'Pkcs7'이 됩니다.
			{
				iv: CryptoJS.enc.Hex.parse(key.iv)
			}
		).toString();
	})(window['CryptoJS']);
};
```

## in java

java에서는 위의 암호화 결과를 decrypt(해독)하고 있습니다. 

```java
public static final String ENC_KEY = "..."; // cryptojs의 pa와 동일한 비밀키
public static final String salt = "..."; // cryptojs의 sa와 동일한 salt
public static final String iv = "...";// cryptojs의 iv와 동일한 초기화 벡터

private static String decrypt(String salt, String iv, String passphrase, String ciphertext, int iterationCount, int keySize) throws Exception {
	SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
	// 반복횟수와 키 사이즈를 설정하고 salt를 이용해 KeySpec을 만듭니다.
	KeySpec spec = new PBEKeySpec(passphrase.toCharArray(), Hex.decodeHx(salt.toCharArray()), iterationCount, keySize);
	// KeySpec을 적용해 PBKDF2 방식으로 암호화된 비밀키를 만들어줍니다.
	SecretKey = key = new SecretKeySpec(factory.generateSecret(spec).getEncoded(), "AES");
	// PKCS5Padding의 Instance를 불러오지만, PKCS#7과 로직이 일치하여 해당 인스턴스만 존재합니다.
	Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
	// CBC모드로 IV를 적용하여서 해독합니다.
	cipher.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(Hex.decodeHex(iv.toCharArray())));
	byte[] decrypted = cipher.doFinal(Base64.decodeBase64(ciphertext));
	return neew String(decrypted, "UTF-8");
}
```

AES란 무엇인지, CryptoJS와 java에서 암호화 복호화 방법

AES 암호화

DI(Dependency Injection)는 의존성 주입으로, 하나의 객체가 다른 객체의 의존성을 제공하는 기술입니다. 
클래스 레벨에서는 의존관계가 고정되지 않고 런타임 시에 관계를 동적으로 주입해주어서, 
유연성을 확보하고 결합도를 낮출 수 있게 해줍니다.

## 의존성 주입 방법

Spring에서 의존성을 주입하는 방법에는 3가지가 있습니다. 
결론부터 말하면 생성자 주입 방법을 사용하는 것이 좋습니다.

### 생성자 주입

```java
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	// Class내 생성자가 하나뿐이면 @Autowired 생략 가능
	@Autowired
	public ExampleController(ExampleService1 service1, ExampleService2 service2) {
		this.service1 = service1;
		this.service2 = service2;
	}
}
```

생성자 주입은 생성자 호출 시점에 1회 호출 되는 것이 보장되어서, 주입받은 객체가 변하지 않게 됩니다.

### 필드 주입

```java
@Controller
public class ExampleController {
	@Autowired
	private final ExampleService1 service1;
	@Autowired
	private final ExampleService2 service2;
}
```

필드 주입은 코드가 간결해지고 유지보수가 편해지는 장점이 있습니다. 
하지만 외부에서 접근이 불가능하다는 단점이 있습니다. 
또한 반드시 Spring과 같은 DI 프레임워크가 존재해야 하기 때문에 사용을 지양합니다.

### Setter 주입

```java
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	@Autowired
	public void setService1(ExampleService1 service1) {
		this.service1 = service1;
	}

	@Autowired(required = false)
	public void setService2(ExampleService2 service2) {
		this.service2 = service2;
	}
}
```

Setter 주입은 생성자 주입과 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용합니다. 
@Autowired 어노테이션은 주입할 대상이 없는 경우에는 오류가 발생합니다. 
따라서 주입할 대상이 없어도 동작하도록 하려면 requried = false를 이용해 설정할 수 있습니다.

## Lombok 활용

생성자 주입은 필드 객체에 final 키워드를 사용할 수 있습니다. 
Lombok의 @RequiredArgsConstructor를 활용하면, 
final 변수를 위한 생성자를 대신 생성해줍니다. 
이를 활용하면 새로운 객체를 추가하거나 기존 객체를 삭제할 때 등등… 
유지보수가 간결해지며 코드 작성시에도 간편해집니다.

```java
// 변경 전
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;

	public ExampleController(ExampleService1 service1, ExampleService2 service2) {
		this.service1 = service1;
		this.service2 = service2;
	}
}

// 변경 후
@RequiredArgsConstructor
@Controller
public class ExampleController {
	private final ExampleService1 service1;
	private final ExampleService2 service2;
}
```

변경 전과 변경 후의 코드가 동일한 생성자 주입을 하는 코드가 됩니다. 
코드 작성이 편해지면서 수정이 적어집니다.

Spring에서 DI(의존성 주입)을 하는 방법입니다.

의존성 주입(DI)

[공식문서](https://immutable-js.com/) 
immutable이란 불변이란 뜻입니다. 
javaScript에서는 원시타입들은 변경이 불가능하지만, 그 이외에는 모두 변경이 가능한 값들입니다. 
변경이 가능한 값들은 메모리 주소를 참조하고 있기 때문에 값이 변경될 경우 해당 값을 사용하는 모든 곳에서 side effect가 발생하게 됩니다.

## 값의 불변성

```js
// javaScript에서 string은 원시타입입니다.
let immutable = 'text';
// 원시타입은 값을 재할당 할 수는 있어도 변경할 순 없습니다.
immutable = 'abcd';

// 참조타입은 메모리만을 참조하므로 값이 변경 가능합니다.
const mutable = {
	one: '1',
	two: '2',
};

mutable.two = '3';

// 따라서 참조타입에서 불변성을 가지려면 새로운 객체를 만들어서 재할당을 해야합니다.
let reallocation = {
	one: '1',
	two: '2',
};

reallocation = {
	one: '1',
	two: '3',
};

// 혹은 깊은 복사를 활용하여 주소값이 다른 객체를 생성 후 값을 변경해야 합니다.
const originObject = {
	one: '1',
	two: '2',
};

const copyObject = { ...originObject, two : '3' };
```

## 복잡한 구조의 객체

다행히도 구조가 간단한 객체의 경우에는 깊은복사를 통한 불변성 유지가 쉽습니다. 
하지만 객체가 복잡한 경우에는 복사 또한 어려워집니다.

```js
const object1 = {
	name: 'object1',
	item: {
		phone: '아이폰',
		car: '제네시스',
	},
};

const object2 = { ...object1 };

object1.item.phone = '갤럭시';
console.log(object2.item.phone); // 갤럭시
```

위의 예시처럼 깊은 복사를 하였음에도 불구하고 object1내의 item은 얕은 복사가 이루어 집니다. 
이러한 객체를 깊은복사 하기 위해선 아래와 같이 해야합니다.

```js
const object1 = {
	name: 'object1',
	item: {
		phone: '아이폰',
		car: '제네시스',
	},
};
// 객체 내의 item도 깊은 복사를 해야 합니다.
const object2 = { ...object1, item: { ...object1.item }};

// 혹은 문자열로 변환하였다가 다시 객체로 변환할 수 있습니다.
const object3 = JSON.parse(JSON.stringify(object1));
```

하지만 객체가 복잡해질수록, 혹은 데이터의 구조를 확실히 알지 못할수록 깊은 복사를 이용하기 힘들어 집니다. 
문자열로 변환하는 방법 또한 필요 이상의 연산 작업이 들어가고 좋은 방법은 아닙니다.

## immutable js 적용

immutable js는 List,Map,Stack,Set등의 데이터 구조를 제공해줍니다. 
불변 컬렉션으로 값의 변경을 불가능 하게 하면서 대신에 재할당을 하도록 합니다. 
또한 Batching Mutations와 Lazy Seq기능으로 인해 성능 향상을 기대할 수 있습니다. 

-	Batching Mutations

	반환을 하기 전에 데이터의 변화가 여러번 일어난다면, 새로운 컬렉션을 생성하지 않고 반환을 할 때만 새로운 불변 컬렉션을 생성합니다.

-	Lazy Seq

	연쇄작업 (filter, map 등...)이 있을 경우에 새로운 컬렉션을 생성하지 않고 필요한 만큼만 연산해줍니다.

반면에 적용할 때의 단점도 존재합니다. 
라이브러리를 추가함으로서 패키지의 사이즈가 커지게 되고, 뿐만 아니라 새로운 데이터 구조의 학습을 해야만 합니다.

### Map

자바스크립트의 object와 비슷합니다. 
다만 값을 변경할 때, 직접할당을 하지 않고 메서드를 통해 새로운 객체를 생성해줍니다.

```js
import { Map } 'immutable';

const testMap = Map({
	one: 1,
	two: 2,
	three: Map({
		four: 4,
		five: 5,
	}),
});

// object의 testMap.one = 10; 과 비슷하나 새로운 객체를 return합니다.
const newMap1 = testMap.set(one, 10);
// depth가 존재할 경우 setIn 메서드로 depth를 표현합니다.
const newMap2 = testMap.setIn([three, four], 40);
// 여러개의 값을 동시에 변경할 땐 mergeIn을 사용합니다.
const newMap3 = testMap.mergeIn([three], {four: 40, five: 50 });
```

### List

마찬가지로 자바스크립트의 []와 비슷합니다.

```js
import { Map, List } from 'immutable';

const testList = List([Map({ test: 1 }), Map({ test: 2 })]);

// get 메서드를 사용해서 n번째 원소값을 가져옵니다.
const element1 = testList.get(0);
// List내의 Map을 가져오려면 다음과 같이 사용합니다.
const element2 = testList.get([0, 'test']);
// n번째 원소값을 수정할 땐 set을 사용합니다.
const newList1 = testList.set(0, Map({ test: 3 }));
// n번째 원소의 내부 값을 변경할 땐 setIn을 사용합니다.
const newList2 = testList.setIn([0, 'test'], 3);
// 아이템을 추가할 땐 push를 이용합니다.
const newList3 = testList.push(Map({ test: 4 }));
// 아이템을 제거할 때는 delete를 사용합니다.
const newList4 = testList.delete(0);
```

### fromJS

fromJS를 사용하면 javascript의 참조객체를 immutable의 Map과 List로 알맞게 변환하여 eturn 해줍니다. 
이를 활용하면 사용방법을 익히지 않고도 활용하기 쉽습니다.

```js
const testMap = fromJS({
	a : 1,
	b : 2,
	c : {
		d: [4,5],
	}
});
```

### toJS

fromJS의 반대로 immutable의 불변객체를 javascript의 참조객체로 변환해줍니다.

## React에서 활용

React에서 리렌더가 일어날 때는 state나 props가 변경될 때 리렌더가 일어나게 됩니다. 
하지만 state나 props가 참조형일 때에는 내부 데이터가 변경되도 주소값은 그대로이기 때문에 리렌딩이 일어나게 되지 않습니다. 
값이 변동될 일이 없을 떈 적용하지 않아도 되고, 데이터 구조가 간단하다면 깊은 복사를 활용하면 됩니다. 
하지만 때에 따라서는 불변객체를 적용해야 좋습니다.

불변객체를 만들어주는 immutable js입니다.

Immutable js

[이미지 출처](https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram) 
[공식문서](https://ko.reactjs.org/docs/state-and-lifecycle.html#adding-lifecycle-methods-to-a-class) 
React의 class형 컴포넌트는 위 이미지와 같은 생명주기를 가집니다. 
Mounting, Updating, UnMounting의 3가지 상황이 있고, 
각 상황에 맞는 라이프 사이클 메서드를 거치면서 컴포넌트가 DOM에 올라가게 됩니다. 
라이프 사이클과 비동기에 대해 이해하면 리엑트에서 본인이 원하는대로 동작하는지 아닌지 판단하기 쉬워집니다.

## 단계

생명주기 메서드는 3가지 단계를 가지고 있습니다. 
각 단계에 맞게 코드를 짜야 컴포넌트가 의도한대로 동작합니다.

-	Render 단계

	이 단계에서는 사이드 이펙트 없이 순수하게 지닌 값을 통해 렌더링 됩니다. 
	사이드 이펙트란 state를 업데이트 하는 행위 등을 말하며, 이 시점에서는 컴포넌트를 일시정지, 중단, 렌더, 재시작 등이 가능합니다.

-	Pre-commit 단계

	업데이트에서의 getSnapshotBeforeUpdate만 이 단계에 해당하는데, 렌더를 마치고 DOM에 반영되기 직전에 일어납니다. 
 이 상황에서도 DOM을 읽을 수 있습니다.

-	Commit 단계

	변경사항들을 DOM에 적용시킵니다. 
	적용 이후에 `componentDidMount`, `ComponentDidUpdate` 메서드를 호출하여 사이드 이펙트를 발생시킬 수 있습니다.

## 생명주기 메서드

### 생성 (Mounting)

컴포넌트가 처음으로 불려져 생성될 때 입니다. 
Re-Render 시에는 불리지 않고 오직 한번만 불려지게 됩니다.

-	**constructor**

	컴포넌트의 생성자 입니다. 
	컴포넌트가 생성되면서 가장 먼저 실행 됩니다. 
	state나 변수, 그리고 클래스를 이곳에서 초기화 해줍니다.

	```tsx
	constructor(props: OwnProps) {
		super(props);

		this.state = {
			example : 'exp',
		}
	}
	```

	`super()`는 빈 객체를 만들고 this에 이 객체를 할당하는 일을 부모 클래스에게 기대합니다. 
	자식 클래스의 인스턴스에는 고유 멤버와 부모 클래스의 모든 멤버도 포함 되었기 때문에 반드시 호출해야 합니다. 
	`super(props)`의 props는 넣어주지 않더라도 클래스에서 인식은 할 수 있습니다. 
	하지만 constructor 단계에서는 props가 `undefined` 상태가 되는데 constructor에서 props를 사용하기 위해선 반드시 넣어줘야 합니다.
	**주의 constructor에서 state에 props를 넣을 때** 
	외부의 props가 변경되어도 constructor에서 초기화를 해주게 된다면 state는 변하지 않습니다. 
	외부 props에 따라 동작하게 하려면 update시에도 불려지는 getDerivedStateFromProps에서 넣어주거나, 혹은 props그 자체로 이용해야 합니다.

-	getDerivedStateFromProps

	이 메서드는 props로 받아온 데이터를 state에 넣어줄 때 사용하는 메서드입니다. 
	일반적으로 사용되는 함수는 아니며, state가 props에 의존해야 하는 경우에만 사용합니다.

	```tsx
	getDerivedStateFromProps() {
		if(props.firstName + props.lastName !== state.name) {
			return {
				name : props.firstName + props.lastName,
			}
		}
		return null;
	}
	```

-	render

	컴포넌트를 렌더링 해주는 메서드입니다. 
	클래스 컴포넌트에서 반드시 필요로 하는 메서드이고, 실제 DOM에 올라가게 될 태그들 입니다.

	```tsx
	render() {
		return (
			<div>
				<input type='text' value={this.state.text}>
			</div>
		)
	}
	```

-	**componentDidMount**

	컴포넌트가 마운트된 직후 실행됩니다. 
	네트워크 요청을 통한 초기화 작업을 할 때 자주 사용됩니다.

	```tsx
	componentDidMount() {
		ajax.get("/example").then(......);
	}
	```

### 업데이트 (Updating)

state가 변화하거나 props가 변화하거나 혹은 `forceUpdate()` 메서드를 사용할 때 발생합니다.

-	getDerivedStateFromProps

	생성시와 마찬가지입니다. props에 대해 tate가 갱신됩니다.

-	**shouldComponentUpdate**

	`성능 최적화 메서드`입니다. 
	이 메서드는 컴포넌트가 리렌더링을 할지 말지 결정해줍니다. 
	true값을 반환하면 리렌더링을 진행하고, false값을 반환하면 리렌더링이 일어나지 않습니다. 
	리엑트는 부모 컴포넌트가 리렌더링 되면 자식 컴포넌트도 전부 리렌더링이 일어납니다. 
	이 메서드를 활용하면 부모 컴포넌트의 리렌더링에 자식 컴포넌트가 자유로워집니다. 
	기본타입(string, number 등..)은 그냥 비교해도 상관없으나, 참조타입(object, array)등은 **주의 얕은 비교를 해야만 값 비교가 가능합니다.**

	```tsx
	shouldComponentUpdate(nextProps, nextState) {
		return this.props.data !== nextProps.data;
	}
	```

-	render

	생성시와 마찬가지로 새로운 결과값이 반영된 컴포넌트를 렌더해줍니다.

-	getSnapshotBeforeUpdate

	이 메서드는 컴포넌트의 변화를 DOM에 반영하기 직전에 호출되는 메서드입니다. 
	스크롤바 위치처럼 업데이트 직전의 값을 참고할 때 쓰이며, 
	이 메서드에서 componentDidUpdate메서드로 새로운 값을 넘겨줄 수 있습니다. 
	일반적인 상황에선 쓰이지 않으나 스크롤 이벤트 같은 경우에 필요합니다.

-	componentDidUpdate

	컴포넌트가 업데이트 된 후에 불려집니다. 
	state나 props의 변화에 따른 로직을 수행할 때 사용하기 적절합니다.

	```tsx
	// getSnapshotBeforeUpdate 미사용
	componentDidUpdate(prevProps, prevState) {
		if (this.props.data !== prevProps.data) {
			this.flag = true;
		}
	}

	// getSnapshotBeforeUpdate 사용
	getSnapshotBeforeUpdate(prevProps, prevState) {
		if (prevProps.list.length < this.props.list.length) {
			const list = this.listRef.current;
			return list.scrollHeight - list.scrollTop
		}
		return null;
	}

	componentDidUpdate(prevProps, prevState, snapshot) {
		if (snapshot !== null) {
			const list = this. listRef.current;
			list.scrollTop = list.scrollHeight - snapshot;
		}
	}
	```

### 제거 (UnMounting)

컴포넌트가 제거될 때 일어납니다.

-	componentWillUnmount

	컴포넌트가 DOM에서 사라지기 직전에 호출됩니다. 
	타이머 제거, 네트워크 요청 취소 등의 정리작업을 실행하기 적절합니다. 
	이곳에선 반드시 setState를 발생시키면 안됩니다.

### 기타

-	componentDidCatch

	자식 컴포넌트에서 에러가 발생한 경우 호출됩니다. 
	commit단계에서 수행되므로, 에러 처리를 통한 side effect를 일으켜도 좋습니다.

-	componentWillMount

	컴포넌트가 DOM에 추가되기 직전에 실행되는 함수이나, 현재는 <dep>deprecated</dep>된 함수입니다.

class형 컴포넌트의 라이프 사이클에 대해 알아보고 그를 활용할 수 있도록 하는 글입니다.

LifeCycle Method

Lombok이란? 
Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, automate your logging variables, and much more.
[공식문서로 부터](https://github.com/projectlombok/lombok) 
해석하여 요약하면 롬복은 에디터의 빌드툴에 자동으로 연결하여 자바를 향상시켜주는 라이브러리 입니다.

## 원리

위의 Lombok 설명을 보면 **편집기에 build tools를 자동으로 연결하여** 라는 말이 있습니다. 
Lombok은 실제로 컴파일러로 넘어갈 때 AST트리를 동적으로 수정하고 바이트 코드를 자동으로 작성해주는 역할을 합니다. 
결국 컴파일 시점 코드 생성이고, 컴파일러 플러그인이기 때문에, 지원하는 IDE에서만 사용할 수 있습니다.

## 사용해야 할까?

Lombok에 대해서는 많은 개발자들 사이에서 **사용해야 한다 vs 사용하면 안된다** 로 나뉩니다. 
결국에 Lombok은 개발을 편하게 하기 위해 사용하는 것이고, 컴파일러를 거치면 사용한 것과 사용하지 않은 것의 성능과 동작은 일치합니다. 
그래도 분명 사용했을때의 강점도 크기 때문에 실제로 많은 기업에서도 잘 사용하고 있습니다. 
개인적인 생각이지만 무조건 사용하지 말아야한다보단 잘 파악하고 사용한다면 큰 문제가 없을거라 생각합니다. 
따라서 이 문서에서는 Lombok에 대해 사용하면 안된다는 이유와 사용해야 한다는 이유를 분석하고, 이에 따라 사용하게 되면 어느 부분을 조심해야 할지에 대해 다루겠습니다.

## 사용해야 한다.

사용해야 한다 의견은 매우 단순합니다. 
Lombok을 잘 적용하면 코드량을 많이 줄여줍니다. 
그에 따라 개발하는 속도가 빨라지고, 또한 리펙토링이 쉬워지며, 코드를 분석하기가 매우 편해집니다.

```java
// Lombok 미적용
public class MemberDto {
	private String id;
	private String password;
	private String name;
	private int age;

	public MemberDto () {}

 public MemberDto (String id, String password, String name, int age) {
 this.id = id;
 this.password = password;
 this.name = name;
 this.age = age;
 }

 public String getId() {
 return id;
 }

 public void setId(String id) {
 this.id = id;
 }

 public String getPassword() {
 return password;
 }

 public void setPassword(String password) {
 this.password = password;
 }

 public String getName() {
 return name;
 }

 public void setName(String name) {
 this.name = name;
 }

 public int getAge() {
 return age;
 }

 public void setAge(int age) {
 this.age = age;
 }
}

public class MemberDtoBuilder {
	private String id;
	private String password;
	private String name;
	private int age;

	public MemberDtoBuilder () {}

	public MemberDtoBuilder id(String id) {
		this.id = id;
		return this;
	}

	public MemberDtoBuilder password(String password) {
		this.password = password;
		return this;
	}

 public MemberDtoBuilder name(String name) {
		this.name = name;
		return this;
	}

 public MemberDtoBuilder age(int age) {
		this.age = age;
		return this;
	}

	public Member build() {
		return new Member(id, password, name, age);
	}
}

// Lombok 적용
@Getter @Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class MemberDto {
	private String id;
	private String password;
	private String name;
	private int age;
}
```

빌드 패턴을 적용하였지만, 빌드패턴을 제외하더라도 코드량이 상당히 줄어들게 됩니다.

## 사용하면 안된다.

1.	컴파일러 단계에서 적용

컴파일러 단계에서 지원하다보니, 특정 IDE에 종속되게 됩니다. 
뿐만 아니라 관련된 플러그인이나 설정을 해야만 적용할 수 있습니다.

2.	지원 중단 시 리스크

	Lombok은 코드량을 많이 줄여줍니다. 
	하지만 그만큼 이미 적용한 프로젝트에서 Lombok 코드를 제거하기란 쉽지 않은데, 
	Lombok에 관련하여서 어떠한 이슈가 발생하거나 제거 해야 할 일이 생기면 그만큼 많은 수정을 필요로 하게 됩니다.

-	코드가 쉽게 변환

	```java
	// Member 클래스
	@AllArgsConstructor
	public class Member {
		private String id;
		private String name;
	}

	// 사용하는 곳
	Member member = new Member("id", "name");
	```

	위와 같은 코드가 있고 정상적으로 동작할 때, 만약 누군가가 아래와 같이 코드를 수정할 수 있습니다.

	```java
	// Member 클래스
	@AllArgsConstructor
	public class Member {
		private String name;
		private String id;
	}

	// 사용하는 곳
	Member member = new Member("id", "name");
	```

	단순히 위 아래 순서만 고쳤지만 실 사용되던 곳의 코드는 완전히 다르게 됩니다. 
	컴파일 에러를 발생하지 않으면서 코드가 쉽게 변환 될 가능성을 가지게 됩니다.

-	순환참조

	JPA Data의 Eintity에서 양방향 매핑을 할 때처럼, 서로가 서로를 참조하고 있을 때와 같이, 
	아무런 생각없이 @ToString 어노테이션을 사용한다면 Stack Over Flow가 발생합니다.

## 해결방안

이슈들로부터 비교적 안전하게 Lombok을 사용하기 위한 방안들입니다.

-	**@Data** 사용 금지

	**@Data* 어노테이션은 @RequiredArgsContructor + @Getter + @Setter + @ToString + @EquialsAndHashCode 입니다. 
	필요 없는 어노테이션까지 가져올 가능성이 많고, 클래스를 잘못 사용하게 될 가능성이 있습니다.

-	**@ToString**은 조심해서

	exclude 파라미터를 활용해서 특정 필드만 제외시킬 수 있습니다. 
	순환참조일 경우 해당 필드를 제외시키고, 조심해서 사용해야 합니다.

-	**@XXArgsConstructor**

	해당 어노테이션들은 위에서 언급하였듯, 코드가 쉽게 변할 수 있는 리스크를 가지게 됩니다.

	1.	**@Builder**와 함께 이용

		접근레벨을 access = PRIVATE로 낮추고 Builder 패턴을 사용하면 코드가 생성자에 종속적이지 않게 되어서, 안전한 코드 작성이 가능합니다.

	2.	사용하지 않음

		그냥 사용하지 않고 생성자를 직접 만들어주는 것도 하나의 방법입니다.

-	**EqualsAndHashCode**

	equals 메서드와 hashcode 메서드를 생성해주는 어노테이션 입니다. 
	하지만 무분별하게 사용하면, Set과 함께 사용할 경우에 이슈가 발생할 수 있습니다.

	```java
	// Member클래스
	@AllArgsConstructor
	@EqualsAndHashCode
	@Setter
	public class Member {
		private String id;
		private String name;
	}

	// Set 사용
	Set<Member> memberSet = new HashSet();
	Member member = new Member("id1","홍길동");
	memberSet.add(member);
	member.setName("개명");
	memberSet.add(member);
	```

	위의 코드 결과를 보면 분명 member객체는 하나뿐인데, Set은 이를 구별하지 못하게 되는 현상이 일어나게 됩니다. 
	따라서 Pk들과 같은 변할일이 없는 객체에만 사용하기를 권합니다.

	```java
	@Entity
	public class Member {
		@EmbededId
		private MemberId;
		......
	}

	@Embeddable
	@EqualsAndHashCode // Id Class는 불변 객체입니다.
	public class MemberId implements Serializable {
		......
	}
	```

Lombok에 대해 단점과, 장점 그리고 사용한다면 어떠한 방식으로 사용해야 할까에 대한 글입니다.

Lombok

[Representational State Transfer API](https://aws.amazon.com/ko/what-is/restful-api/)는 리소스를 이름으로 구분하여 해당 상태를 주고 받는것을 의미합니다. 
간단하게는 API의 URI를 만드는 규칙입니다.

## 사용 이유

1.	서버와 클라이언트의 구분

	백엔드랑 프론트엔드를 구분하여서 서로의 의존성을 떨어뜨립니다.

2.	무상태(Stateless)

	세션과 쿠키를 다루지 않으면서 서버는 요청만 단순 처리하게 되고, 서비스의 자유도가 높아집니다.

3.	캐시(Cacheable)

	HTTP 프로토콜의 캐싱 기능 적용 가능

4.	협업 규칙

	개발자들이 동일한 방식으로 API를 개발하여 서비스의 통일감을 주고, 
	코드 분석을 빠르게 합니다.

## REST 구성 요소

1.	자원(Resource): URI

2.	행위(Verb): HTTP Method

	HTTP 프로토콜의 [Method](#http-method)들을 사용합니다.

3.	표현(Representation of Resource)

	JSON, XML등 형태로 나타내어 지고, Spring에서는 ResponseEntity를 활용합니다.

## HTTP Method

메서드는 총 8가지가 있습니다.

1.	GET: 서버로 부터 데이터를 취득

2.	POST: 서버에 데이터를 추가, 작성 등

3.	PUT: 서버의 데이터를 갱신, 작성 등

4.	PATCH: 리소스의 일부분을 수정

5.	DELETE: 서버의 데이터를 삭제

6.	HEAD: 서버 리소스의 헤더(메타 데이터의 취득)

7.	OPTIONS: 리소스가 지원하고 있는 메소드의 취득

8.	CONNECT: 프록시 동작의 터널 접속을 변경

## Response Status (상태 코드)

HTTP STATUS CODE 라고 불리고, Response에 상태코드가 담겨서 클라이언트에게 응답합니다. 

-	2XX(성공)

	-	200 OK

		요청이 성공했음을 의미합니다. 
		**ResponseEntity.ok(dto);**

	-	201 Created

		POST나 PUT요청 이후에 리소스가 생성되었음을 나타냅니다. 
		**ResponseEntity.created(URI.create("/")).build();**

	-	204 No Content

		요청에 대해 보낼 컨텐츠가 없을 때 사용합니다. 
		**ResponseEntity.noContent().build();**

-	4XX(클라이언트 오류)

	-	400 Bad Request

		잘못된 문법으로 서버가 요청을 이해하지 못할 경우입니다.

	-	401 Unauthorized

		요청이 인증받지 못했음을 나타냅니다.

	*	403 Forbidden

		요청에 권한이 없을 때를 나타냅니다.

	-	404 Not Found

		일반적으론 알려지지 않은 URL을 나타냅니다. 
		때에 따라선 결과 리소스가 없을 경우에도 404를 사용합니다. 
		**ResponseEntity.notFound().build();**

-	5XX(서버 오류)

	-	500 Internal Server Error

		서버에 에러가 나타났음을 알립니다.

	-	502 Bad Gateway

		서버가 게이트웨이로부터 잘못된 응답을 수신했음을 나타냅니다.

	-	504 Gateway Timeout

		서버가 게이트웨이 역할을 수행하는 동안 요청을 마치기 위한 응답을 수신하지 못할 경우입니다.

## 설계 규칙

1.	동사 대신 명사를 사용합니다.

	**@GetMapping("/getMember")** X → **@GetMapping("/member/[id]")**

2.	자원에 대한 행위는 HTTP method를 이용합니다.

	**@GetMapping("/books")** → 책 목록을 가져온다. 
	**@GetMapping("/books/[id]")** → 특정 책의 정보를 가져온다. 
	**@PostMapping("/books/[id]")** → 새로운 책을 등록합니다. 
	**@PatchMapping("/books/[id]")** → 특정 책을 삭제한다.

3.	URI 경로에는 소문자가 적합합니다.

4.	슬래시 구분자(/)는 계층 관계를 나타냅니다.

	**/houses/apartments**

5.	URI마지막 문자로 슬래시(/)를 넣지 않습니다.

6.	밑줄(￦_), camelCase 대신 하이폰(-)을 사용하여 가독성을 높여줍니다.

	**/bookAndVideo, /book-and-video** X → **/book-and-video**

## 추가 자료

-	GET vs OTHER

	GET 방식은 다른 메서드들과 차이점을 가지고 있습니다.

	1.	캐싱

		GET 방식은 캐싱을 하기 때문에 반복된 요청에 더 빠릅니다.

	2.	파라미터
		
		파라미터 내용이 노출되기 때문에 사용자들이 이를 볼 수 있습니다.

	3.	길이 제한

		GET 방식의 파라미터는 데이터 길이에 대한 제한이 있습니다. 제한되는 정도는 브라우저마다 다릅니다.

-	idempotent(멱등성)

	여러번 API가 수행되더라도 같은 결과가 나와야 한다는 말입니다. 
	GET, PUT, DELETE가 이에 속합니다.

-	PUT vs PATCH

POST, PUT 그리고 PATCH의 차이점은 일종의 규약이기 때문에 반드시 지킬 필요는 없습니다. 
그래도 규약을 지킨다면 메서드가 어떤 역할을 하는지가 분명해져서 코드를 이해하기 더 편해집니다. 

1.	PUT

	데이터가 없다면 새로운 데이터를 생성하거나, 있다면 그 위에 덮어씌우는 역할을 합니다. 
	새로운 데이터를 생선한 경우에는 201(Created), 기존 데이터를 덮어쓴 경우는 200(OK) 혹은 204(No Content)로 응답해야 합니다. 
	즉 PUT은 자원의 모든 상태를 알고 있는 상태(Request에 모든 데이터)여야만 합니다.

```java
	// controller
	@PutMapping("/member/{id}")
	public ResponseEntity<Void> updateMember(
		@RequestBody MemberRequest request,
		@PathVariable String id
	){
		if(memberService.updateMember(request, id)){
			return ResponseEntity.ok().build();
		}
		return ResponseEntity.created(URI.create("/member/id/")).build();
	}

	// service
	@Transactional
	public boolean updateMember(MemberRequest request, String id) {
		boolean isMember = memberRepository.findById(id).isPresent();
		Member member = request.toEntity();
		memberRepository.save(member);

		return isMember;
	}
```

2.	PATCH는 PUT과 달리 Entity를 찾아오고, 그 데이터의 일부를 수정하는 역할을 합니다.

```java
	// controller
	@PatchMapping("/member/{id}")
	public ResponseEntity<Void> updateNickNameMember(
		@RequestParam String nickName,
		@PathVariable String id
 ) {
	 service.updateNickNameMember(nickName,id);
	 return ResponseEntity.ok().build();
 }

	// service
	@Transactional
	public void updateNickNameMember(String nickname, String id) {
		Member member = memberRepository.findById(id)
			.orElseThrow(NoSuchElementException::new);

		member.changeNickName(nickName);
	}

	// entity
	@Entity
	public class Member {
		@Id
		@Column
		private String id;

		@Column
		private String nickName;

		public void changeNickName(String nickName) {
			this.nickName = nickName;
		}
	}
```

## 목적

RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 Application을 만드는데 있습니다. 
성능향상을 위한것이 아닌, 일종의 규칙을 만드는 것으로 
각 서비스에 맞게 적용하면 됩니다.

RESTful API

[원문](https://atomicdesign.bradfrost.com/chapter-2/) 
아토믹 디자인 패턴이란 컴포넌트를 재사용성이 강하고 단단하게 설계하는 디자인 패턴으로, 
리엑트나 뷰와같은 컴포넌트 단위 프론트 프레임워크를 사용할 때 적용하는 방식입니다. 
마치 화학처럼 원자가 모여 분자가 되고, 분자가 모여 하나의 유기체가 되어서, 
최종적으로는 잘 조립이 되어서 하나의 결과물을 구성하게 됩니다. 
따라서 이 디자인 패턴을 잘 적용하면 공통 컴포넌트를 통해 개발속도가 향상되고 
각 페이지들이 통일성 있으면서도, 다양한 기능을 구현 가능케 합니다.

## Atoms(원자)

Input이나 Button, H1, H2와 같은 순서 HTML 태그를 구성합니다. 
더 이상 쪼개질 수 없고, 마진이나 위치값을 가지지 않습니다. 
또한 state와 props를 다양하게 가져서 최대한 포용력 있게 구성해야 합니다. 

## Molecules(분자)

분자는 원자들이 모여서 이루어지며, 체크박스가 여러개 모인 리스트라던가, 
혹은 Input태그와 Label태그와 Button 태그가 합쳐져서 하나의 검색창의 단위를 가집니다. 

## Organisms(유기체)

유기체는 분자나 원자들이 합쳐져서 생성되고, 분자나 원자의 위치값을 조정합니다.

## Templates(템플릿)

템플릿은 페이지의 그리드를 정해주는 역할을 합니다. 

## Pages(페이지)

앞서 위에 있던 요소들이 모여서 하나의 페이지가 만들어지게 됩니다. 
템플릿을 잘 활용하여 페이지를 만드는 것이 통일감 있는 페이지가 만들어집니다.

아토믹 디자인 패턴(Atomic Design Pattern)이란 무엇인가, 또 컴포넌트를 어떻게 설계하는가에 대한 글입니다.

아토믹 디자인 패턴

지난 포스트에서는 Eureka Server로 동작할 Service Discovery를 만들었습니다. 
[ServiceDiscovery 포스트](/post/back-end/service-discovery) 
Eureka Server에 각 Service들을 Client로 등록해서 Server가 파악할 수 있게 해야합니다.

## 등록방법

Eureka Server에 각 Service들을 Client로 등록해서 Server가 파악할 수 있게 해야합니다.

### Dependencies

```groovy
// build.gradle
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}
```

### Annotation

Service Client로 등록하는 어노테이션은 총 2개가 있습니다. 

-	@EnableDiscoveryClient

	이 어노테이션은 Eureka뿐 아니라 consul, zookeeper들이 같이 속해있습니다. 
	해당 기능들도 같이 구현하여 사용하고 싶을 때 이 어노테이션을 사용합니다.

-	@EnableEurekaClient

	이 어노테이션은 오로지 Eureka Client로 등록해주기만 합니다.

두 어노테이션중 하나를 선택하여서, 메인클래스에 붙이면 됩니다.

```java
@SpringBootApplication
@EnableEurekaClient
public class TestApplication {
	public static void main(String[] args) {
		SpringApplication.run(TestApplication.class, args);
	}
}
```

### 설정 파일 추가

```yml
eureka:
	client:
		serviceUrl:
			defaultZone: http://www.exam.com:8085/eureka/
		registerWithEureka: true
		fetchRegistry: true
```

Eureka Server의 URL을 eureka.client.serviceUrl.defaultZone 설정값에 넣어줘야 합니다. 
그리곤 Eureka Server 서비스와는 반대로, Client임을 알리기 위해 
eureka.client.registerWithEureka, 
eureka.client.fetchRegistry 이 두개의 값을 true로 설정합니다.

```yml
spring:
	application:
		name: client-name
```

spring.application.name의 이름으로 Eureka Server에 등록됩니다.

## Eureka 등록의 원리 (HTTP Method로 등록 및 삭제)

Eureka Server는 HTTP Method를 받아서 등록, 갱신, 및 삭제를 진행합니다.

-	등록

	appID로 Client에 등록합니다. 
	**POST /eureka/apps/[appID]**

-	갱신

	appID의 instanceID 갱신을 받습니다. 
	**PUT /eureka/apps/[appID]/[instanceID]**

-	삭제

	appID의 instanceID를 삭제합니다. 
	**DELETE /eureka/apps/[appID]/[instanceID]**

위의 등록 방법에서 어노테이션을 적용하면 위 3가지 작업을 자동으로 진행합니다. 
갱신 요청이 일정 시간동안 없다면 해당 서비스를 죽은것으로 간주합니다.

Spring Cloud MSA 환경에서 Service들을 등록하는 방법에 대한 글입니다.

Eureka Server(ServiceClient)

Service Discovery란 외부에서 마이크로 서비스들을 검색하기 위한 기능을 지원해줍니다. 
ket, value 값으로 각 서비스가 어디에 존재하는지 저장하고, 검색을 해줍니다.

## Netflix Eureka

Eureka는 Gateway로 부터 요청정보를 받게되면 알맞는 서비스에 요청을 보내주는 역할을 합니다. 
뿐만 아니라 Load Balancer를 지원해주거나 서비스 인스턴스 상태를 확인할 수 있습니다.

## 적용법

Spring Boot 프로젝트에서는 아래 방법대로 적용할 수 있습니다.

### dependencies

gradle 혹은 maven에서 netflix-eureka-server를 추가해줍니다. 
gradle 기준으로는 아래와 같습니다.

```groovy
dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-server'
}
```

### @EnableEurekaServer

SpringBoot의 메인 메서드가 존재하는 서비스 어플리케이션에 어노테이션을 추가해줍니다.

```java
@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServiceApplication {
	public static void main(String[] args) {
		SpringApplication.run(DiscoveryServiceApplication.class, args);
	}

}
```

### 설정 파일 추가

```yml
spring:
	application:
		name: cloud-discovery

eureka:
	client:
		register-with-eureka: false
		fetch-registry: false
```

spring.application.name 속성은 서비스의 이름 (Key값)을 지정해줍니다. 
eureka.client.register-with-eureka속성은 eureka 서버에 등록 여부를 결정해주는데, 
Discovery 서비스는 해당 서비스 자체가 eureka 서버가 되야하기 때문에 false로 해줍니다.

## 적용 확인

![EurekaInstance size:800*400](/back-end/eurekaInstance.png)

-	Instances currently registered with Eureka

	현재 Eureka Server에 등록되어 있는 Service목록들을 확인 할 수 있습니다. 
	Application은 yml의 spring.application.name으로 설정한 Key 값이며, 
	Availability Zones는 가용성 영역으로 한 서비스 내의 인스턴스 갯수를 나타내줍니다. 
	Status는 UP은 서버가 문제없이 가동되는 것, DOWN은 서버가 가동되지 않음을 뜻합니다.

Spring Cloud MSA 환경에서 서비스들을 감독해주는 서비스에 대한 글입니다.

Eureka Client(Service Discovery)

## Component란?

[공식문서](https://ko.reactjs.org/docs/components-and-props.html) 
컴포넌트는 React에서 화면을 이루는 하나의 조각입니다. 
React를 사용할 때는 컴포넌트를 class형 또는 function형으로 정의할 수 있습니다. 
class형 컴포넌트의 경우에는 라이프 사이클 기능을 사용할 수 있고, 임의 메서드를 정의할 수 있습니다. 
function형 컴포넌트는 사용하기 간편하고, 라이프 사이클 대신에 hooks를 사용할 수 있습니다. 
또한 빌드 성능이 class형보다 약간 더 좋습니다. 
최신 React는 계속해서 최적화 hook과 편리성 hook을 개발하면서 function형을 공식으로 권장하고 있으나, 
코드 짜는 방식이 다르고 성능차이가 크지 않아서 
OMS에서는 몇몇 컴포넌트들만 function형으로 사용되고 있고, 대부분의 컴포넌트가 class형으로 사용되고 있습니다.

## class형 Component의 구성

class형 컴포넌트는 아래와 같은 구성으로 이루어져있습니다.

```tsx
// Counter.tsx 파일
/* import 선언부
 라이브러리 모듈이나, 다른 컴포넌트들을 import해주는 부분입니다. */
import React from 'react';

/* type 선언부
 typeScript에서 지원해주는 기능으로, 사용할 변수 명과 타입을 선언해주어서,
 컴포넌트의 가독성을 올려주고, 자동완성 및 컴파일 에러를 지원해줍니다. */
interface OwnProps {
	// 변수명 뒤에 ?를 붙히면 | undefined가 됩니다.
	// 즉 initialCounter: number | undefined와 같아집니다.
	initialCounter?: number;
	useName: boolean;
	name?: string;
}

interface OwnState {
	counter: number;
}

type aa = 'aa' | 'bb';

/* 클래스형 컴포넌트를 정의합니다.
 컴포넌트명은 관례로 첫 문자는 대문자로 사용합니다. */
class 컴포넌트명 extends React.Component<OwnProps, OwnState> {
	/* 변수 선언부
	 컴포넌트에서 사용할 변수를 선언해줍니다.(state, props 제외)
	 여기 사용되는 변수들은 반드시 리렌더 시마다 화면에 적용되니
	 변수들을 사용할 때 표현방법을 고민해야 합니다. */
	private flag: boolean = false;

	// 라이프 사이클 선언부
	constructor(props: OwnProps) {
		super(props);
		// 변수 및 state초기화
		this.state = {
			counter: 0,
		};
	}

	componentDidMount() {
		if (initialCounter !== undefined) {
			this.setState({ counter: initialCounter });
		}
	}

	// 렌더 영역으로 실제 화면에 보이게 되는 부분입니다. JSX 문법으로 작성합니다.
	render() {
		return (
			<div>
				{/*JSX 문법에서 조건부로 렌더링 할 수 있습니다.*/}
				{useName && <h1>안녕하세요 {name}입니다.<h1/>}
				<input type="text" value={this.state.counter} />
				<button onClick={this.onClickUp}>Up</button>
				<button onClick={this.onClickDown}>Down</button>
			</div>
		);
	}

	/* 사용자 함수 선언부, 컴포넌트에서 사용할 함수들을 선언해서 사용할 수 있습니다.
	 private을 붙히지 않으면 외부 컴포넌트에서 ref를 통해 DOM으로 직접 접근할 수 있습니다. /*
	setValue = (value: number) => {
		this.setState({ counter: value });
	};

	getValue = () => this.state.counter;

	private onClickUp = () => {
		this.setState({ counter: this.state.counter + 1 });
	};

	private onClickDown = () => {
		this.setState({ counter: this.state.counter - 1 });
	};
}

export default 컴포넌트명;
```

## state, props

컴포넌트에서 가장 중요한 개념인 state와 props입니다. 
React는 기본적으로 state나, props가 변경될 때 화면을 re-render합니다. 

-	props

	props는 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달할 때 사용합니다.

	```tsx
	<Counter initialCounter={10} useName={true} name="홍길동" />
	```

-	state

	state는 컴포넌트 내에서 동적으로 상태를 관리해주는 값입니다. 
	constructor에서 state를 선언 해주고, 이후에 어떠한 이벤트가 있을 때 이 state값을 변경해줍니다. 
	state값을 변경할때는 setState()메서드를 사용해주어야 하는데, 이 때 state가 바뀌는 것은 **비동기**로 실행됩니다. 
	따라서 상태가 변경된 이후에 어떤 작업을 하고 싶으면 콜백함수를 사용할 수 있습니다.

	```tsx
	this.setState({ counter: 10 }, () => console.log('만세'));
	```

## Life Cycle

class형 컴포넌트는 Life Cycle을 가지는데, 이를 활용하여 컴포넌트가 렌더될 때, 
업데이트 될 때, 혹은 컴포넌트가 사라질 때 등의 상황에서 특정한 코드를 실행시키거나 혹은 디버깅할 수 있습니다. 
[Life Cycle 포스트](/post/front-end/life-cycle)

## 공통 Component 사용법 알아보기

컴포넌트의 내부 로직을 이해하지 않더라도, 컴포넌트의 사요앙법을 어느정도는 알 수 있게 됩니다. 
interface로 선언된 props의 변수명과 타입을 확인하고 이에 따른 동작을 확인하면서 사용할 수 있습니다. 
추후 포스팅을 통해 컴포넌트 별로 분석해보도록 하겠습니다.

## 성능 올리기

-	리렌더링

	React는 3가지 경우에 컴포넌트에 리렌더링이 일어납니다. 
	state가 변경되거나, props가 변경되거나, 혹은 forceUpdate() 메서드를 호출하였을 때 입니다. 
	**리엑트는 부모 컴포넌트가 리렌더 되면 자식 컴포넌트도 전부 리렌더가 일어납니다.** 
	즉 리렌더가 자주 일어나게 되면 성능이 저하되고, 이를 `souldComponentUpdate`를 통해 최적화가 가능합니다. 
	최적화가 가능해도 애초에 불필요한 리렌더를 일으키지 않는것이 최선이고, 
	적절한 리렌더는 UI를 설계할 때 필요하지만, 무분별한 리렌더는 성능 저하를 유발합니다.

-	state vs ref

 [공식문서](https://ko.reactjs.org/docs/forwarding-refs.html) 
 createRef()는 상위 컴포넌트에서 리렌더링 시키는 것이 아닌, DOM에 직접적으로 접근하여서 하위 컴포넌트에서 리렌더를 일으켜 변경하거나 조작합니다. 
 하위 컴포넌트에서만 리렌더를 일으켜서, 리렌더의 범위를 최소화 시킴으로서 성능을 끌어올릴 수 있습니다. 
 하지만 무분별한 사용은 오히려 렌더의 범위는 줄이지만 렌더의 횟수를 늘려 성능이 저하될 수 도 있습니다. 
 공통 Component나 라이브러리에서 적절하게 사용하면 좋습니다.

-	shouldComponentUpdate

	[공식문서](https://ko.reactjs.org/docs/optimizing-performance.html#shouldcomponentupdate-in-action) 
	라이프사이클인 shouldComponentUpdate는 false를 반환할경우 리렌더를 시도하지 않고, 
	심지어 true를 반환하는 경우에도 이전에 렌더링 된 React 엘리먼트와 동일 한 경우에는 DOM을 update하지 않아서 
	React의 렌더링 성능을 끌어올릴 수 있습니다.

React의 Class형 Component를 분석하여 공통 코드를 이해할 수 있도록 하는 글입니다.

React Class형 Component 분석하기

## Monolithic vs MSA

Monolitihc이란 기존에 사용하던 방식으로, 
한 서비스 안에 모든 기능을 유기적으로 연결시켜 운영하는 방식입니다. 
MSA는 Monolithic방식과 다르게 서비스를 나누고 기능을 분리하여 하나의 어플리케이션으로 합쳐서 운영하는 방식입니다. 
MSA환경에서 실제 개발을 해보면서 느낀점은, 
MSA 환경이여서 얻는 이점도 많았지만, 
장점만 존재하진 않았고, 불편한 점들도 상당히 있었습니다. 
약간 주관적이겠지만 제가 생각하는 장단점입니다.

### 장점
-	유연한 서비스 관리

 각 서비스를 유연하게 배포할 수 있어서 실제 상황에서 소스를 롤백하거나, 또한 확장하기에 좋습니다.

-	책임 분리 및 장애 범위 축소

 서비스의 책임이 분리되어서, 대량 데이터 조회 서비스와 
 핵심 로직 서비스를 분리하는 방식으로 사용도 가능하여서, 
 장애가 일어나도 커다란 피해가 없을 수 있습니다.

-	편리한 관리도구

 elk 스택을 활용한 로그조회나, grafana를 통한 시각화 자료등이 각 서비스 마다 이루어져 있기에, 
 분석이나 해결방안을 도출하는데 많은 도움이 되었습니다.

-	편리한 기능개발

 신규 기능을 개발하기에 해당 서비스에 미치는 영향도를 고려하기 더 쉽고, 
 특정 서비스의 구성을 바꿀 수 있기에 다양한 시도를 하기 좋습니다.

### 단점

-	초기 서비스를 갖추는데 많은 시간과 인력이 필요합니다.

 서비스를 설계에 따라 나누고, gateway, discovery, 등등 필요로 하는 서비스뿐 아니라, 
 배포화 도구, 모니터링 도구 등… 
 그 구현 난이도 또한 어렵습니다.

-	특정 소스 테스트 및 디버깅 난이도 상승

 여러 서비스끼리 서로 api를 주고받는 경우, 
 어디 서비스에서 어떤 문제가 있는지 찾기 더 어려워질 수 있습니다. 
 또한 테스트하려면 여러 서비스를 동시에 돌려서 테스트 해야하는데 이것도 번거롭습니다.

-	난잡한 코드관리

 JPA를 사용하는데 컬럼이 추가된다거나 하는 경우 해당 Entity를 사용하는 모든 서비스를 찾아서 업데이트를 해줘야하고, 
 혹은 새로운 기준코드가 생겨도 enum을 사용할 경우 마찬가지로 해당 모든 서비스를 찾아서 코드를 업데이트 해줘야 합니다. 
 뿐만 아니라 개발자의 수가 많아지고 프로젝트가 커질수록 여러 서비스에 같은 로직이 구현되어 있을 가능성도 점점 커집니다.

적다보니 단점도 많이 적었지만, MSA는 얻는 이점도 크고 확실한 아키텍처라고 생각합니다. 
하지만 기술적으로나, 관리적으로 보았을 때 무조건적으로 MSA를 사용하는 것이 좋다 보단, 
서비스의 규모나 특징을 생각하고 선택하는 것이 더 좋다 생각합니다.

## MSA의 구조

MSA에 정해진 구조는 없지만, 이정도의 틀은 유효하다 생각합니다.

### API Gateway

Client에게 요청을 바든 지점입니다. 
Service Router를 통해 API요청을 각 서비스에 보내주고, 
간단한 보안, 인증을 수행합니다.

### Service Mesh

Service Mesh란 Micro Service내의 내부 통신을 의미합니다.
-	Service Discovery (Eureke)

 Service들을 등록하고, 각 Service들의 위치(IP주소,Port번호), 
 인스턴스 갯수 및 상황등을 파악하여 주는 서비스입니다.

-	Load Balancer (Ribbon)

 서비스가 분산된 형태로 존재할 때 알맞는 Instance에 요청을 보내주도록 도와줍니다.

-	Config Store

 공통된 설정파일(DB 정보나, Network 설정 등..)을 저장해두고 필요로 하는 서비스에게 보내줍니다.

-	Circuit Breaker

 원격 접속의 실패율이 임계치를 넘을 경우, 
 접속을 차단해주는 시스템입니다.

### Telemetry

전체 서비스의 모니터링과 진단 기능을 가집니다. 
elastic Search같은 도구들을 이용합니다.

MSA란 무엇인지, 기존 프로젝트와 어떠한 차이가 있는지에 대한 글입니다.

## Axios란?

Axios는 비동기 통신 라이브러리로, 흔히 알고 있는 ajax 기능을 내장하고 있습니다. 
OMS에선 utils/Ajax.ts 파일에 세팅이 되어있습니다. 
Axios는 Promise 기반으로 javascript에서 제공하는 XMLHttpRequests를 만들어줍니다. 
보통 Front-End에서 Back-End로 요청을 보낼 때 많이 사용되고, 혹은 외부 API를 받아오거나 크롤링을 할 때 사용합니다.

## Promise란?

Promise는 javascript에서 비동기 작업을 처리하는 방법중에 하나입니다. 
비동기 작업이 성공할 때와, 실패할 때를 나누어서 처리기를 연결해줄 수 있고, 
보통은 axios와 같은 비동기 통신에서 자주 사용됩니다. 
자세한 사용방법은 [mdn Promise](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise)를 참고해주세요.

## 인스턴스 만들기

Axios는 인스턴스를 만들지 않고도 API 호출이 가능하지만, 
인스턴스를 만들면 baseURL, timeout 등의 기본적인 설정이 가능하고, 
또한 Interceptor를 적용시킬 수 있게 되어 편한 사용이 가능해집니다.

```js
import axios from 'axios';

const ajax = axios.create({
	baseURL: 'https://example.com/',
	timeout: 1000,
	headers: { 'Access-Control-Request-Headers': ['Authorization', 'Content-Type'] },
}); // ajax라는 인스턴스를 생성해줌.
```

## API 요청 보내기

인스턴스를 통한 요청 메서드는 아래와 같이 있습니다. 
HTTP Methods에 대해서는 [restful 포스트](/post/back-end/restful-api)를 참조해주세요. 
url은 반드시 들어가야하고, [] 이 부분에 들어가는 것은 선택사항입니다.

1. ajax.get, ajax.delete

	ajax.get(url[,config]); 
	get방식과 delete방식은 url에 query들이 담겨서 넘어가게 됩니다. 
	주의하실점은 parameter가 브라우저에 따라 일정 글자 수 이상이 넘어가게 되면, 
	에러가 발생할 수 있습니다.

	```js
	const config = {};
	ajax.get('example', config);
	```

2. ajax.post, ajax.put, ajax.patch

ajax.post(url[,data[,config]]); 
post, put, patch 방식은 request body에 데이터를 담아서 보내줍니다.

```js
const config = {};
const responseBody = {};
ajax.post('/example', responseBody, config);
```

## config 세팅

config에는 request와 response에 대해서 다양한 세팅을 해줄 수 있는데, 
자주 사용되는 것들에 대해서만 다루겠습니다.

```js
const config = {
	// headers는 request header에 담길 값들을 지정해줍니다.
	// back-end 설정에 맞춰 설정 데이터들을 넘길 수 있고, 인증토큰 값 등을 넘겨줍니다.
	headers: {
		'X-Requested-With': 'XMLHttpRequest',
		Authorization: token,
	},
	// Get방식과 Delete 방식에서 많이 사용되며, url 옆에 쿼리를 붙혀줍니다.
	// back-end에서는 @RequestParam, @PathVariable 등을 통해 값을 가져옵니다.
	params: {
		userId: 'X0134481',
	},
	// 인스턴스를 사용할땐 Delete방식에서만 사용됩니다.
	// Delete 방식에서 param이 아닌 request body에 데이터를 넣어주고 싶을 때 사용합니다.
	data: {
		name: '유영진',
	},
	// paramsSerializer는 params의 시리얼라이즈를 담당하는 옵션 함수입니다.
	// 데이터를 key[]=value1&key[]=value2로 보내는걸, key=value1&key=value2로 변경해줍니다.
	paramsSerializer: (params) => qs.stringify(params, { arrayFormat: 'repaet' }),
	// 요청이 시간 초과 되기 전의 시간을 지정합니다. 요청이 이 이상걸리면 요청을 중단합니다.
	timeout: 1000,
	// 자격증명을 이용하여 사이트간 제어 요청을 해야 하는지를 설정합니다.
	withCredentials: false, //기본값
	// status코드를 활용해 Promise를 이행할지, 거부할지를 결정합니다.
	validateStatus: function (status) {
		return status >= 200 && status < 300; // 기본값
	},
	// cancel 토큰은 아래에서 더 자세히 다룹니다.
	cancelToken: source.token,
};
```

## 응답

응답 정보는 promise의 결과에 return 됩니다. 
응답 정보는 이행(then)에 담기게 됩니다.

```js
ajax.get('/test').then((response) => {
	// 서버에서 보낸 데이터가 담깁니다.
	console.log(response.data);
	/* status code가 담깁니다. (200, 201, 204 등등…)
	status code를 활용하여 insert 문을 사용할 중복체크 로직 등을 exception이 아닌 방식으로 구현 가능합니다.*/
	if (response.status === 200) {
		// OK 코드
		console.log('중복 아이디');
	} else if (response.status === 204) {
		// Created
		console.log('생성 완료');
} 
// status를 code가 아닌 string으로 나타냅니다.
console.log(response.statusText);
// 서버에서 보낸 response header 값들을 볼 수 있습니다.
console.log(response.headers);
});
```

## 기본적인 사용법

OMS에서는 아래와 같은 방법으로 주로 사용합니다.

```js
import ajax, { ajaxHeaders, failure } from 'utils/Ajax';

// Get 방식 요청
const config = {
	headers: ajaxHeaders,
	params: {
		company: 'SKHYNIX', // 넘겨줄 데이터
	},
};
const success = (response) => {
	console.log(response.data);
};
const doFinally = () => {
	console.log('반드시');
};
ajax.get('url', config).then(success).catch(failure).finally(doFinally);

// Post 방식 요청
const responseBody = {
	userId: 'show5116',
	userName: '유영진',
};
const config = {
	headers: ajaxHeaders,
};
const success = (response) => {
	console.log(response.data);
};
const doFinally = () => {
	console.log('반드시'); // 요청 성공 실패 여부를 떠나 반드시 실행해야 하는 함수
};
ajax.post('/url', data, config).then(success).catch(failure).finally(doFinally);
```

## 에러

OMS에서는 utils/ajax.ts에 faulure가 정의되어 있어서, 기본적으로는 가져다가 사용하면 됩니다. 
하지만 특수한 상황에서는 에러메시지를 숨긴다던지, 혹은 실패했을 경우 다른 액션이 필요할 때, 
혹은 에러가 나는 원인이 프론트엔드인지를 찾을 때, 직접 에러 핸들러를 추가해서 사용해주면 됩니다.

```js
ajax.get('/url').catch((error) => {
	if (error.response) {
		// 요청은 전송되었으나, 응답코드가 2xx가 아닐경우
		console.log(error.response.data);
		console.log(error.response.status);
		console.log(error.response.headers);
	} else if (error.request) {
		// 요청은 전송되었는데, 응답이 수신되지 않았을 경우
		console.log(error.request);
	} else {
		// 요청을 보내는데 실패한 경우(프론트엔드 문제)
		console.log(error.message);
	}
});
```

## interceptors

axios인스턴스를 만들면 interceptor를 적용시킬 수 있는데, 
이로 인해 request 요청에 필요한 헤더를 편하게 세팅해주기도 하고, 
response에서 오는 요청에 특별한 이벤트를 걸어줄 수 도 있습니다.

```js
// Interceptor를 사용하기 시작
const requestInterceptor = ajax.interceptors.request.use(
	(request) => {...} ,
	(error) => {...}
);
const responseInterceptor = ajax.interceptors.response.use(
	(response) => {...} ,
	(error) => {...}
);

// Interceptor를 제거
ajax.interceptors.request.eject(requestInterceptor);
ajax.interceptors.response.eject(responseInterceptor);
```

현재 OMS에서는 로그인, 로그아웃, 그리고 토근에 관련되어서 interceptors가 사용되고 있고, 
이는 [auth 포스트](/post/front-end/auth)에서 더 자세히 다룹니다.

## 요청취소

취소토큰을 이용해 취소가 필요할 때 요청 취소를 할 수 있습니다. 
취소토큰은 **지원중단된** proposal-cancelable-promises를 기반으로 하고 있습니다. 
프론트에서 어떠한 동작에 의해서 취소시켜야 할 경우에만 사용할 것을 추천드리고,(요소를 제거) 
xception에 대한건 백엔드에서 처리할 것을 추천드립니다. 
사용 방법에는 2가지 방식이 있고, 코드스타일의 차이만 존재하고 기능은 같습니다.

### source 방식

```js
const CancelToken = axios.CancelToken;
const source = CancelToken.source();
const config = {
	cancelToken: source.token,
};
ajax.get(url, config).catch((error) => {
	if (axios.isCancel(error)) {
		console.log('캔슬되었습니다.' + error.message);
	}
});

setTimeout(() => {
	source.cancel('시간초과');
}, 500);
```

### 생성자 방식

```js
const CancelToken = axios.CancelToken;
let cancelRequest;
const config = {
	cancelToken: new CancelToken((c) => (cancelRequest = c)),
};
ajax.get(url, config).catch((error) => {
	if (axios.isCancel(error)) {
		console.log('캔슬되었습니다.' + error.message);
	}
});

setTimeout(() => cancelRequest(), 500);
```

비동기 통신 라이브러리인 axios의 설정 및 사용법에 대해 알아보는 글입니다.

Axios

MarkDown파일은 사용법이 쉽고, 빠르게 문서를 정리할 수 있는 장점이 있습니다. 
확장자는 **.md**로 HTML 마크업을 대신하여서 표현되고 있습니다. 
각 프로젝트의 **README.md** 처럼 글씨와 간단한 이미지로 표현하는 문서입니다. 
현 프로젝트의 모든 글들은 mdx파일들로 이루어져 있습니다.

## .mdx

mdx파일은 .md파일과 동일한 문법으로 작성이 되는데, 
거기에 더불어 리엑트 컴포넌트와 함께 사용이 가능한 확장자입니다. 
따라서 현재 OMS-Tech-Blog는 MDX Remote를 이용해 .mdx파일을 해석하고, 
이를 하나의 블로그 글처럼 만들어주는 역할을 하고 있습니다.

## 마크다운 문법

마크다운의 문법은 기본적인것은 비슷하나, 
적용되는 컨텐츠에 따라 약간씩 다르게 적용될 수 있습니다. 
ex) github, bitbucket등의 사이트에서 README.md도 서로 다르게 적용됩니다.

### frontmatter

frontmatter는 파일 시작 시 파일에 대해 작성하는 구역입니다. 
파일에 맨 위에 파일에 대한 정보를 작성해 주면 됩니다.

```md
---
title: 'MarkDown 작성법'
date: '2023-04-03'
description: 'OMS-Tech-Blog에서 mdx 파일 작성법에 대한 글입니다.'
authorId: 'show5116'
authorName: '유영진'
tags: ['md']
thumbnail: '/front-end/markdown.png'
---
```

### 제목

`<h1>` 태그부터 `<h6>` 태그 까지 제목을 표현할 수 있습니다.

```md
	제목 작성법
	# 제목 1
	## 제목 2
	### 제목 3
	#### 제목 4
	##### 제목 5
	###### 제목 6
```

### 강조

```md
이텔릭체는 *별표(asterisks)*를 사용하세요.
강조는 **별표(asterisks)** 또는 `백틱(backtick)`을 사용하세요.
<del>취소선은</del> `<del></del>`를 사용하세요.
밑줄은 ``를 사용하세요.
```

이텔릭체는 *별표(asterisks)*를 사용하세요.
강조는 **별표(asterisks)** 또는 `백틱(backtick)`을 사용하세요.
<del>취소선은</del> `<del></del>`를 사용하세요.
밑줄은 ``를 사용하세요.

### 목록

`<ol>`, `<ul>` 목록 태그로 변환됩니다.

```md
1. 순서가 필요한 목록

2. 순서가 필요한 목록
 - 순서가 필요하지 않은 목록(서브)
 - 순서가 필요하지 않은 목록(서브)

3. 순서가 필요한 목록
 1. 순서가 필요한 목록(서브)
 2. 순서가 필요한 목록(서브)

4. 순서가 필요한 목록

- 순서가 필요하지 않은 목록에 사용 가능한 기호
 - 대쉬(hyphen)
 * 별표(asterisks)
 + 더하기(plus sign)
```

1. 순서가 필요한 목록

2. 순서가 필요한 목록
 - 순서가 필요하지 않은 목록(서브)
 - 순서가 필요하지 않은 목록(서브)

3. 순서가 필요한 목록
 1. 순서가 필요한 목록(서브)
 2. 순서가 필요한 목록(서브)

4. 순서가 필요한 목록

- 순서가 필요하지 않은 목록에 사용 가능한 기호
 - 대쉬(hyphen)
 * 별표(asterisks)
 + 더하기(plus sign)

### 링크

외부 링크는 `<a>`태그로 변환되고, 
내부 링크는 Next.Link로 변환됩니다.

```md
[GOOGLE](https://google.com)

[NAVER](https://naver.com "링크 설명(title)을 작성하세요.")

[상대적 참조](/about)

[제목](#제목)
```

[GOOGLE](https://google.com)

[NAVER](https://naver.com "링크 설명(title)을 작성하세요.")

[상대적 참조](/about)

[제목](#제목)

### 이미지

외부 링크는 `<img>`태그로 변환되고, 
이미지 파일은 Next.Image로 변환됩니다.

```md
![대체텍스트를 작성해주세요.](http://www.gstatic.com/webp/gallery/1.jpg)
![대체텍스트란에 사이즈 지정이 가능합니다. size:800*600](http://www.gstatic.com/webp/gallery/1.jpg "링크 설명(title)을 작성하세요.")
![프로젝트내 이미지 파일은 사이즈 지정을 하지 않으면 고정된 크기로 나옵니다.](/front-end/dog.png)
![사이즈 지정을 해주세요 size:500*300](/front-end/dog.png)
```

![대체텍스트를 작성해주세요.](http://www.gstatic.com/webp/gallery/1.jpg)
![대체텍스트란에 사이즈 지정이 가능합니다. size:800*600](http://www.gstatic.com/webp/gallery/1.jpg "링크 설명(title)을 작성하세요.")
![프로젝트내 이미지 파일은 사이즈 지정을 하지 않으면 고정된 크기로 나옵니다.](/front-end/dog.png)
![사이즈 지정을 해주세요 size:500*300](/front-end/dog.png)

### 이미지에 링크

이미지안에 링크를 사용할 수 있습니다.

```md
[![Google size:330*130](/front-end/google.png)](https://www.google.com/)
```

[![Google size:330*130](/front-end/google.png)](https://www.google.com/)

### 코드블록

코드 종류에 따라 블록을 작성할 수 있습니다. 
백틱 3번과 그 옆에 언어 종류를 적어주시면 됩니다. 
**주의 remoteMdx 라이브러리가 `java`를 지원하지 않아 하이라이터 적용이 안됩니다.**

````md
```java
String a = "aa";
```

```sql
SELECT a.* FROM user a;
```

```yml
spring:
	post: 8081
```

```html
<h2>안녕하세요</h2>
```

```css
a {
	background: black;
}
```

```ts
const a: string = 'aa';
```

```tsx
<Link>
	{Array(5)
	.fill(null)
	.map((item, index) => (
		{index}번째 입니다.
))}
</Link>
```

```bash
yarn start
git pull origin master
```

```groovy
dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.boot:spring-boot-starter-webflux'
}
```
````

```java
String a = "aa";
```

```sql
SELECT a.* FROM user a;
```

```yml
spring:
	post: 8081
```

```html
<h2>안녕하세요</h2>
```

```css
a {
	background: black;
}
```

```ts
const a: string = 'aa';
```

```tsx
<Link>
	{Array(5)
	.fill(null)
	.map((item, index) => (
		{index}번째 입니다.
))}
</Link>
```

```bash
yarn start
git pull origin master
```

```groovy
dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.boot:spring-boot-starter-webflux'
}
```

### 인용문

`<blockquote>` 태그로 변환됩니다.

```md
인용문(blockQuote)

> 남의 말이나 글에서 직접 또는 간접으로 따온 문장. 
> _(네이버 국어 사전)_

break!

> 인용문을 작성하세요!
>> 중첩된 인용문(nested blockquote)을 만들 수 있습니다.
>>> 중중첩된 인용문 1 
>>> 중중첩된 인용문 2 
>>> 중중첩된 인용문 3 
```

인용문(blockQuote)

> 남의 말이나 글에서 직접 또는 간접으로 따온 문장. 
> _(네이버 국어 사전)_

break!

> 인용문을 작성하세요!
>> 중첩된 인용문(nested blockquote)을 만들 수 있습니다.
>>> 중중첩된 인용문 1 
>>> 중중첩된 인용문 2 
>>> 중중첩된 인용문 3 

### 수평선

`<hr>`태그로 변환됩니다.

```md
---
(Hyphens)

***
(Asterisks)

___
(Underscores)
```

---
(Hyphens)

***
(Asterisks)

___
(Underscores)

### 줄바꿈

` `태그를 사용하거나, 띄어쓰기 2번을 이용해 줄바꿈을 할 수 있습니다.

```md
동해물과 백두산이 마르고 닳도록
하느님이 보우하사 우리나라 만세 
무궁화 삼천리 화려 강산 
대한 사람 대한으로 길이 보전하세
```

동해물과 백두산이 마르고 닳도록
하느님이 보우하사 우리나라 만세
무궁화 삼천리 화려 강산 
대한 사람 대한으로 길이 보전하세

### JSX 태그

JSX 태그를 그대로 사용할 수 있습니다.

```md

	빨간색 
	<a href='/front-end/downloadMdx.mdx' download>예시 다운로드</a>
	<div
		style={{
			width: 0,
			height: 0,
			borderBottom '50px solid transparent',
			borderTop: '50px solid transparent',
			borderLeft: '50px solid skyblue',
			borderRight: '50px solid transparent',
		}}
	></div>

```


	빨간색 
	<a href='/front-end/downloadMdx.mdx' download>예시 다운로드</a>
	<div
		style={{
			width: 0,
			height: 0,
			borderBottom: '50px solid transparent',
			borderTop: '50px solid transparent',
			borderLeft: '50px solid skyblue',
			borderRight: '50px solid transparent',
		}}
	></div>


### 요약

펼쳐졌다 닫히는 details 태그를 사용할 수 있습니다.

```md
<details>
	<summary>요약입니다.</summary>
	Elit voluptate labore eiusmod aliqua in excepteur ea in.
</details>
```

<details>
	<summary>요약입니다.</summary>
	Elit voluptate labore eiusmod aliqua in excepteur ea in.
</details>

### 커스텀 기능

```md
**주의 주의사항 입니다.** 
강조구문에 주의 라는 글자로 시작하면 주의 구문이 생성됩니다.
```

**주의 주의사항 입니다.** 
강조구문에 주의 라는 글자로 시작하면 주의 구문이 생성됩니다.

## IDE 활용

.md 파일의 경우에는 **Intellij**와 **VS Code**에서 자동완성, 미리보기를 지원합니다. 
이를 활용해 작성하게 되면 좀더 편리하게 가능합니다.

OMS-Tech-Blog에서 mdx 파일 작성법에 대한 글입니다.