DB 수정사항 + Token들 저장 위치 결정 (이유)

Entity를 만들면서 생각을 해보니 DB 구조를 몇개 수정해야겠다고 생각이 들었습니다.

 

일단 BaseEntity를 만드는 과정에서 원래는 없었던 수정일자를 추가했습니다.

 

@MappedSuperclass
public abstract class BaseEntity {

	@Id
	@GeneratedValue
	private Long id;

	@CreatedDate
	@Column(nullable = false, updatable = false)
	private LocalDateTime createdAt;

	// 추가
	@LastModifiedDate
	@Column(nullable = false)
	private LocalDateTime modifiedAt;
}

 

 

또한 Like Entity를 구현하다 댓글과 게시글 좋아요를 나눴습니다.

생각보다 좋아요를 조회하거나 추가, 삭제할 일이 많을 것 같아 나누는게 맞다고 판단되었습니다.

 

// 댓글 좋아요
@Entity(name = "comment_likes")
public class CommentLike extends BaseEntity {

	@Column(nullable = false)
	private Long userId;

	@Column(nullable = false)
	private Long commentId;

}

// 게시글 좋아요
@Entity(name = "post_likes")
public class PostLike extends BaseEntity {

	@Column(nullable = false)
	private Long userId;

	@Column(nullable = false)
	private Long postId;
}

 

 

Entity를 만들다보니 위에서 말했던 것 처럼 또 이렇게 DB 구조가 바뀌었다.

 

 

 

또 수정될거 같긴 합니다..


개발하다보니 자꾸 자꾸 생각나고 바뀌는게 많더라구요

 

보안을 위해 Spring Security를 선택하고 JWT를 통해

AccessToken과 RefreshToken을 통해 유저 인증을 할 계획입니다.

 

지금 그렇게 구현중이구요!

 

AccessToken과 RefreshToken을 어디에 저장할지 고민을 많이 했는데AccessToken은 클라이언트 스토리지에 저장하고 RefreshToken은Redis를 채용하여 캐시에 저장하기로 했습니다.

 

AccessToken을 클라이언트에 저장하기로 한 이유는 주로 짧은 유효기간과 요청마다
AccessToken이 포함될 예정이라 굳이 서버에 저장할 필요가 없다고 생각했습니다.
(탈취 시 피해를 줄이기 위해 유효기간 1시간!)

RefreshToken을 캐시에 저장하기로 한 이유는 디스크 기반인 DB에 저장했을때보다

메모리 기반인 캐시가 속도가 빠르고

TTL 설정이 쉽기 때문입니다.

 

얼른 회원가입을 구현하며 SMTP를 사용한 이메일 인증을 구현하는 글로 돌아오겠습니다.

 

 

반말 했다가 높임말했다가 해도 이해해주세요 그냥 제 생각을 막 쓰다보니 ^_^