회고장

👣 개요 오늘은 프로젝트의 SSL 적용을 끝마무리하고 RestTemplate에 ErrorHandler를 등록해 오류 로깅을 위한 장치를 마련했다. 대부분의 SSL 적용을 위한 Certbot 관련 게시글들은 StandAlone 방식을 이용해서 인증서를 발급받았다. 이러한 게시물들은 간단히 아래 명령어를 입력하고 몇 가지 문답을 통해 쉽게 발급을 수행했다. certbot certonly --standalone 문제는 해당 방식은 게시글에 나열된 방식과 다르게 작동하지 않았다. 따라서 StandAlone 방식이 아닌 Manual 방식으로 Challege를 진행하고자 했다. 이것은 직접 Let's encrypto가 제시하는 토큰을 개발자가 직접 전달하는 방식으로 이뤄져 있었다. 직접 임시 Controller를 ..

👣 개요 오늘은 API 서버를 실제로 배포하기 위한 활동을 했었다. 대략적으로 EC2에 서버를 가동시키고 도메인을 취득하고 해당 도메인을 이용해서 https를 적용하는 작업을 했었다. 아래는 시간순으로 했던 일을 나열했다. 1. EC2에 3.36.132.42 IP로 웹 서버 띄웠습니다. 테스트를 위해 사용했던 서버기도 해서 APP 자체에는 문제가 없습니다. 2. '내도메인 한국' 사이트를 통해 무료 도메인을 취득했습니다. Domain : miniproject.kro.kr 3. Route 53을 통해 해당 도메인과 IP를 매핑해줬습니다. 그 결과 해당 도메인으로 EC2의 서버로 접속됨을 확인했습니다. 4. 이제 Https를 적용하기 위해 Certbot을 이용해서 SSL 인증서를 받고 있습니다. 문제는 Ch..

👣 개요 오늘은 그렇게 고생스러웠던 카카오 인증 과정을 끝내 구현하는 날이었다. 카카오 인증 과정 중 서버로서의 기능은 이미 구현되어 있었다. [사용자가 이미 Authorization Code를 받은 이후, 서버로 리다이렉션 되었을 때를 가정하고 그 이후의 과정인 Access Token 취득, User 정보 조회, DB 저장, JWT 발급을 구현한 상태.] 하지만 프론트쪽에서 Authorization Code를 받고 해당 token을 지닌 채로 리다이렉션 요청을 보낼 때, 리다이렉션 응답을 가로채는 방법에서 애먹고 있었다. 이미 Redirect Url로 자동으로 리다이렉트 되고 있기에 도저히 JWT 토큰을 받을 만한 방법이 보이지 않았다. 왜냐 하면, 이전까지 나의 OAuth2 인증 과정은 항상 Redi..

👣 개요 오늘은 검색 기능의 페이징 구현과 소셜 로그인을 구현 완료하는 날이었다. 검색 기능의 페이징은 QueryDSL을 이용해서 해결했다. 해당 기능을 위해 기존 쿼리에 limit과 offset을 설정했다. 그리고 TotalElements 갯수를 찾기 위해 Count Query를 따로 작성했다. 처음에는 기존 코드에 단순히 fetchCount()를 이용해서 count 쿼리를 보내려고 했으나 이것은 이미 deprecated된 기능이어서 직접 select 파라미터에 count를 이용해서 카운트 쿼리를 보내게 했다. 문제는 소셜 로그인이었다. 로컬 서버에서 소셜 로그인을 수행할 때는 분명 문제가 없었다. redirect_url도 정확히 설정했고 Cors 설정도 정확히 했고 실제로 소셜로그인에 의해 acces..

👣 개요 오늘은 서버의 추가 기능들을 구현하고 코드 통합을 하는 날이었다. 나의 경우, 회사 검색 기능, profile마다의 설정 분리, EC2 배포를 위한 Test API 서버 설정, 페이지네이션 기능 구현을 수행했다. 회사 검색 기능을 위해 QueryDSL을 적용했고 테스트 서버를 위한 설정을 분리하기 위해 local, test, prod 프로파일을 사용했다. 페이지네이션은 단순히 Page, Pageable를 이용해서 구현했다. 같이 백엔드를 수행하는 팀원 분께서는 '카카오 소셜 로그인' 기능을 구현해주셨다. 소셜 로그인을 수행하면 OAuth2 인증 과정을 거쳐 카카로 인증 서버로부터 Access Token을 받고 해당 토큰으로 유저 정보를 조회하고 해당 정보로 회원 가입을 시도한다. 이렇게 함으로서..

