속닥속닥 기술블로그 속닥속닥 기술블로그

dev 와 feature 브랜치로 여러 개념을 이해해보자! (merge의 기본 단위는 branch) dev : base branch feature : dev 브랜치에서 나눠진 하위 브랜치 오늘 생각해볼 것 ✏️ merge fast-forward merge non fast-forward merge github에서의 여러 가지의 merge merge rebase and merge squash and merge ☁️ fast-forward merge feature브랜치를 dev브랜치로 병합할 때 dev브랜치에 새로운 작업 내역이 없다면 merge commit 없이 HEAD만 변경할 수 있다. 이를 fast-forward(빨리 감기) merge라고 부른다. 현재 브랜치(feature)의 HEAD를 대상 브랜치(..

실제로 사용자의 40%가 3초 동안 기다리게 되면 사이트를 이탈하는 것으로 나타났다. 월마트에서는 페이지 속도를 100ms까지 개선하면 수익이 1% 증가한다는 사실을 발견했다. 물론 웹사이트의 로딩 속도가 프론트보다는 백엔드에 많이 의존적인 것은 사실이지만 최근에는 꼭 그런 것 만은 아니다. 웹 애플리케이션이 시간이 지남에 따라 복잡해 지면서 늘어가는 비동기 통신, 복잡해진 UI등으로 이전과는 다른 무거운 애플리케이션들이 형성되면서 사용자에게 직접적으로 직면하는 프론트엔드에게도 성능이 중요해지고 있다. 하지만 이 속도라는 것은 사람마다 체감하는 것이 다르고 이를 판단해서 최적화하기란 쉬운일은 아니다. 그렇다면 프론트엔드에서 성능을 측정하는 가장 보편적인 지표와 이를 해석하는 방법은 무엇이 있을까? Goo..

저번 포스트에서 LocalDateTime.now()를 모킹하기 위해 clock 객체를 Bean으로 등록 후 now() 속 파라미터로 주입했다. 1. static 메소드를 mocking하는건 안티패턴이다 PowerMock 방식과 mockStatic 방식 모두 그렇다. Mockito 깃허브의 Enable mocking static methods in Mockito#1013 이슈에서 관련 논의가 활발하게 진행되었다. https://github.com/mockito/mockito/issues/1013 Enable mocking static methods in Mockito · Issue #1013 · mockito/mockito Static methods mocking with Mockito This is a ..

@Repository public interface PostRepository extends JpaRepository { Slice findSliceBy(Pageable pageable); Page findPostsByMemberOrderByCreatedAtDesc(Pageable pageable, Member member); } 사용된 코드 0. intro 우리 코드는 원래 Slice를 이용해 페이징 했다. 그런데 이번에 "내가 쓴 글 조회" API는 총 페이지 수도 필요로 했다. 찾아보니 Page를 통해 기존 Slice 기능과 더불어, 총 페이지 수 도 알 수 있었다. 다만 Page 는 생성 비용이 Slice 보다 많이 드므로 총 페이지 수 를 알 필요 없다면 Slice를 쓰면 될 것 같다. 1. P..

익명 커뮤니티를 만드는 서비스 특성상 비밀번호는 물론이고 아이디까지 암호화해서 저장해야 한다. 이 암호화를 어디서 어떻게 해줘야할지에 대해 팀에서 토론이 있었다. 토론이 재밌었고 생각하지 못했던 부분들이 있어서 기록으로 남긴다. 문제 상황 현재는 이런 방식으로 회원가입 요청이 오면 Dto에서 꺼낼 때 바로 암호화해서 저장을 한다. 하지만 이렇게 되면 Username과 Password의 도메인 로직을 적용하지 못한다. 예를 들어 글자수 제한 혹은 비밀번호에 꼭 들어가야하는 정규식 규칙 같은 것들말이다. 대안 1 - DTO에 로직 넣기 처음 생각해 본 방식은 DTO에 로직을 넣는 것이었다. 그렇게 하면 애초에 컨트롤러단에서 valid를 해서 처리를 해줄 수 있다. 하지만 그렇게 되면 도메인 로직이 여기저기 ..

프로젝트를 진행하던 중 예상치 못한 난관을 만났다. 기존의 세션방식의 로그인을 위해서는 쿠키를 활용해야 하는데 서버로부터 헤더Set-cookie에 담겨서 오지만 코드에서 이를 잡지 못했다. 왜 쿠키를 잡지 못하고 안찍히는 것일까? 다른 헤더들은 가볍게 잡는데 왜 쿠키 이녀석만 내 손에 들어오지 않는 것일까 문제가 뭔지 한번 살펴보도록 하자. 쿠키란? HTTP 쿠키 (HTTP cookie)란 하이퍼 텍스트의 기록서(HTTP)의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일을 일컫는다. https://ko.wikipedia.org/wiki/HTTP_쿠키 쿠키란 결국 어떤 사이트를 방문하였을 때 웹 브라..

우테코 내에서 팀 프로젝트로 속닥속닥 이라는 익명 커뮤니티를 개발하고 있다. 현재 인증/인가를 JWT를 이용해 구현했는데, 토큰 만료 시간이 지났을 경우 로그인이 풀리는 문제가 있다. 토큰 만료로 갑작스레 로그인이 풀린다면 사용자는 불편을 겪을 것이다. 예를 들어, 속닥속닥 사용자가 게시판에 글을 열심히 쓰고, 작성 버튼을 눌러 글 작성을 완료하려 한다. 하지만, 작성하는 도중에 토큰이 만료되었고 글 작성 버튼을 누르는 순간 로그인 화면으로 돌아가 하던 작업을 잃게 된다. 이런 상황을 방지하기 위해 토큰이 만료된다면 자동으로 다시 발급해주어 로그인이 풀리지 않게 구현하려 한다. 이를 위해, Refresh Token을 이용하면 된다. 자동로그인 동작 시나리오 1. 로그인하면 access token과 ref..

0. Intro @Entity @EntityListeners(AuditingEntityListener.class) public class AuthCode { private static final long VALID_MINUTE = 5L; @CreatedDate private LocalDateTime createdAt; //... public void verifyTime() { LocalDateTime expireTime = this.createdAt.plusMinutes(VALID_MINUTE); if (LocalDateTime.now().isAfter(expireTime)) { throw new InvalidAuthCodeException(); } } } 인증코드가 생성시점에서 5분이 지나면 만료되는 ..