
Springboot로 프로젝트를 수행하면서, 테스트코드에 대한 필요성을 느끼지 못했고, 그로 인해 공부해야겠다는 생각으로 이어지지 못했다. 이번에 JPA를 제대로 공부하면서 그간의 부족했던 점을 인지하고, 개선하기 위해 단위 테스트를 도입하고자 공부하게되었다.자바를 위

한 개의 주문에 N개의 주문 상품이 존재사람의 입장에서 접근하면, 주문이 있어야 주문 상품이 있다고 생각할 수 있다.\-> 연관관계의 주인은 단순히 외래키 관리의 문제이지, 비즈니스상의 우위 관계로 접근하려고 하면 안된다!연관관계의 주인을 주문으로 정하면, 주문이 관

ORM : 객체와 데이터베이스 테이블의 매핑을 통해 엔티티 클래스 객체 안에 포함된 정보를 테이블에 저장하는 기술JPA에서는 테이블과 매핑되는 객체 정보를 영속성 컨텍스틀 통해 어플리케이션 내에서 오래 지속되도록 보관영속성 컨텍스트는 논리적인 개념눈에 보이지 않음엔티티

영속성 컨텍스트가 관리하지 않는 엔티티준영속 엔티티는 detach 메서드를 통해서 혹은, 아래처럼 식별자를 강제로 주입한 객체가 될 수 있다.참고 : https://sjiwon-dev.tistory.com/14준영속 엔티티는 영속성 컨텍스트가 관리하지 않기 때

감사하게도..JdbcTemplate 클래스로 구현이 돼있어 가져다쓰면 됐다. 😭loop돌때 마다의 각각 INSERTbatch에 쌓아두고 한번에 쿼리를 날리는 bulkUpdate (10000개의 데이터의 성능 차이가 이정도....참고로 내부 로직에선 update쿼리도

서론 사내 시스템을 개발 중, 외부 API 호출 ➡️ DB save 요청을 날리는 로직에 대해 궁금증이 생겼다. ❓ 첫번째 고민은, 외부 api에 의존성이 높은 save 요청인데, 트랜잭션 분리를 하는게 맞을까하는 고민이었다. 두번째는 외부 api는 우리 서버단에서

서론 기존의 사내 레거시 코드에서 HttpUrlConnection 객체를 생성하고 setter를 통해 값을 담아 httpmethod를 파라미터로 외부 api request를 날린다. 😢 함께 개발한 팀원이 서비스 계층에서 외부 api를 2번 호출하기 때문에 성능이
새롭게 토이프로젝트를 시작하면서, 소셜 로그인 기능을 Oauth2로 네이버와 구글과 연계해 구현해보았다. 그동안 편하게 서비스를 이용해오면서, 어떻게 동작하는지에 대한 기술적인 호기심을 해결할 수 있었고 이를 기록하고자 한다.해당 게시글은 다음 강의를 참고하여 작성했습
이전 포스트에 이어서 필터, 핸들러, 엔티티를 구현해보겠습니다.해당 게시글은 다음 강의를 참고하여 작성했습니다.https://www.youtube.com/watch?v=xsmKOo-sJ3c&list=PLJkjrxxiBSFALedMwcqDw_BPaJ3qqbWeB

일일 미션을 관리하는 사이드 프로젝트를 수행하면서, 현재 수행중이지 않은 미션을 비활성화하는 로직을 개발했다. 비활성화는 03시에 스케줄러를 통해 처리하기 위해 batch를 공부하다가, Spring batch와 quertz 라이브러리를 통한 스케줄러를 알게되어 적용하게

서론 사이드 프로젝트를 수행하면서, FE 개발자분이 BE에 API 요청을 날릴 때, 에러가 발생하는 경우 각 도메인과 상황에 맞는 예외 처리를 적용하기 위해 공통 예외 처리를 어떻게 하는지 찾아보고 적용하게 되었다. > Spring의 예외 처리 방법 > Sprin

Spring Security + OAuth 2.0 + JWT로 인증·인가를 구현한 프로젝트에서 컨트롤러 단위 테스트 코드를 작성하면서 컨트롤러에 도착하기 전 Filter가 가로채서... Mock 객체를 SecurityContextHolder에 담는 방법을 탐색하다가 해

테스트코드를 작성하면서, form-data타입으로 DTO 객체와 Multipartfile 객체를 받는 컨트롤러 계층에서 마주한 이슈와 해결과정을 기록하고자 한다. 사용자의 프로필을 수정하는 컨트롤러에서, 수정할 닉네임은 DTO 객체로, 프로필 사진은 Multipart

서론
최근 테스트 코드를 작성하면서, 이전에 적용했던 인메모리 DB를 기반으로 테스트 하는 방식에 의문점을 가지게 되었다.Repository 계층의 역할은 DB와 의존성을 맺어서 데이터를 주거니 받거니한다. 그러나, Mock이나 InmemoryDB를 통해 테스트를 독립적으로

서론 사이드 프로젝트를 수행하면서, 미션과 인증글이 생성될 때 이미지 파일을 저장하는데, 서버 리소스 절약, 서버 부하 감소를 이유로 presignedUrl을 적용하게 되었다. 본론 > 기존 이미지 파일 저장 흐름 > 기존에는 클라이언트로부터 API 요청이 들어

사이드 프로젝트에서 푸시 알림 기능을 도입하게 되었다.기술 스택 채택과 적용 과정에 대해서 기록하고자 한다.알림 기능 요구사항참여중인 미션에 다른 유저가 참여한 경우참여중인 미션에 다른 유저가 인증글을 작성한 경우필수 인증 제츨 요일에 미제출 상태인 경우3가지 기능 모

사이드 프로젝트에서 SSE를 활용해 실시간 푸시 알림 기능을 구현했었다.알림 전송에서의 안정성과 신뢰성을 높히기 위해 여러 방면을 고민하다가, Kafka를 도입하게 되었다. Kafka & SSE를 통해 구현한 실시간 이벤트 스트리밍 도입 과정을 기록하고자 한다.Kafk

사이드 프로젝트에서 03시마다 미션을 종료하고, 인증글 미제출 유저를 강제퇴장처리하는 배치를 수행하고 있다. 배치가 돌면서 오류가 발생했을 때, 이를 어떻게 대처할지를 고민하고 적용한 결과를 기록하고자 한다.서론에서 언급한 배치 수행 내용은 boolean 타입의 필드를

현재 일일 미션 인증 서비스는 로그인 이후 넘어가는 메인페이지로, 미션 리스트를 보여주고 있다. 즉, 사용자들이 접속할 때마다 미션 리스트에 대한 조회 쿼리를 api 서버가 수행하기 때문에, DB I/O 부하를 낮추고, 효율적으로 리소스를 사용하기 위해서 Redis로

서론 사이드 프로젝트에서 좋아요 기능을 구현하면서, 동시성 이슈를 마주했다. 어떤 상황에서 발생했고 어떻게 해결했는지 과정을 기록하고자 한다. 본론 > 문제상황 > 4개의 쓰레드로 동시성 테스트를 수행했다. 당연히 4번의 좋아요 API 요청이 발생했기 때문에 좋

오픈카톡방을 많이 사용하고 있는데, 이를 가능하게 해주는 WebSocket을 공부하게 되었다. 추후 실시간 공매도 거래나 관련한 실시간 통신에 대해 업무를 맡을 수도 있으니.. 웹 환경에서 우리는 HTTP 프로토콜을 통해 요청과 응답의 구조로 서비스를 이용하고 있다.