[Redis] 명령어 정리
·
CheetSheet
Redis는 빠른 성능과 다양한 데이터 구조를 제공하는 인메모리 데이터베이스입니다. 이 글에서는 Redis의 주요 명령어를 데이터 구조별로 정리하고, 실제 활용 예를 통해 각 명령어의 사용법을 알아보겠습니다.1. StringString은 가장 기본적인 데이터 구조로, Key-Value 형태로 데이터를 저장합니다.# 데이터 저장 및 조회SET user:email abc@example.comGET user:email정수가 문자열로 저장된 경우# 정수 증감 연산SET user:count 1INCR user:count # ++DECR user:count # --GET user:count여러 Key-Value 동시 처리# 멀티 SET, 멀티 GETMSET user:name alex user:email al..
[SPRING CLOUD] 주요 모듈에 대한 개념 짚고 가기
·
Study/SPRING
소프트웨어 개발은 변화하고 있습니다. 특히, 마이크로서비스 아키텍처(Microservices Architecture)는 대규모 애플리케이션을 작고 독립적인 서비스로 분리함으로써 더 나은 확장성과 유연성을 제공합니다. 하지만 분산된 서비스 환경에서는 복잡한 문제들도 함께 등장합니다. 이 문제를 해결하기 위해 등장한 것이 바로 Spring Cloud입니다. Spring Cloud는 마이크로서비스 아키텍처를 쉽게 설계하고 운영할 수 있도록 다양한 도구와 기능을 제공합니다. 이번 글에서는 Spring Cloud의 개념과 주요 기능, 그리고 각 모듈의 실용적인 사용법을 하나씩 알아보겠습니다. Spring Cloud란?Spring Cloud의 정의Spring Cloud는 스프링 프레임워크 기반의 확장 모듈로, ..
JWT 어디에 담아야 하나요?
·
Study/ARCHITECTURE
JWT 전송 방식과 쿠키 및 헤더의 장단점JWT(JSON Web Token)는 인증 및 권한 부여의 핵심적인 역할을 하는 토큰입니다. JWT를 전송할 때는 일반적으로 쿠키나 헤더를 사용하게 되며, 각각의 방법에는 고유한 장점과 단점이 있습니다.프로젝트를 진행할 때 마다 의문이 드는 부분이어서 임은지 멘토님께 질문을 드리고 답변받은 내용을 정리하였습니다.JWT를 담을 수 있는 곳: 쿠키 vs 헤더1. 쿠키의 장단점✅ 장점보안 강화 가능: HttpOnly 옵션을 통해 쿠키에 저장된 JWT를 JavaScript에서 접근하지 못하도록 보호할 수 있습니다. 이는 XSS(크로스 사이트 스크립팅) 공격으로부터 안전하게 해줍니다.❌ 단점모바일 환경의 제약: 네이티브 모바일 애플리케이션에서는 쿠키를 직접적으로 사용할 수..
MSA(Microservices Architecture): 시작하기 전에 알아야 할 장단점과 구조
·
Study/ARCHITECTURE
MSA(Microservices Architecture)는 복잡한 시스템을 작은 독립적인 서비스로 나누어 개발하는 아키텍처 스타일입니다. 이러한 구조는 서비스별로 독립적인 개발, 배포, 확장이 가능하여 유연성과 효율성을 제공합니다. 하지만, MSA의 도입은 많은 장점과 동시에 몇 가지 단점을 동반하므로, 이를 충분히 이해한 후 결정하는 것이 중요합니다. 이번 글에서는 MSA의 장단점과 전체적인 구조에 대해 살펴보겠습니다.MSA의 장점독립적인 배포와 확장성각 서비스는 독립적으로 배포되고 확장될 수 있습니다. 이를 통해 한 서비스의 변경이나 확장이 다른 서비스에 영향을 미치지 않으며, 특정 서비스에 부하가 증가할 경우 그 서비스만 확장하면 됩니다. 이와 같은 유연한 확장성 덕분에 자원 관리가 효율적입니다.개..
[SPRING BOOT] Swagger 설정하기 (핵심만 간단히)
·
Study/SPRING
Swagger는 API 문서를 자동으로 생성하고 테스트할 수 있는 도구로, Spring Boot에서는 springdoc-openapi 라이브러리를 사용하여 쉽게 설정할 수 있습니다.SpringBoot 버전: 3.3.5springdoc-openapi 버전: 2.6.0아래는 핵심 설정 방법입니다.1. 의존성 추가먼저, springdoc-openapi 의존성을 프로젝트의 build.gradle 파일에 추가합니다.dependencies { implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.6.0'}2. Swagger 설정 파일 작성Swagger를 구성하기 위한 설정 클래스를 만듭니다. 이 클래스는 OpenAPI와 Swagger UI의 ..
[SPRING BOOT] QueryDSL 설정하기
·
Study/SPRING
이번 글에서는 Spring Boot 프로젝트에서 QueryDSL을 설정하는 방법을 다루어 보겠습니다. QueryDSL은 JPA를 사용하면서 타입 안전한 쿼리를 작성할 수 있는 강력한 도구로, 복잡한 쿼리를 더 간단하고 직관적으로 작성할 수 있습니다.SpringBoot: 3.3.51. QueryDSL 설정을 위한 환경 준비Gradle 설정 (build.gradle)프로젝트에서 QueryDSL을 사용하려면 의존성을 추가하고, QueryDSL의 코드를 생성할 디렉토리를 설정해야 합니다. 아래는 build.gradle 파일의 설정 예시입니다.plugins { id 'java' id 'org.springframework.boot' version '3.3.5' id 'io.spring.depende..
[ SPRING BOOT] 일관된 API 응답을 위한 유틸 클래스 만들기
·
Study/SPRING
Java에서 일관된 API 응답을 위한 유틸 클래스 만들기RESTful API를 설계할 때 가장 중요한 요소 중 하나는 일관된 응답 형식입니다. 클라이언트는 API 응답이 일정한 구조를 가지고 있어야 성공과 실패를 쉽게 구분할 수 있으며, 이는 디버깅과 유지보수를 더욱 간단하게 만듭니다. 이 글에서는 Java에서 통합된 응답 형식을 제공하기 위해 작성한 유틸리티 클래스를 소개하고, 이를 통해 API의 일관성을 어떻게 유지할 수 있는지 살펴보겠습니다.설계 목표유틸 클래스의 설계 목표는 다음과 같습니다:성공과 실패에 대해 통합된 응답 형식 제공클라이언트는 성공(success) 또는 실패(error) 여부를 예측할 수 있어야 합니다.간결한 에러 메시지 전달예외 처리 시 명확한 에러 메시지를 반환하여 클라이언트..
[SPRING BOOT] 전역 예외 처리 핸들러 및 Enum 으로의 관리
·
Study/SPRING
Spring의 AOP스프링의 주요 철학중 AOP(관점 지향 프로그래밍)는 로직에서의 핵심 관점과 부가 관점을 나누고 각 관점을 기준으로 모듈화를 하는 것입니다.조회를 하는 비즈니스 로직의 경우 Id로 데이터를 조회하고 잘 가공해서 내보내 주는게 핵심 관점이고 조회한 데이터가 없다면 이 후 어떻게 처리해야 하는가 는 부가 관점인 것입니다.그렇다면 비즈니스 로직이 있는 서비스 단에서는 데이터가 존재하는지 체크만 하고 없다면 Exception을 발생 시키는 방식으로 핵심 관점에만 집중 할 수 있게 됩니다.@ExceptionHandler는 스프링 프레임워크에서 예외 처리를 위한 어노테이션으로, 특정 컨트롤러나 글로벌하게 예외 상황을 핸들링할 수 있는 메서드를 지정하는 데 사용됩니다.이 어노테이션을 사용하면 특정..
[JUNIT] Mockito를 이용한 Service Layer 단위 테스트
·
Study/TEST
기본 개념부터 짚고 넘어가기UNIT 테스트를 하는 이유unit 테스트는 쉽게 말하면 메소드 단위로 테스트 하는것이라고 생각한다.SpringBoot에서 웹서비스를 제공하기 위해 필요한 요소들을 생각해보면HTTP 요청을 받아 줄 WAS(톰캣)요청별로 처리해 주는 Dispathcer Servlet시큐리티 등과 같은 각종 설정들과 Bean 들컨트롤러, 서비스 등의 BeanDB (테스트용 H2, 혹은 활성화 상태의 DB)등등 각종 Bean을 등록하고 프로그램들이 실행되어야 웹 서비스를 제공할 수 있다.하지만 서비스의 하나의 메소드만 테스트 하고 싶을 때 모든 것들이 필요할까?매번 테스트 할때마다 서버가 활성화 될때 까지 기다리는 시간비용은 얼마나 들까?UNIT 테스트를 하는 이유는 여기에 있다.잘 작동하는지 궁금..
[SpringBoot] Entity의 생성자 범위
·
Study/SPRING
서론프로젝트에서 내가 맡은 도메인의 로직을 개발 및 테스트하고 기쁜 마음으로 PR을 날렸다.프로젝트 초기이다 보니 꽤나 방대한 양의 코드를 한번에 PR 하게 되었다(반성 중이다..)팀원들의 코드리뷰를 잘 받을 수 있을까 하고 걱정 하였으나 팀원 분들께서 매우 꼼꼼하게 리뷰를 해주셨다.특히나 Entity 부분에서 크게 생각 없이 작성한 부분이 있다는 것을 깨닫고 '내가 왜 이렇게 작성을 하였을까?' 하고 되짚어 보고 다시 공부를 해보았다.코드리뷰(엔티티의 생성자 범위까지 꼼꼼하게 봐주셨다 ㅎㅎ)왜 Entity의 생성자를 protected로 하셨나요?사실 나는 저기에 protected 를 해둔거도 잊고 있었다. 다시금 고민해 보니 protected 를 할 이유가 없어보인다.나의 원래 목적은 빌더패턴을 이용하..