스프링에서 백엔드 Repository를 구현하다보면 사용하는 어노테이션이 있다.바로 @Transactional! AOP를 활용해서 커밋, 롤백 등 트랜잭션을 관리하는 기능이다.만약 해당 repository에서 읽기작업만 수행할 경우, readOnly=true 속성을 사용하기도 한다.@Transactional(readOnly = true) 위 설정을 통해 성능상의 이점을 가져올 수 있다고 하는데, 좀더 구체적으로 어떤 이점이 있는지 공부해보려고 한다. Transcational과 Dirty ChekingTransactional은 begin()부터 commit()작업 전까지 영속성 컨텍스트를 유지한다.또한, 영속성 컨텍스트로 불러온 Entity의 변경사항을 DB에 바로 적용하지 않고, Dirty Chekin..

두번째 리팩토링의 주제는 @Reposiotry 생략했는데 왜 정상작동? 이다. 과거 MyBatis를 활용해서 프로젝트를 진행했던적이 있다. Controller, Service, Repository 등 클래스들은 어노테이션을 통해 꼭 빈으로 등록했었다(당시에 몇번 빼먹었다가 오류가 나서 수정했던 기억이ㅎ) 그런데 프로젝트의 경우, @Repository 어노테이션을 생략해도 정상적으로 동작하는것을 발견했다. 초반에 작성했던 클래스를 제외하고는 대부분 명시하지 않았다. 구현에 급급하다보니 살피지 못했던 부분이다. 다른점이라면 기술스택으로 인한 차이가 있다. JPA를 채택하고있기 때문에 Repository는 모두 JpaRepository를 extends하는 인터페이스 기반의 레포지토리이다. 그렇다면 지금 발..

