TIG

우리팀에서는 논리적 삭제 적용을 위해 soft delete를 사용했다. 위시리스트를 예를들어 보겠다.Wishlist 엔티티에 isDeleted 필드를 두어 DB에서 실제로 삭제하지 않고 해당 필드를 업데이트 하는 식으로 구현했다.따라서 wishlist에 추가 후, 삭제

소셜 로그인 우리 서비스에서는 소셜로그인을 지원한다. 일단 카카오 로그인을 구현했고, 추가로 구글 로그인을 구현 예정이다. 소셜로그인에는 크게 두가지 방법이 있다. 백엔드에서 모든 과정을 처리하고 JWT 토큰을 발급하여 리턴 함 프론트엔드와 적절히 역할을 나누어 로그

우리 서비스에서는 다른 서비스들도 그러하듯이 JWT 방식의 access token(AT)와 refresh token을 통해 사용자를 관리한다.따라서 다음의 로직을 사용한다.해당 메서드는 OncePerRequestFilter 클래스를 extend 한 클래스 내부에 있다.

우리 서비스에서는 JWT를 사용해 로그인을 구현했었다. 이에 따라 로그아웃도 기록하려고 한다.사용자가 로그아웃을 진행하면 기존의 토큰들을 무효화 시켜주어야 한다. 그렇지 않으면 개발을 좀 아는 사람이 토큰 값을 network 탭에서 까보고 가지고 있다가 억지로 악의적인

위 화면은 우리 서비스에서 볼 수 있는 검색 기록 화면이다. 여태까지는 기능이 구현 되지 않아서 그냥 더미데이터가 들어가 있었다. redis 를 도입하면서 구현을 완성 했다.redis에 대해서는 다른 포스트에서 더 자세히 작성할 예정이다.검색 기록을 MySQL DB에

1편에서는 로컬 환경에서 실행되게 했지만, 우리 서비스는 EC2 를 사용하여 배포를 했으므로 최종적으로는 EC2 환경에서 실행이 되어야 한다.일단 EC2 환경에 redis를 다운 받아야 한다.다운 받는 방법은 구글에 많이 정리 되어 있으니 따로 정리하지는 않겠다. 대신

우리 서비스는 docker 를 통해 배포를 진행했다. 로컬에서 도커 이미지를 생성하고 이를 도커 허브에 push 한 후, EC2 콘솔에서 pull 받아서 사용하는 방식이었다.배포를 위해서는 작성된 docker-compose.yml 를 통해 이미지를 생성해야한다. 하지만

TIG 서비스는 개발이 거의 완성되어 서비스를 출시 할 예정이다..!기존에는 Github Actions 를 통한 CI/CD를 구축하긴 했지만 다운타임이 완전히 없던 것은 아니다. 내가 새로운 기능을 개발하거나 수정사항이 있어서 코드를 수정 한 후 develop 브랜치에

적어도 20시간 정도는 잡고 있다가 결국 자고 일어나서 해결해버렸다.문제 상황이랄것도 없다. 그냥 nginx 를 연결하고 난 뒤로부터 CORS 에러가 계속 났다.이전 포스트에 작성했던 코드가 잘 실행되는 줄 알았지만 알고보니 nginx 파일이 전송되지 않고 있었고 이상

실제 운영되는 서버와 테스트 하는 서버가 분리되어야 함을 알고 있었지만 다른 것들을 먼저 처리하느라 조금은 늦게 시작하게 되었다. 결론적으로 성공했지만 또 역대급 시간을 쏟은 과정이 되었다.기존에 블루/그린 배포를 완성해 둔 상태이다. 현재 그린환경이 배포되어 있는 상

TIG 서비스에서는 사용자 별 검색 기록을 Redis 데이터베이스에 저장하여 관리한다.단순히 MySQL 데이터베이스에 저장하여 관리하는 것도 개발자 입장에서 편리할 수 있지만, 인메모리 데이터베이스인 Redis 를 사용하면 어느정도의 성능 이득이 있을지 확인해보았다.각

최근에 스타트업 면접을 보고왔는데, 면접관 분께서 제안해주신 방법으로 티그 최적화를 진행해보았다.기존의 티그 홈화면 로직은 다음과 같다.사용자의 위치 정보를 수집한다.위치 정보를 바탕으로 근처에 있는 업체를 계산한다. 이때, Haversine 방식으로 거리를 계산한다.