🤔 서론 Exception Handler 를 구현하다 리펙토링 한 경험을 작성합니다. 🫢 본론 기존 Exception 은 상황에 맞게 각각 Custom Exception 을 만들어서 처리를 했습니다. 문제점 Exception 마다 각각의 Handler 를 만들어주어야 했습니다. 클래스는 통합해서 작성해도 되지만, 여기서 중요한 건 만든 각각의 Custom Exception 별로 별도의 Handler를 추가로 계속 작성해주어야만 했습니다. 중복된 코드 private static final String MESSAGE = "패스워드가 일치하지 않습니다"; @ExceptionHandler(value = {PasswordMismatchException.class, BadCredentialsException.cla..
😮 서론 간단한 사이트들을 제외하고, 대부분의 사이트에서는 회원 기능이 존재합니다. 회원 정보를 통해서 가입된 사이트에 글을 쓰거나, 읽거나 댓글을 달거나 문의를 넣거나 등등 다양한 기능들을 사용할 수 있게 되는데요! 하지만, 페이지를 옮겨다닐 때마다 회원 인증을 진행하고, 껐다가 켰을 때마다 다시 인증을 진행하고 이런 일은 .. 제가 아는 사이트에선 존재하지 않습니다. 이처럼 인증을 유지하기 위한 방법 중 세션 방식과 토큰 방식에 대해 장단점을 알아보고 어떤 걸 사용할지 정해보도록 하겠습니다. 😏 본론 인증(Authentication) / 인가(Authorization) 기본 개념부터 잡고 가도록 하겠습니다. 인증(Authentication) 내가 누군지에 대해 사이트에 인증받는 걸 얘기합니다. 보통..
😀 서론 @Secured("ROLES_GUEST") 기존 권한 관리방법은 매직리터럴로 처리가 되어 있었습니다. 이는 오타날 가능성도 있고, 나중에 관리하기도 힘들다는 판단을 하였고, 이를 enum 으로 처리한 과정을 정리해봅니다. 🥸 본론 @Secured 애노테이션의 value는 String[] 를 받도록 정의되어 있기 때문에 enum 값을 받지 못합니다. 그러면 어떻게 해야할까? @RequiredArgsConstructor public enum UserGrade { ADMIN(ROLES.ADMIN, null), STAFF(ROLES.STAFF, ROLES.ADMIN), GUEST(ROLES.GUEST, ROLES.STAFF); private final String roleName; private fin..
🙂 서론 제가 느끼기엔 properties 보다는 yaml 파일이 더 가독성이 좋아 관리하기 쉽다고 생각합니다. 설정 파일을 불러와 객체를 만들 때 보통 @PropertySource 애노테이션을 사용하지만, default로 yaml을 읽지 못합니다. 그렇다고, yaml과 properties를 같이 사용하는 건 통일성이 없고, 그럴 필요가 없다 생각됩니다. 그렇기 때문에 이를 yaml 파일을 읽을 수 있도록 설정한 방법을 정리해봅니다. 😛 본론 가져올 yml 파일의 설정 값입니다. @Getter @RequiredArgsConstructor @ConstructorBinding @ConfigurationProperties(value = "jwt") @PropertySource(value = "classpath..
🥹 서론 이번 토이 프로젝트에서 Redis를 도입하기로 하여 Redis에 대해 학습한 내용을 정리해봅니다. Redis에 대해서 알아보기 전에 Cache에 대해 이해가 필요하신 분은, 아래 링크를 확인해주세요! [Network] 캐시(Cache) 알아보기 😗 본론 Redis (Remote Dictionary Server) 란? in-memory 형태의 No-SQL로써 Key-Value 쌍의 해쉬 맵 형태의 데이터베이스입니다. in-memory: disk가 아닌 memory에 저장하기 때문에 disk I/O 작업이 발생하지 않아 속도가 빠르며, 휘발성입니다. No-SQL: Not Only SQL를 뜻하며 RDBMS에 비해 속도가 빠른 장점이 있습니다. in-memory 종류 No-SQL 종류 대표적인 비교 ..
🥹 서론 하나하나 차근차근 🙂 본론 캐시란? 자주 사용되는 결과 데이터를 미리 캐시 공간에 저장해서 다음 호출 때 빠르게 결과를 전달 캐시를 사용하는 이유 캐시를 사용하는 이유는 속도에 있습니다. 기본적으로 데이터가 저장되는 공간은 Disk입니다. 이유는 다른 Registers, Cache, Memory 들에 비해 저렴하고, 용량이 크기 때문입니다. 하지만, 그림에서 보시다시피 속도가 제일, 매우 느린 편에 속합니다. 엄청 잘 되는 서비스 같은 경우 디스크에서만 계속 불러오게 되면 속도가 따라주지 못해 결국 병목현상이 발생할 수 있습니다. 그럼 모든 데이터를 캐시에 넣어? 캐시는 휘발성을 띕니다. 이 말은, 컴퓨터를 껐다가 켜면 저장된 데이터가 전부 날아간다는 걸 의미합니다. 그리고, 가격 측면에서 ..
🙂 서론 이번 Project 에서 코드는 java를 사용하고, 빌드툴은 Kotlin Gradle DSL 을 사용하기로 하였습니다. Gradle에 대해서도 한 번 정리하면 좋을 것 같아서 글을 적어봅니다. 😁 본론 Gradle 이란? https://github.com/gradle/gradle Gradle 은 빌드 자동화 및 다국어 개발 지원에 중점을 둔 빌드 도구입니다. 모든 플랫폼에서 소프트웨어를 Building, Testing, publishing, deploying 하는 경우 Gradle 은 코드 컴파일 및 패키징에서 웹 사이트 게시에 이르기까지 전체 개발 수명 주기를 지원할 수 있는 유연한 모델을 제공합니다. Gradle은 Java, Scala, Android, Kotlin, C/C++ 및 Gro..
🥸 서론 이번 프로젝트를 진행하면서 항상 그렇듯 ERD (Entity Relationship Diagram) 을 작성했습니다. 기존에 제가 사용해왔던 ERD 작성 툴은 2가지가 존재했습니다. ERD Cloud eXERD eXERD 는 유료버전이며, ERD 를 수정 및 보는 사람은 프로그램을 설치 해야한다는 단점이 존재하여 사이트 형식인 ERD Cloud 를 선택했습니다. 하지만 ERD Cloud 에도 단점이 존재했는데요, 바로 회원가입을 해야하고, 사용자 측면에서는 접근성이 떨어진다는 점입니다. 이번 프로젝트는 public 프로젝트이기 때문에 개발자 외에도 ERD 또한 공유하는 것이 목적이었고, 빠른 접근성을 원했습니다. 그렇게 해서 알게 된 다이어그램 mermaid js 에 대해서 공유하려 합니다. 🤪..