기존 CookieUtil의 문제점 찾기코드리뷰 과정에서 대답에 가장 난항을 겪었던 클래스의 리팩토링 과정을 설명하려고 한다. 우선, 기존 코드는 다음과 같았다.@Slf4j@Componentpublic class CookieUtil { private static String domain; private CookieUtil() {}; @Value("${bbaegok.root-domain}") public void setDomain(String domain) { CookieUtil.domain = domain; } public static Optional getCookie(HttpServletRequest request, String name) { Co..

그동안 열심히 개발해온 독서기록 앱, 이 드디어 Andorid/Ios 프로덕션으로 출시되었다🎉🎉그간 겪었던 수많은 난항...과 회고는 뒤로하고,앞으로의 운영, 그리고 개선방향에 대해 고민해볼때 인것같다. 마침 배포와 동시에 좋은 기회로ㅎㅎ 면접을 보게 됐는데, 무려 세시간동안 코드리뷰나 다름없는 면접을 볼 수 있었다.덕분에 앞으로 리팩토링의 방향성, 그리고 부족했던 부분들을 개선해나갈 인사이트를 얻었다..!오늘은 이러한 부분을 정리해보려고 한다. 우선 백엔드를 배포하고, 혼자 운영환경에 대해 고민했을때 필요했던 부분은 다음과 같았다. 전체적으로 코드 자체는 성능과 관련된 정말 운영이슈를 개선하려고 했었다.현재 API자체는 잘 동작하기 때문에, 성능관련한 고민만 하면 되겠지? 라고 생각했던것 같다...

백준 1707. 이분 그래프 처음 문제를 봤을땐 좀 이해하기 힘들었는데, 예제를 통해 그림을 그려보면 감이 좀 잡힌다. 예제분석CASE 1.1,2,3번 정점이 있고, (1,2)와 (2,3) 간선이 이어져있는 형태이다.분석해보면, [1,2]와 [3]으로 집합을 분리했을때 각 집합에 속한 정점끼리는 서로 인접하지 않는다는 것을 알 수 있다.즉, 이분그래프인것이다.  CASE 2. 1,3번 정점이 서로 연결되어있지는 않지만, 그둘을 하나의 집합으로 묶었다고 해서 이분그래프가 되진 못한다. 나머지 집합이 서로 인접하기 때문이다(간선을 갖기 때문)  이분그래프그렇다면 위 내용을 바탕으로, 이분그래프를 정의해보자면 다음과 같다. 이런식으로 정점을 두 진영으로 나누었을때, 서로 다른 진영끼리는 연결될 수 있으나 같은..

노트 수정창에서 사용할 PATCH API, 즉 수정 API를 구현하던중 찝찝~한 부분을 발견하게 되었다. PATCH 는 기본적으로 '수정할 부분만' 전송하도록 동작한다.따라서 컨트롤러는 '값이 바인딩 된' 부분에 대해서만 수정작업을 진행하면 된다. 그런데 만약 사용자가 해당 필드를 '빈 값'으로 초기화 하려고 한다면?즉, 위 화면에서 '내용'에 해당하는 부분을 Null로 초기화하고 싶다면? 프론트엔드에서 발생하는 요청은 다르지만, 백엔드 컨트롤러에서 받을 요청은 똑같아진다(구분할 수 없다.) 문제상황자세히 설명하자면 다음과같다.우선 프론트엔드에선 다음과 같이 요청이 발생한다.  그러나 백엔드에선 두 요청이 똑같이 보인다.요청객체에 바인딩 되면서 할당되지 않은 값들은 Null로 초기화 되기 때문이다.따라서..

배포환경에서 프론트-백엔드간 API를 테스트하던 중 계속해서 제기됐던 문제가 하나있다.바로 여러기기를 사용해서 로그인 하는 경우, 기존에 사용하던 기기는 액세스토큰 만료와 동시에 리프레쉬 토큰이 INVALID해진다는것! 이렇게만 말하면 대체 무슨소리인가 싶을수도 있는데, 좀더 자세히 설명해보도록 하겠다. 문제상황 분석우선, 각 토큰이 포함하고 있는 데이터는 다음과같이 설정되어있었다."Access-Token" : userId + providerCode + 동의한약관버전 + 비밀key + 만료시간(1분)"Refresh-Token" : 비밀key + 만료시간(7일) 위 상태에서, 로그인로직의 경우 다음과같이 동작한다.로그인에 성공하면 두 토큰을 모두 재발급해준다. 또한 동시에 Refresh토큰값을 DB에 저장..

배포환경에서 로그인 시스템에 문제가 생겼다. access-token 만료시 refresh-token 재발급 로직이 비정상적으로 동작하고 있었던 것. 즉 액세스토큰 재발급 API가 매번 런타임 에러를 뱉고 있는것이였다. 간단해보였던 이 문제는 우리팀을 꽤나 고생시켰는데... 크게 두가지 문제가 있어서 그랬던거였다.1. 액세스토큰 재발급 로직에서 액세스토큰을 검증하는 불필요한 로직이 있었음2. 리프레쉬토큰이 정상적으로 발급되지 않고 있었음 여기서 두번째 문제가 오늘의 주제, '다른 도메인간 쿠키 문제 해결하기!' 이다.또한 이 문제를 해결하면서 마주친 다양한 에러들에 대해 좀 더 기술해보도록 하겠다. 더보기(CF) 1번 문제 해결첫번째 문제는 오늘의 주제와는 동떨어진 휴먼에러이기 때문에 넘어갈까 했지만, 혹..

올해 6월, 같이 공부하던 친구의 권유로 공모전에 하나 참가하게 되었다.바로바로 !!공공데이터를 활용해서 비즈니스 모델 및 참신한 아이디어를 발굴하고자 하는 대회이다.  지원계기당시 싸피를 수료할 시기여서 시간적 여유가 있었는데, 마지막 프로젝트를 함께했던 팀원이 이 공모전을 함께 나가자고 권유했다. 사실 처음엔 나갈 생각이 거의 없었다.. 그동안 모든 프로젝트들을 (백엔드인 내가) 디자인했었는데 이게 너무x100 힘들었었다. 근데 이 팀에 들어가면 밤새 혼자 피그마를 만질 내 모습이 보였다....😢 그치만 내가 합류하면 따라오겠다는 믿음직한 친구들도 있었고, 디자인만 끝내면 이번엔 백엔드에만 집중할 수 있으리라는 생각이 들었다(프론트엔드, AI 모두 능력있는 팀원들이였다). 무엇보다도 싸피 내 경쟁이..

SSAFY를 수료한지도 벌써 6개월이 되어간다.1년이나 되는 교육과정에, 열정적인 사람들이 모인 부트캠프다보니 굉장히 많은 사람들을 만났고, 많은 경험을 했고, 또 많이 성장할 수 있었다.(한가지 스포일러를 해보자면, 싸피에서 진행되는 4개 프로젝트중 3개 프로젝트에서 1위를 수상했다😀!)그래서 오늘은 이러한 경험과 성장에 대해 포스팅해보려고 한다. 개발실력과 기술적인 얘기보다는, 이 프로그램이 나에게 가져다 준 경험, 그리고 그 감상에 초점을 맞춘 글이 될 것같다. 우선, 이러한 훈련과정을 알게된 경로인 '선도기업 아카데미'에 대해 먼저 알아보도록 하자. 선도기업 아카데미 훈련과정나는 삼성에서 진행하는 SSAFY를 들었지만, 사실 요즘은 기업에서 진행하는 훈련과정이 아주x100 많다. 그리고 이렇게 ..