👣 개요 오늘은 필수 기능 구현의 마지막 날로 백엔드 API 서버와 프론트엔드 웹 서버를 서로 맞춰보는 날이었다. 하지만 이것은 생각보다 잘 이뤄지지 못했다. 예를 들어, 로컬 서버에서는 자유롭게 주고받던 쿠키값이 배포 서버에서는 넘어가지 못한다는지 댓글 관련 API 명세서에 유저 ID를 요구하는 바가 없어서 그대로 진행했다가 차후에 프론트엔트에서 ID를 사용해야 해서 급하게 추가해야 한다던가 등등의 문제가 발생했다. 다행이도 3-Layer 구조를 가진 spring은 이런 문제를 해결하기 매우 쉬웠다. 단순히 API에서 추가 데이터를 요구하는 것은 단순히 DTO에서 추가 칼럼을 제출하도록 하면 그만이고 Cookie로 전달하던 JWT도 Header의 Authorizaiton로 전달하도록 바꾸는 작업도 단순..

👣 개요 오늘은 백엔드 API 서버와 프론트엔드 웹 서버를 합쳐서 테스트해보는 날이었다. cors에 대해 이해하긴 했지만 테스트 방법이 따로 없어서 우선 CORS 설정을 하지 않은 채로 프론트엔드로 전달했다. 하지만 당연하게도 CORS 문제가 터졌고 이를 해결하기 위해 처음엔 Postman으로 직접 테스트를 하면서 디버깅했다. 같은 기기 내에서 postman을 사용하면 Origin이 같기 때문에 문제가 발생하지 않는다는 이야기를 듣고 API 서버를 배포한 후에 로컬에서 postman으로 테스트하기로 했었다. postman으로는 문제가 없었고 때문에 해결되었다고 생각한 API 서버를 다시 React 팀에게 전달했다. 하지만 또 문제가 발생했고 다시 문제를 해결해야 했었다. 아예 테스트 환경을 프론트엔드 팀..

👣 개요 오늘은 주특기 프로젝트의 모든 기초적인 API 기능 구현을 마치고 테스트까지 수행한 뒤, React 개발팀을 위한 간단한 배포까지 수행했다. 그동안 하지 못한 코드 병합을 끝마치고 코드 병합 중 문제가 발생한 부분에 대해 디버깅을 수행했다. 이미 테스트 코드를 작성하면서 오류 가능성을 모두 제거한 보람이 해당 과정에서 빛을 바랬던 것 같다. 코드 병합 후 postman으로 수행한 테스트들이 모두 아구가 맞아 떨어지면서 빠른 코드 병합을 수행했다. 다만 다소 아쉬웠던 부분은 profile 별로 설정과 코드를 분리하지 못한 것이 아쉬웠다. React 팀에서는 mock 서버를 이용해서 개발을 수행했기에 실제 API 서버를 이용해서 테스트할 필요성이 생겼다. 때문에 나는 이것을 배포하기로 결정했다. 이..

👣 개요 이번주는 Lv 5 과제 수행을 하고 금요일부터 주특기 프로젝트를 진행했다. Lv 5 과제는 단순히 좋아요 기능을 구현하는 것이었고 추가적으로 카테고리 기능, 전역 예외 처리 기능 등등을 구현하는 것이었다. 좋아요 기능은 쿼리 최적화를 위해 queryDSL을 이용할 수도 있었지만 그냥 기존의 소스 코드를 최대한 건드리지 않기 위해 엔티티 리스너를 이용했다. 카테고리 기능은 단순한 CRUD 였고 전역 예외 처리도 AOP를 사용했다기 보다 미리 구현된 ControllerAdvice를 이용해서 처리했다. 그리고 금요일부터는 주특기 프로젝트를 시작했는데 주특기 프로젝트는 React 개발자 2명, Sprign 개발자 2명으로 이뤄져 하나의 웹 사이트를 개발하는 과정이다. 아직 2일 밖에 진행하지 않아 진행..

👣 개요 오늘은 주특기 프로젝트 2일차로서 나에게 주어진 프로젝트의 기초 기능 구현을 모두 마쳤다. 내게 주어진 것은 다음과 같았다. Company Entity 관련 API 구현 Comment Entity 관련 API 구현 전역 예외 처리 Spring Security 도입 인가 필터 구현 @CreatedBy 기능 활성 이번 과제는 이전의 주특기 훈련 주차의 코드와 다르게 테스트 코드 관련으로 신경을 썼다. 왜냐 하면, 현재 Member 로그인 기능을 다른 팀원 분이 맡아주셨기에 통합 테스트를 진행하기 어려운 상황이었다. 그래서 단위 테스트를 진행하였고 덕분에 단단한 코드를 작성할 수 있게 되었다. https://github.com/Specialty-Project-Team-2/miniproject-back..