F-Lab 프로젝트 1

쿠키 / 세션 인증 방식을 통해 로그인 기능을 구현하는 경우 세션이 처리할 요청은 읽기보단 쓰기에 대한 요청이 많을 것으로 예상할 수 있습니다. 하지만 트래픽이 증가해 로그인 요청에 대해서도 많은 사용자로부터 생성된다면 상대적으로 하나의 요청 처리 시간이 많이 소비되는

UserServiceImpl 클래스의 signUp()의 내부 구현 코드를 보면 Entity 객체인 UserDto 객체를 생성하는 builder 메소드는 signUp() 메소드 내에서만 동작하고 외부로 생성된 UserDto를 리턴하지 않도록 구현되어 있습니다.그러다보니

필요한 기능들을 구현하면서 발생할 수 있는 예외 상황에 대한 처리 로직을 추가하게 되는 경우가 생겨났습니다. 이때 예외 처리 로직을 어떤 레이어에 책임을 주어야 할지에 대한 고민을 하게 되었습니다.예를 들면 회원가입 로직을 진행하기 위해 Request로 넘어온 emai

회원가입을 진행하기 위해선 꽤 많은 값을 Controller에서 request로 받아와 Service로 넘겨줘야 하는 소요가 발생했습니다. 여기서 문제는 많은 숫자의 변수를 각각의 매개변수로 넘겨주는 것이 합리적인 선택인지 의문이 생겼습니다.회원가입을 위한 데이터를 담

로그인한 회원이 구매나 판매 서비스에 대한 요청을 보낼 경우, 특정 메소드들은 UserId 정보를 필요로 하는 경우가 존재합니다.예를 들면 즉시 구매 요청을 보낸 경우, 판매 입찰가와 거래 체결을 진행하기 위해선 구매자의 정보도 필요하기 때문에 userId를 필요로 하

문제점 DB 연결을 위해 Mybatis를 활용하기로 결정했고 이를 위한 구현을 진행하던 중 Mapper 인터페이스를 주입할 대상에 대한 고민을 하게 되었습니다. MyBatis의 경우, Service 레이어에 Mapper 인터페이스를 주입시켜 쿼리문을 날려 DB를 사용

문제점 DB에 접근하는 로직은 크기 쓰기에 대한 요청과 읽기에 대한 요청이 많습니다. 그렇기 때문에 @Transactional 어노테이션을 선언하는 경우에도 읽기만을 위한 메소드엔 @Transactional(readOnly = true)로 선언해 의도치 않은 데이터

문제점 판매 입찰 최고가에 대한 즉시 구매 기능을 구현하던 중, 클래스 별 책임 분리가 애매한 상황에 마주하게 되었습니다. 수정 전 코드는 다음과 같습니다. OrderServiceImpl 위 코드에서 즉시 구매 기능은 1)새로운 Order 개체에 대한 생성 및 저

만약 프로젝트가 실제 배포가 되고 사용자 이용 수가 많아진다면 읽기보다 쓰기 처리리가 상대적으로 많을 수 밖에 없는 기능에 과부하가 올 것이고 이는 서버 다운의 주된 원인이 될 수 있습니다.그래서 Session에 담길 사용자 정보를 저장할 메모리 공간에 대한 확장을 고

회원가입 및 로그인, 로그아웃 기능을 구현한 다음, 요청을 보낸 클라이언트가 현재 로그인한 상태인지 아닌지에 대한 검증을 거치고 로그인된 클라이언트의 요청일 경우 이를 처리해줄 수 있도록 해줘야 할 필요가 생겼습니다.이를 구현하기 위해 가장 먼저 적용해본 개념은 AOP

요구사항 로그인 인증 방식으로 선택한 세션 방식과 Jwt 토큰 방식을 함께 구현하더라도 객체지향 스러운 설계로 구성한다면 두 방식을 다른 코드의 영향을 주지않고 유연하게 변경할 수 있는 설계가 가능할 것이라 생각했습니다. 자바에선 이와 같은 유연한 설계를 구현할 다형

회원가입 API를 구현한 뒤 가입된 사용자에 대해서 로그인 요청을 받고 가입이 된 사용자에 한해 사용자에 대한 정보를 저장하고 관리할 방법이 필요하다고 판단했습니다.이를 구현할 수 있는 방법은 크게 세션/쿠키 방식 과 JWT 방식을 생각해봤고 각 방식에 대한 기본 설명

만약 프로젝트를 제작하면서 개인 로컬 환경에서 모든 플랫폼을 직접 설치해 코드 작성 및 테스트를 진행하고 문제가 없어 외부 서버에 배포를 한다고 가정했을 때, 배포 환경과 개발 환경의 차이로 인해 발생할 수 있는 문제점은 개발 환경에서 제어할 수 없고 예측하기 힘들 것

여러 개발자가 협업을 통해 하나의 서버를 구현하기 위해선 코드 버전관리에 대한 규약을 정할 필요해 이를 정해볼 필요가 있었습니다.git flow는 feature, develop, release, hotfix, master 5가지의 브랜치로 나눠 각 브랜치에 목적에 맞게

Github Flow를 브랜치 전략으로 선택했기 때문에 CI에 대한 자동화 전략이 필요했고 현재 상황에서 가장 효율적인 자동화 전략이 무엇인지 고민하게 되었습니다.Github Actions은 Github 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화 할 수

처음 DB와의 연결을 위해 설계한 테이블 구성은 어플리케이션 확장이나 리팩토링 과정에서 변경될 가능성이 높았고 실제로 많은 변경 소요를 발생시켰습니다. 이 과정에서 프로젝트 진행 과정에 따른 스키마에 대한 버저닝을 위한 관리 툴이 필요하다고 생각했습니다.Flyway는