우아한테크코스/모락 프로젝트6 JPA entity에 validation annotation을 붙인 이유 예시로 사용된 코드는 깃허브를 통해 확인할 수 있습니다. validation annotation을 붙인 이유와 생성자 검증의 맹점에 대해 작성한 글입니다. DB에 있는 데이터들을 100% 신뢰할 수 있다!라고 생각한다면 이 글은 읽지 않으셔도 좋습니다. 모락 프로젝트를 진행하면서, Entity 필드의 검증 로직이 존재해야 하는 곳에 대한 토론을 많이 진행했습니다. 우리는 토론의 결과로 검증을 위해 Entity 필드에 validation annotation을 붙이는 것을 택했습니다. 모락에서 사용되는 Entity에 대한 예시로는 다음과 같습니다. Entity 필드에 대해 올바른 값인지 확인하는 방법은 2가지가 있습니다. 1. 위와 같이 각 필드에 validation annotation을 붙이기 2. Ent.. 2022. 8. 28. 모락의 Git branch 전략 Git branch 전략을 도입한 이유? 프로젝트 이전까지는 혼자서 개발을 진행했기 때문에 하나의 branch에서 편하게 작업할 수 있었다. 모락 프로젝트에서 6명의 개발자가 함께 코드를 공유한다. 6명이 하나의 branch에서 작업을 진행한다면 매우 많은 conflict들이 발생했을 것이다. 따라서 우리는 6명이 동시에 여러 작업을 수월하게 수행하기 위해 Git branch 전략을 도입했다. Git branch 전략 버전 1 다음 그림은 제일 처음으로 생각했던 branch 전략이다. 가장 간단하고 도입하기 쉬운 전략이다. 이 전략은 main branch와 feature branch 2개로 이루어진다. main : 실제 서버에 배포되는 production 코드가 존재하는 branch feature : 기.. 2022. 8. 27. 존재하지 않는 API 요청 커스터 마이징하기 존재하지 않는 API 요청을 커스터 마이징을 한 이유 기존에 백엔드 서버로 존재하지 않는 API가 요청되면 다음과 같은 응답을 건내주었다. 존재하지 않는 API가 요청 시 404 NOT FOUND를 응답한다. 모락 프로젝트에서는 이런 상황 뿐만 아니라 리소스가 존재하지 않는 경우에도 NOT FOUND와 error code를 던져준다. 따라서 존재하지 않는 API가 요청 상황에도 error code를 통해 에러 구분을 하고 싶었다. (참고 글) 커스터 마이징 과정 우선 커스터 마이징 이전에 존재하지 않는 API가 요청 시 어떻게 진행되는 지 DispatcherServlet을 확인해보자. 존재하지 않는 API로 요청을 보내보았다. http://localhost:8080/invalid-api 위의 요청을 보내.. 2022. 8. 16. Custom Error Code가 왜 필요했을까? 커스텀 에러 코드를 도입한 이유 이때까지 백엔드에서 예외가 발생하면 프론트엔드로 다음과 같은 응답 메시지를 보내고 있었다. // response { "message": "요청 형식이 잘못되었습니다." } 각 Http Status Code 마다 응답되는 message는 한 가지뿐이었다. 따라서 어떠한 예외가 발생하던 위의 4가지 중 하나의 메시지만 받을 수 있었다. 악의적인 사용자가 악의적인 요청을 보내 예외가 발생하는 경우 어떠한 잘못으로 인해 예외가 발생했는지 알 수 없게 하기 위해서 위처럼 메시지를 추상화하여 응답하였다. 그러나 이런 추상적인 메시지 덕분에 프론트 개발자가 개발하는데에 어려움을 겪게 되었다. 프론트 개발자가 개발 진행 중, 요청을 보냈을 때 예외가 발생하면 응답 메시지를 통해 어떤 예.. 2022. 8. 10. 모락 프로젝트의 서버 구조 (리버스 프록시) 모락 프로젝트 세 번째 스프린트에서 서버 구조를 설계하였습니다. 서버 구조를 설계하기 이전에 우리의 통신 방식은 다음과 같았습니다. 1. 정적 파일을 요청할 때는 정적 파일이 담긴 서버에 요청을 보냅니다. 2. 서버의 API 요청을 할 때는 서버로 요청을 보냅니다. 이러한 구조로 서비스를 실행할 때 문제가 있었습니다. 사용자가 서버 내부의 데이터가 필요하다면 WAS에 직접적으로 요청을 보내야 했습니다. WAS에 사용자가 직접적으로 접근할 수 있게 하였을 때는 여러 문제가 발생할 수 있습니다. 1. 보안 제일 큰 문제는 보안입니다. WAS에 직접적으로 접근이 가능할 경우 데이터베이스가 털릴 가능성이 있습니다. 데이터 베이스에는 우리의 중요한 데이터들이 많이 있기 때문에 항상 조심히 지켜줘야 합니다! 2. .. 2022. 8. 8. Github OAuth 로그인 구현하기 OAuth 기능을 구현한 이유? 우리의 서비스에서 직접적으로 회원가입, 로그인 기능을 구현하여 회원 정보를 관리하고 사용하기보다는 이미 인증된 서비스에서 관리하는 회원 정보를 가져와 사용하기 위해서 OAuth 기능을 구현하였습니다. 진행 과정 깃허브 공식 문서 테스트에 사용된 코드는 깃허브에서 확인해볼 수 있습니다. 1. github settings -> Developer settings로 접근합니다. 2. New Github App을 클릭하여 새로운 Github App을 만듭니다. 3. App설정을 진행합니다. 다음과 같이 설정을 진행했습니다. 여기서 Callbak URL은 사용자가 깃허브 로그인 페이지에서 로그인에 성공을 하면 깃허브 측에서 이동 시켜줄 URL입니다. 4. 사용자의 github ID.. 2022. 7. 16. 이전 1 다음
