BE

서론Github Actions와 Docker를 이용하면 손쉽게 CI/CD를 구축할 수 있다. 구축 과정에서 발생한 여러 에러들을 어떻게 해결했는지 공유를 해보고자 한다. 기본적인 서버 환경은 아래와 같다.Springboot v3.1.3Java 17Ubuntu 22.04.2 (메인 서버, AWS EC2)Ubuntu 22.04.6 (테스트 서버, GCP Compute Engine)Github Container Registry CI/CD 전체 과정Github Actions와 SSH를 사용하는 CI/CD 구축 과정은 간단하다.작성한 코드를 commit하고 자신의 Github Repository에 push한다.Github Actions가 내가 main.yml에 작성한 내용에 따라 작업을 수행한다.(1) Sprin..

현재 뮤피에서 소셜 로그인을 OIDC를 사용해서 구현하고 있다. 카카오, 구글, 애플 로그인을 제공하는데, OIDC도 OAuth2.0의 확장 스펙이다 보니 각 로그인의 구현 방식이 서로 같다. 현재 코드가 구현에만 신경을 쓰다 보니 카카오 로그인 먼저 구현하고 나머지는 복붙해서 변경 부분만 바꿔둔 상태였다. “객체 지향과 디자인 패턴”이라는 책을 읽는 중에 디자인 패턴 중 하나인 “템플릿 메서드 패턴” 파트를 읽다가 소셜 로그인 부분에 적용할 수 있을 것 같아서 미뤄놨던 리팩토링을 해보려고 한다. OIDC를 어떻게 구현했는지는 아래의 링크에 자세히 설명해두었다. https://aodtns.tistory.com/124 Open ID Connect 으로 구글 로그인 구현하기 (feat. SpringBoot)..

뮤피에서 홈 화면에 우리가 직접 선정한 곡을 매주 월요일에 추천해 주는 “이 주의 추천 곡”이라는 컨텐츠가 있다. 기본적으로 RestTemplate로 Spotify API를 호출하여 곡 정보를 불러오는데, “이 주의 추천 곡”은 현재 홈 화면에 있어서 조회를 많이 할 확률이 높기 때문에 불필요한 Spotify API 호출을 줄여야 했다. 1. 기존 방식 성능 측정하기 1.1 기존 방식 [사용자] 이 주의 추천 곡에 있는 곡들 중 하나 클릭 [클라이언트] 해당 곡의 track id로 곡 정보 조회 요청 [서버] RestTemplate으로 Spotify API 호출하여 정보 조회 곡 정보와 사용자의 평점 정보 등을 함께 응답 곡 정보 요청에 사용자의 평점 정보 등을 함께 제공하기 때문에, 단순히 요청에 대한..

뮤피에서는 기존에 OAuth를 사용하여 소셜 로그인을 구현하였다. 소셜 로그인 구현 방식은 다음과 같다. Client가 Authroization Code를 받아서, Server에 보낸다. Server는 받은 Code로 Resource Server에 접근하기 위한 Access Token을 Authorization Server로부터 발급받는다. 발급받은 Access Token으로 Resource Server에게서 정보를 가져온다. 로그인 혹은 회원가입 처리를 한다. OAuth의 문제점 OAuth를 사용하면 발급받은 Access Token이 뮤피에게서 받은 것인지는 알 수가 없다. 단순히 Resource Server에 접근하기 위한 Access Token이기 때문이다. 이는 OAuth가 인증이 아닌 “인가”에..

서론 Go + Fiber로 개발했던 Grafi 서비스를 Java + SpringBoot로 마이그레이션하는 작업을 본격적으로 시작했다. 일단 가장 먼저 모든 엔티티에 CreatedAt, DeletedAt 같은 공통 필드를 선언하기 위해 당연히 @MappedSuperclass를 사용하려고 했지만 문득 Embedded Type도 필드들을 묶어서 선언하는 것 아닌가 하는 생각이 들었다. 비슷한 고민의 글들이 많아서 이를 종합하여 정리해 보았다. @MappedSuperclass 엔티티 간의 공통 속성과 메서드를 추출하여 재사용 이 애너테이션이 붙은 클래스는 테이블을 생성하지 않고, JPA에서 관리되는 엔티티가 아니다. 이 클래스의 속성과 메서드는 이 클래스를 상속받은 실제 엔티티 클래스에서 사용된다. 테이블과 관..

서론 현재 React와 SpringBoot를 사용하여 프론트엔드와 백엔드 개발을 하고 있다. Jwt 토큰( Access Token, Refresh Token)을 사용하여 인증하고 있고, Interceptor를 사용하여 요청이 Controller 단에 도착하기 전에 인증을 한다. 그런데 요청을 보내면 react의 url인 localhost:3000을 allow 해주었는데도 CORS 에러가 발생한다. 이유가 뭘까? 문제 상황 CORS 에러 발생 위와 같이 React(localhost:3000) 에서 SpringBoot(localhost:8080)로 요청을 보낼 때 CORS 에러가 발생한다. 백엔드 로그 확인 서버에서는 JwtInterceptor에서 에러가 발생했다고 한다. JwtInterceptor 코드 ..

서론 이번 프로젝트는 특히 코드, 네이밍, 구조에 신경을 많이 쓰면서 개발을 하다 보니 기존에 했던 방식에 의문이 생겼다. 로그인 시에 사용자가 입력한 id를 백 단에서 조회할 때 해당 id가 없다면, 해당 id가 없다는 것을 성공적으로 확인했으니 클라이언트에게 status code를 200(ok)으로 응답하는 게 맞는 걸까? 아니면 해당 id가 없기 때문에 404(not found)로 응답하는 게 맞는 걸까? 영한님 강의에서도 200을 던지는 것도 방법 중 하나라는 것을 얼핏 들었던 것 같기도 하고 서버에서 정상적으로 처리를 한 것이기 때문에 200을 던져도 무방하다고 생각은 했지만 뭔가 찝찝해서 이번 기회에 개발 오픈 채팅방에 물어봤다. 200인가 404인가 질문을 잘..한 것 같진 않지만 뭐 XY..

도커로 노드 js 이미지를 만들고 5000:8080으로 포트 매핑 후 run 해보니.. docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:5000 -> 0.0.0.0:0: listen tcp 0.0.0.0:5000: bind: address already in use. ERRO[0000] error waiting for container: context canceled 이런 에러가 떴다.. 보니까 이미 5000번 포트를 사용 중이라는 건데.. 로컬에서 다른 서버를 사용하지도 않는데 뭔가 싶었다. 사용 중인 포트를 확인해보니 ControlCe가 사용 중이었고, 찾아보니 맥북 AirPlay에서 5000 ..