잡동사니

REST API란 뭘까? 많이 들어는 봤는데 개념이 모호하다.지금부터 이에 대해 간단히 알아보자. 시작하기 전 이 글은 진정한 의미의 REST API가 아닌 개발자들이 일반적으로 알고 쓰는 수준의 REST API 이다.REST API는 정보들이 주고받아지는 데 있어서

빈 스코프 공부를 하면서 제일 어려웠던 부분을 다시 정리해보았다.웹 스코프를 이용한 예제를 개발해보자.동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다.이럴때 사용하기 딱 좋은것이 바로 request 스코프이다.다음과 같이 로그가 남도

다음과 같은 상황을 가정해보자.피자 셰프가 레시피를 봐야만 피자를 만들 수 있다. 요리사는 레시피가 변경되면 새로운 피자를 만들게 된다. 따라서, 요리사는 레시피에 의존하는 관계라 할 수 있다.이를 간단히 코드로 살펴보자.PizzaChef 객체는 PizzaRecipe

검증1의 ValidationItemControllerV1에서 검증 오류 발생시 기존 데이터가 보존되는 원리를 자세히 알아보자.컨트롤러 구현부를 보자.ValidationItemControllerV1의 일부분addForm() 메소드를 보면 모델에 Item 빈 객체를 넣어주

서블릿이 제공하는 HttpSession을 이용하여 로그인을 처리했다.일단, 세션의 동작 방식을 간단히 복습해보자.클라이언트가 서버로부터 로그인 요청을 한다.서버는 요청 로그인 id값마다 고유의 sessionId값을 만들어 세션 저장소에 저장한다.세션 저장소 : Map

웹 브라우저에서 서버가 요청을 받고 응답을 보내는 과정 중 컨트롤러에서 예외가 발생했다. 이러한 경우 서블릿에서 예외가 어떻게 처리되는지 알아보자. Filter 코드를 보자. 이 코드를 보면, 마치 필터의 try-catch 문에서 예외를 처리하는 것 처럼 보인다.

WAS와 웹서버의 개념을 정리해보았다. 간단히 알아보자.일단 서버의 개념을 짚고가자. 서버는 컴퓨터라고 생각하자.같은 컴퓨터도 서비스를 해주느냐 제공받느냐에 따라 서버와 클라이언트로 나뉜다.서버는 다른 의미로도 사용이 되는데 어떤 컴퓨터로 하여금 서버 역할을 하도록 해

지금까지 스프링의 MVC에 대해 자세히 공부를 했었다. 그러나 MVC의 기본적인 개념들이 모호하여 정리해보았다.간단한 사이트를 정적 웹으로 구현한다고 하면 어떨까? 이는 별 문제가 없을 것이다.그러나 대규모의 사이트(네이버나 구글)들을 정적 웹으로만 구현하라고 하면 어

기존 필터와 인터셉터의 개념이 좀 모호했는데 좀 자세히 정리해보았다. 필터 필터(Filter)는 J2EE 표준 스펙 기능으로 디스패처 서블릿(Dispatcher Servlet)에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대해 부가작업을 처리할 수 있

DB를 연동하여 프로젝트를 할 때 테스트 용 SQL을 작성하여 서버 실행마다 DB에 샘플 데이터를 저장하고 싶으면 어떻게 할까? 일일히 서버를 실행하고 작성한 SQL을 실행하는 것은 매우 번거로울 것이다.먼저 application.properties 에 다음을 추가하자

다른 엔티티와 일대다 관계를 가진 엔티티를 조회하는 과정에서 다음 문제가 발생했다. 구글링을 해보니 지연로딩으로 인해 연관관계를 가지고 있는 엔티티가 제때 호출이 안된 것이였다. 조회하려는 엔티티와 이와 연관관계를 맺고 있는 엔티티는 다음과 같다.Owner 와 일대다

컨트롤러에서 요청 메시지 바디에 있는 정보를 통해 엔티티 컬럼을 추가하는 과정에서 다음 오류가 발생했다.컨트롤러에서 호출된 메소드와 요청 메시지 바디에 담긴 정보는 다음과 같다.여기서 사용되는 엔티티들은 다음과 같다.Owner 엔티티와 다대일 관계이다.FK를 가진다.S

APM(Application Performace Monitoring)을 통해 프로젝트 부하 테스트를 진행하던 중 병목 현상이 발생했다. 초당 100건의 요청을 보낸 결과 (실전에서 본인이 맡은 부분이 이러면 똥줄 탄다고 한다.)빨간색 : 실패파란색 : 성공현재 WAS와

