Mind Diary

이번 프로젝트를 진행하며 API 문서를 만들다 회원가입 POST 요청을 보냈을 때 이미 등록된 이메일이나 닉네임일 경우 응답 status code는 어떤 걸 해야할 지 고민이 되었다.이전의 프로젝트에서는 팀원들과 협의해서 200 OK로 다 응답을 보내고 응답 body에

유저의 로그인 API 기능을 작성할 때 발생한 문제입니다. JWT 인터페이스, 쿠키 인터페이스, 캐시 인터페이스, HttpServletResponse 클래스를 사용하게 되면서 대부분의 로직이 컨트롤러 계층에서 작성되게 되었습니다. 이러한 코드 때문에 오류가 난 부분을

API 처리 중 실패 상황에 대한 어떻게 처리할 것인가 고민이 있었습니다.예를 들어, DB 에러가 발생할 경우API request 시 필요한 body 데이터가 오지 않았을 경우JWT토큰이 만료한 경우회원 가입 시 중복 닉네임인 유저의 경우 등등 이런 여러 실패 상황이

일기 관련 API에서 사용자 토큰을 통해 접근 권한을 확인하거나, 사용자의 id 값을 가져오는 로직이 중복되는 문제가 발생했습니다. 리팩토링 전에는 아래와 같이 사용자의 권한을 확인하고, 정보를 가져오는 부가 기능이 대부분의 메소드에서 반복되었습니다. 1\. 토큰이 유

회원가입 API 시에 발생한 문제입니다.회원가입 시 사용자의 이메일로 이메일 토큰이 있는 url을 보내 이메일 인증을 진행합니다.이 때, 이메일 토큰 검증용도로 redis에 이메일 토큰을 미리 저장해둡니다. 위와 같은 회원가입 코드가 있으며 다음과 같은 로직이 일어납니

게시글 목록 조회 API 시 게시글 정보 뿐 아니라 게시글에 등록된 여러 태그들과 여러 미디어자료(사진 등)을 같이 가져와야 합니다. 이러한 일대다 관계의 모든 데이터를 한번에 가져오면서 중복된 데이터가 생기고, 쿼리 결과 row 수가 늘어납니다. 결국 응답 결과 데이

스트레스 검사나 우울 검사와 같은 자가 진단 검사 데이터를 모두 레디스에 추가할 때 발생한 문제입니다. 하나의 검사 데이터를 추가할 때마다 redis의 데이터 추가 명령어가 발생하면서 네트워크의 병목 현상이 발생할 수 있습니다.레디스는 이벤트 루프와 단일 스레드 방식을

자가진단 관련 데이터를 캐시를 이용해 조회할 때 cache miss 문제가 발생했습니다. DB에 있는 자가진단 관련 데이터를 한번에 캐시에 저장하고, 이후 조회할 때는 캐시를 통해서만 데이터를 조회하는 로직이었습니다. 새로운 자가진단 데이터가 DB에만 등록되있을 경우

자가진단 목록과 게시글 목록을 조회시 mysql의 order by limit을 사용한 페이징 처리를 했습니다. 그런데 현재 코드에서 사용되는 ORDER BY... LIMIT offset,count 절은 테이블 풀 스캔을 하기 때문에 offset과 count의 숫자가 커

HTTP의 무상태성과 비연결성이라는 특징이 있습니다. 이 특징 때문에 사용자의 인증 정보가 필요할 때마다 매번 로그인을 해야하는 상황이 발생합니다. 예를 들어 한 페이지에서 로그인을 하고 다른 페이지로 가면 재로그인을 해야합니다. 그래서 문제 해결을 위해 쿠키, 세션,