![[NEMODU] 메인 화면 조회 API 개선하기](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FkBEDI%2FbtsjNKxQ8yv%2FuZxnOgYoR1yPaLtDz7uYXk%2Fimg.png)
목표 메인 화면 조회 API를 개선하는 과정을 소개합니다. 개요 처음 프로젝트를 시작하면서 동아리 활동 기간인 2달에 맞춰 개발을 진행했습니다. 기간을 맞추는 것을 우선순위로 진행하면서, 기술 부채가 쌓이고 있었습니다. 그 중 하나는 메인 화면을 조회하는 로직입니다. 메인 화면은 애플리케이션에 진입하면 가장 먼저 볼 수 있는 화면입니다. 본인을 포함한 친구, 챌린지 멤버들의 운동 기록과 더불어 기록한 영역 수 등 많은 정보를 한 번에 확인할 수 있는 핵심 기능입니다. 역할을 분배하면서, 해당 기능은 팀원이 담당했었습니다. 이제 백엔드 개발을 혼자 진행하고 있어, 코드 분석부터 문제 해결까지 진행했습니다. 요약 구체적인 내용을 기술하기 전에 간단하게 요약하면 다음과 같습니다. 성능 개선을 위해 두 가지 측..
![[Spring] 내가 ~Service, ServiceImpl로 분리하는 이유](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FLYbJ7%2Fbtr1JttDXG3%2FUIsoFyRcRd9bsrgBIFeGSK%2Fimg.png)
목표 서비스 계층을 개발할 때 ~Service, ~ServiceImpl로 나누는 이유에 대해서 기술합니다. 개요 저는 Spring 기반의 백엔드를 구현하는 프로젝트를 구현할 때 항상 ~Service, ~ServiceImpl과 같이 인터페이스와 구현체로 분리해서 개발했습니다. 처음에는 이렇게 배웠기 때문에 따라 했고, 경험이 쌓이면서 왜 이렇게 해야 하는지에 대한 고민을 하기 시작했습니다. 정말 다양한 측면에서 생각해 볼 수 있는 문제이고, 상황에 따라 의견이 분분한 문제이므로 정답은 없다고 생각합니다. 하지만, 제가 프로젝트에서 이렇게 적용할 때는 그만한 근거가 필요하고, 저는 분리해서 개발하는 게 합당하다고 판단했습니다. 막상 면접 자리에서 '왜 이렇게 구현했는가?'라는 질문을 받았을 때, DI? 확장..
![[MySQL] UUID의 개념과 성능 개선 결과](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdF248G%2Fbtr0riG1Sma%2FY15D4kJdkViBmoR6Vk0aR1%2Fimg.png)
목표MySQL에서 UUID를 최대한 효율적으로 사용해 보기 위한 노력 과정을 기술합니다. 개요관계형 DB에서 데이터(튜플)을 식별하기 위해 PK(Primary Key, 기본키)를 사용합니다.하지만, 클라이언트와 서버 사이에서 데이터를 확인하기 위해 PK를 주고받는 것은 보안적인 측면에서 위험합니다.만약 다음과 같은 URL이 있다면 어떨까요?http://www.domain.com/user/info?userid=1파라미터로 들어가는 userid의 값만 바꿔도, 다른 사람의 정보를 확인할 수 있는 것을 예측할 수 있습니다.이처럼 예측가능한 모델이 되어 SQL Injection의 위험성이 존재하기 때문에, PK값을 그대로 넘겨주는 것은 바람직하지 않습니다.따라서, 고유값을 갖는 특정 값으로 데이터를 식별할 필요..
![[Spring] 전역 예외 처리를 위한 @ControllerAdvice와 @RestControllerAdvice](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FwWP2P%2FbtrGzZGbdU1%2FPEunKhDXcn10rAW8dqPu1k%2Fimg.png)
목표 전역 예외처리를 위한 @ControllerAdvice와 @RestControllerAdvice에 대해서 알아보겠습니다. 개요 진행하던 프로젝트에서 리팩토링이 시급한 부분은 전체적인 구조였습니다. 복잡하고 가독성 떨어지는 코드이기 때문입니다. 이러한 구조로 만들어지는데 많은 원인이 있지만, 단연 try-catch 문이 일등 공신이라고 생각합니다. 가독성이 떨어지는 것부터, try문 안에 있는 것은 지역변수로 처리되는 점, 반환형에 맞게 return을 try-catch문 안팎으로 처리해야된다는 점 등 자연스럽게 프로젝트의 구조를 일그러뜨렸습니다. 물론, try-catch문이 나쁘다는 것은 아니지만, 발생하는 예외를 체계적으로 관리할 필요가 있었습니다. Spring은 다양한 예외 처리 방법이 있지만, 그..
![[Spring] API 문서 자동화를 위한 Swagger 3.0.0 적용](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdbDKA0%2FbtrFY76KQlg%2FDtlS0SpquDoLeeqRIQpl30%2Fimg.png)
목표 Swagger에 대해 알아보고, JWT Security가 적용된 Springfox 3.0을 적용해보겠습니다. 목차 개요 Swagger란? 정리 개요 팀 프로젝트를 진행하면서 가장 고된 사항은 바로 API 정보를 프론트와 공유하는 것이었습니다. 노션에 직접 URL, 파라미터, 결과 등을 적어줬습니다. 프로그램이 커지니까 실수도 잦아지고, 찾기도 힘들었습니다. 이에 대한 해결책인 Swagger에 대해 알아보고, 적용을 해보도록 하겠습니다. Swagger란? Swagger는 OAS(Open Api Specification)를 위한 오픈소스 프레임워크입니다. 즉, API의 문서를 자동으로 정리해주는 것 입니다. 해당 Swagger를 협업하는 개발자에게 전달하면 Path, Request, Response, ..
![[Spring] JPA, RDS, MySQL 연동 시 연결 안됨-CommunicationsException](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcQ1TCu%2FbtrypiOBKoa%2FOhHPlxMX38jaE3qgpkyGt1%2Fimg.png)
상황 현재, Spring으로 API 서버를 개발하는 프로젝트를 진행하고 있고, 카카오 API를 사용해 소셜 로그인을 구현하고 있습니다. 개발 환경은 IntelliJ IDE에서 Spring boot +JPA(Hibernate) + MySQL을 사용하고 있으며, 프론트와 연결하기 위해서 AWS의 EC2 인스턴스와 RDS를 띄워놓았습니다. 분명히, 어제 저녁까지만 해도 정상적으로 잘 동작하는 것을 확인하고 깃허브에 푸시까지 했습니다. 오늘 다시 서버를 동작시키니 접속이 안되는 상황이 발생했습니다. 아무것도 안했는데 에러가 발생한 것은 처음이라서 무척 당황했습니다. AWS의 EC2 인스턴스, RDS 인스턴스가 모두 사라진 경우 연결이 안되니, 인스턴스가 중지되어 있는지 확인하기 위해 AWS에 접속하였습니다. 접..