지난 우아한테크코스 6기 프리코스를 진행하면서 Getter를 지양하는 것을 항상 목표로 삼았다. 물론, 도메인을 조회를 하는 경우 Getter는 가히 필수적이다. 그럼 어떤 상황에서 Getter를 지양해야 될까? 더 나아가 왜 사용하면 안될까? (사용하면 진짜 편하던

Value Object(값 객체, 이하 VO) 객체에 대해 알아보자. 내가 생각하는 VO 도입 이유와 장점을 서술해보려 한다.VO는 단어 그대로 값을 저장하는 객체이다. 특정 또는 여러 도메인의 값을 나타내는 역할이다.자동차 경주를 생각해보자. Car 객체는 크게 이름

Spring Boot를 통해 프로젝트를 진행한다면 계층 간 데이터 전달 시 DTO 클래스 사용은 필수다. 그러나 이를 왜 사용하는지, 사용한다면 어떤 장점이 있는지에 대해 놓치고 있는 것 같아 자세히 정리해보려 한다.추가로, Spring Boot에서 사용하는 5 Lay

DB에서 자주 조회해야 하는 데이터가 있다고 생각해보자. 매 요청마다 해당 데이터를 DB에서 가져가 준다면 엄청난 성능 저하가 발생할 것이다. 만약, 게임 사이트 메인 페이지에서 레벨이 높은 100명의 유저 정보를 보여준다고 생각해보자. 유저 정보는 변동성이 상대적으로

결제 관련 데이터를 받는 상황을 생각해보자. 결제 수단은 아래와 같다. 신용카드 계좌 이체 간편 결제 상품권 값을 4가지로 제한되므로 아래 열게체를 활용하여 요청을 받을 수 있다. public class PaymentController { @PostMappi

시작하기 전 QueryDSL의 경우 버전별 문법 차이가 존재합니다. 아래 QueryDSL 버전은 Querydsl-JPA 4.2.1 입니다. > 버전이 5.X라면 아래 내용과 상이할 수 있습니다. 1. extends / implements 사용하지 않기 > JPAQu

최근 프로젝트에서 소셜 로그인 구현을 맡게되어 관련 코드를 공유하고자 합니다. 일단 소셜 로그인의 경우 다음 3가지를 고려했습니다.네이버카카오구글과정은 아래와 같습니다.소셜로 부터 인가 코드 받아오기인가 코드를 통해 소셜 토큰 받아오기소셜 토큰을 통해 소셜에 등록된 사

객체지향 패러다임은 객체마다 적절한 책임과 역할을 부여하여 객체간 협력을 통해 문제를 해결해나가는 프로그래밍 기법이다.이 협력 과정에서 객체는 클라이언트, 서버 둘 중 하나를 담당하게 된다. 아래 예시를 통해 알아보자.Movie.caculateMovieFee() 메서드

카카오톡 선물하기 클론 + 펀딩 프로젝트에서 결제 기능을 담당하게 되었다. 결제 수단은 카카오페이다.프론트엔드가 백엔드에게 결제 준비 요청을 보낸다.백엔드는 요청값 일부를 캐싱 후 카카오페이 서버에 결제 준비(https://developers.kakaopay.

최근 프로젝트를 진행하면서 Spring Security를 사용하고 로깅 모듈을 개발하면서 알게된 Filter와 Interceptor 개념을 정리하려 한다.서블릿 요청 시 Filter, Interceptor, AOP 순으로 전달이 되며 처리 후 반대 순서로 응답이 전달된

이번 프로젝트에서도 소셜 로그인을 담당하게 되었다. 약 2번 정도 소셜 로그인을 구현한 경험이 있으나, Spring Security의 OAuth2 라이브러리를 사용하였기에 이번에는 직접 OAuth2 모듈을 만들어보자 라는 생각으로 임하게 되었다.Spring Securi

댓글, 회원 가입 등 다양한 도메인에서 "사진 업로드"라는 공통 기능이 필요합니다. 저의 궁극적 목표인 도메인간 결합도 낮추기, 유지보수 및 확장성를 위해 어떤 고민을 했는지 남겨보려 합니다.모든 도메인에서 사진만 업로드하는 것이 아닌, 사진 외에 다른 정보들을 같이

현재 상황 댓글 생성 시 다양한 로직이 실행된다. 이미지 S3 저장 컴포넌트(게시글)의 댓글 수 증가 부모 댓글의 대댓글 수 증가 부모 댓글 작성자에게 알림 전송 이러한 작업을 비동기로 처리하는게 맞다 판단하여 Spring Event Listener를 도입했다. 문

메시지 큐: RabbitMQ 이메일 서비스: JavaMailSender 알림 데이터는 별도 스키마에 저장 대댓글, 좋아요, 공지사항시 사용자에게 알림이 전송됩니다. 해당 이벤트가 발생한 경우, 특정 사용자에게 알림을 전송하는 로직을 Spring Event Hand

지금까지 Redis를 사용하면서 정작 주의할 점에 대해선 잘 알지 못했다. 이를 정리해보려 한다.Redis는 싱글 스레드기 때문에 한 번에 하나씩 명령에 처리할 수 있다. 따라서 데이터 양이 많은 경우 O(n) 명령어를 호출하면, 꽤 오랜 시간 동안 Redis가 다음