🚆

Tweaver

생성일

2023/11/27 01:51

태그

당일치기 여행 스케줄링 플랫폼

깃허브

https://github.com/ValueWith

비고

프로젝트 설명

💭

혼자 여행하는것이 싫은 사람들에게 일행을 모집하고 매칭할 수 있다면 어떨까?

💭

여행 일정을 쉽게 계획할 수 있는 서비스가 있다면 어떨까? 좀 더 쉽게 여행을 떠날 수 있도록 도와주는 당일치기 여행 스케줄링 + 일행 모집 플랫폼입니다.

Overview

혼자가 아니야, Trip with buddy - Tweaver

💭

여행 일정을 쉽게 계획할 수 있는 서비스가 있다면 어떨까?

💭

혼자 여행하는것이 싫은 사람들에게 일행을 모집하고 매칭할 수 있다면 어떨까?

Tweaver 는

좀 더 쉽게 여행을 떠날 수 있도록 도와주는 당일치기 여행 스케줄링 + 일행 모집 플랫폼입니다.

🗓

일정을 등록하고, 함께 여행을 떠날 일행을 쉽게 구해보세요!

🪄

입력한 장소를 바탕으로 가장 최단 거리의 동선을 제안받아보세요!

👀

지도위에 장소와 순서를 시각적으로 나타냄으로써 한 눈에 일정을 확인해볼 수 있어요!

💬

실시간 그룹 채팅을 이용해 일행과 여행 전 필요한 사항들을 쉽게 조율해보세요!

서비스 아키텍처

ERD

주요기능

트위버 주요기능

구현한 기능

구현한 기능

FE

길찾기의 기준, 출발지 선택

BE

카카오 모빌리티 다중 목적지 API 다중 목적지 API를 사용한 이유는 적은 API호출로 모든 지점간의 양방향 거리를 구할 수 있기 때문으로, 최대 30개의 목적지를 검색할 수 있기 때문에 최대 10개의 지점의 양방향 거리를 10번의 api호출 만으로 알아낼 수 있습니다.

완전탐색을 사용해서 최적 경로를 정렬하여 반환 당일치기라는 컨셉으로 인해 최대 일정 수가 10개로 제한 되어 있고, 출발지가 정해져 있기 때문에 모든 지점의 거리를 완전탐색으로 구현하더라도 9!의 시간복잡도로 해결 가능하다고 생각이 들어 완전 탐색을 통한 최적의 경로 추천을 구현하였습니다.

추가적으로 구현하고 싶은 기능

•

지점간 거리를 다중 경유지 api로 변경하기

현재는 다중 목적지 api로 구현하여서 지점간 최대 반경이 10km로 제한 되어 있기 때문에 출발점과 목적지 사이의 거리가 최대 반경을 넘어서게 되면 거리를 추천해 주지 못하는 경우가 생기고 있습니다. 따라서 다중 경유지 길찾기로 지점간의 거리를 구하게 되면 제한 반경 거리가 없기 때문에 모든 거리를 추천해 줄 수 있을 것이라 생각합니다. 다만 api를 최소한으로 부르기 위한 로직이 다소 복잡할 것으로 예상됩니다.

경로 추천

구현한 기능

FE

성능 최적화, 이미지 최적화에 대한 고민 서비스 전체에서 많은 이미지를 사용하기 때문에, 이미지 최적화가 필요하다고 판단했습니다. Browser Image Compression 라이브러리를 통해 업로드 시 자동으로 이미지를 압축합니다.

스켈레톤 UI (Skeleton UI)

BE

AWS S3 사용 AWS S3는 확장성이 뛰어나고 안정적인 스토리지 서비스를 제공합니다. 이를 통해 대량의 이미지 데이터를 효율적으로 저장하고 관리할 수 있습니다.

AWS CloudFront 통합 이미지 파일과 같은 정적 콘텐츠의 전송 속도를 개선하기 위해, AWS S3와 함께 CloudFront CDN(Content Delivery Network)을 사용할 수 있습니다.

이미지 업로드

배경

사용자들이 등록한 그룹을 필터링을 통해 원하는 그룹만 볼 수 있어야 한다.

구현한 기능

쿼리는 page(페이지), status(모집상태), area(지역), sort(정렬), title(검색)이 있습니다.

FE

react-router-dom의 useSearchParams()를 사용 새로고침을 하면 사용자가 선택한 쿼리가 초기화 되는것이 아니라, searchParams.get(’옵션’)을 통해 동일한 쿼리의 데이터를 보여줍니다.

데이터 정렬 & 필터 그룹 데이터는 지역별로, 그룹의 모집 현황별로 필터가 가능합니다. 그룹 데이터의 최신순, 마감순 정렬을 지원합니다.

페이지네이션 사용자가 현재 어디까지 봤는지 기억하고 다른 모집글과 비교할 수 있도록 무한 스크롤링이 아니라 페이지네이션 방식을 채택하였습니다.

BE

QueryDSL을 사용하여 복잡한 검색 및 필터 조건을 처리합니다. 이를 통해 동적 쿼리를 생성하여, 다양한 사용자 요구에 맞춘 데이터를 제공할 수 있으며 가독성, 컴파일 시 문법 오류 등 장점으로 인해 사용했습니다.

Spring Data JPA Pageable 인터페이스 및 커스텀 페이지네이션 커스텀 DTO 사용 - Pageable 인터페이스를 사용하여 페이지 번호, 페이지 크기, 정렬 순서 등의 정보 등을 사용했습니다. - Page 객체 대신에 커스텀 DTO(Data Transfer Object)를 사용하여 필요한 정보만 전달 할 수 있도록 페이지네이션 응답을 설정했습니다.

검색 및 필터 기능

구현한 기능

배경

여행을 같이 갈 사람을 모집했다면, 여행 전에 조율이 필요한 점들을 함께 이야기 할 수 있어야 합니다.

채팅서비스는 다수의 회원이 참여하는 서비스입니다. 많은 데이터를 주고 받아야 합니다.

FE

SockJS와 StompJS를 활용한 실시간 그룹 채팅 구현 SockJS를 통해 웹 소켓을 연결하고, StompJS는 해당 웹 소켓을 통해 메세지를 주고받습니다.

사용자가 가입한 그룹 전체 채팅방 조회 & 채팅방 개별 알림 사용자가 가입한 그룹의 채팅방에 메세지가 있다면, 그 채팅방에 들어가지 않아도 마지막 메세지를 수신할 수 있습니다.

BE

WebSocket은 HTTP에서 작동할 수 있는 양방향 통신 프로토콜입니다. Spring이 제공하는 WebsocketApi를 이용하여 사용자들은 웹에서 실시간으로 채팅할 수 있습니다.

STOMP는 WebSocket 프로토콜을 이용하여 구성되는 단순 텍스트 지향 프로토콜입니다. 웹에서 수신, 발신되는 메시지는 메시지 브로커 역할을 하는 본 서버의 WebSocket 어플리케이션을 통해 관리됩니다. 이를 통해 메시지 전송의 안정성과 확장성을 높였습니다.

실시간 그룹채팅

배경

내가 만든 그룹, 내가 가입한 그룹, 승인 대기중인 그룹의 이력을 확인하고 관리할 수 있어야 한다.

구현한 기능

FE

그룹 관리 내가 만든 그룹과 내가 가입한 그룹, 승인 대기 중인 그룹 리스트를 확인 가능합니다. 내가 만든 그룹은 그룹 수정과 삭제가 가능하고, 가입된 멤버와 신청자 정보를 볼 수 있습니다. 내가 가입한 그룹에서 탈퇴하거나, 승인 대기중인 그룹에서 지원을 취소할 수 있습니다.

BE

마이라운지 그룹 조회 각 그룹 이력에 대하여 pagenation을 포함한 조회가 가능합니다. groupMember테이블의 status를 통하여 상태를 관리(승인, 거절, 탈퇴, 강퇴, 대기, 취소) 내가 만든 그룹 - 승인, 거절, 강퇴가 가능합니다. 참여 중인 그룹 - 탈퇴가 가능합니다. 대기 중인 그룹 - 신청 취소가 가능합니다.

그룹 상세보기 상세 페이지에서 신청 취소, 신청, 탈퇴가 가능합니다.

그룹 관리

배경

서비스에서 이메일 주소를 고유값으로 가지기 때문에 검증이 필요합니다. 사용자가 입력한 이메일이 유효한 이메일인지, 이미 가입된 이메일인지 확인할 수 있어야 합니다.

구현한 기능

FE

이메일 검증 사용자가 입력한 이메일이 유효한 이메일인지 react-hook-form에서 정규식으로 검증합니다.

BE

OpenFeign은 선언적 REST 클라이언트로써 Spring MVC 어노테이션을 사용해 인터페이스의 동적 구현을 생성합니다. OpenFeign을 이용해 mailgun(외부 api)이 제공하는 메일 전송 서비스를 이용합니다. 별도의 SMTP 서버를 구축하지 않고 메일 서비스를 유연하고 간단하게 사용할 수 있습니다.

Redis는 Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 인메모리 방식의 비관계형 DBMS입니다. 사용자 메일 인증 단계에서 일시적으로 필요한 데이터인 인증 코드를 효율적으로 관리할 수 있습니다.

이메일 인증

배경

사용자는 프로필 이미지, 닉네임, 비밀번호를 바꿀 수 있어야 한다.

구현한 기능

FE

프로필 정보 갱신 내 프로필의 정보가 수정되면 헤더에 노출되는 사용자의 이메일과 프로필 썸네일이 즉각 교체됩니다.

BE

가입 수단에 따른 로직 처리

프로필 편집

트러블슈팅

트위버 트러블슈팅

문제 상황

Mock API에서 백엔드 서버로 주소를 바꿔 API 요청을 보내면 CORS 에러로 요청이 실패하는 현상

문제 해결

Vite의 server.proxy를 사용하면 브라우저의 요청을 프록시 서버로 먼저 보내고, 프록시 서버가 실제 대상 서버에 요청을 전달할 수 있습니다. 이 설정을 통해 프록시 서버가 동일한 도메인에서 요청이 이루어진 것 처럼 보이도록 요청 도메인을 변경하게 되고, CORS를 우회할 수 있습니다.

/https://vitejs.dev/config/

/api 라는 문자열이 target 에 지정한 문자열로 변환되어 사용됩니다.

개발 환경에서 CORS (Cross Origin Resource Sharing) 에러 발생

문제 상황

Form 태그 내 컨텐츠들을 하위 컴포넌트로 분리했을 때 하위 컴포넌트에 있는 Input 에러 메세지가 제대로 노출되지 않는 문제 발생

해결 시도

Input 컴포넌트에 React-Hook-Form errors 객체가 제대로 전달되고 있는가?

로그인 및 회원가입 페이지에서 정상 작동 확인, 그룹 모집 페이지(GroupRecruit.tsx)내로 Input 컴포넌트를 위치시켰을 때는 메세지가 정상 출력됩니다.

따라서 form 태그와 분리되었을 때 문제가 발생하는 것으로 추정했습니다.

useForm에 register 함수에 Input이 정상등록되고 있는가?

기본정보 등록 컴포넌트(GroupRegistInfo) 에서 엔터 이벤트 발생 시에도 form의 onSubmit 함수에 어떠한 데이터도 전달되지 않는 것을 확인하고, 그룹 모집 페이지에서 errors props를 내려주기 위해 코드를 수정했습니다.

여전히 에러 메세지를 제대로 출력하지 못하는 것을 확인했습니다.

문제 해결

React-Hook-Form은 폼 데이터를 제출하는 시점에 자동으로 트리거되어 유효성 검사와 폼 제출을 실행합니다. (즉 폼에 등록된 이벤트)

useForm 훅을 호출한 쪽(Form을 사용하는 컴포넌트)에서 register로 한 번만 등록하고, props로 전달합니다.

React-Hook-Form 컴포넌트가 Form 태그와 분리되었을 때 Error 메세지를 출력하지 못하는 문제

문제상황

group 페이지 진입 시 호출되는 console.log(’render’)가 너무 많은 문제

React.StrictMode에 의해 console.log() 호출이 두 번씩 되는것을 감안해야함.

문제 원인

react-query의 QueryClient에는 refetchOnWindowFocus 옵션이 있음.

원인: refetchOnWindowFocus 옵션은 쿼리가 윈도우(focus)에 다시 맞춰져 다시 가져올지 여부를 결정함 default 값은 true로 되어 있음

해결: refetchOnWindowFocus: false 이 옵션을 false로 설정하면, 윈도우가 focus되는 이벤트에 대해 쿼리가 자동으로 다시 가져오지 않음 → 이는 윈도우가 focus될 때마다 자동으로 쿼리를 다시 실행하는 기본 동작을 끔.

react-router-dom의 useSearchParams

원인: setSearchParams를 통해 url을 업데이트 하게 되면 페이지 리렌더링 발생함 → React Developer Tools를 사용해 highlight를 표시해보면 Header, Footer까지 highlight 처리 됨

안전한 리렌더링? → 페이지에서 검색창에 검색어를 입력만 해 놓고 enter나 버튼을 클릭하지 않은 상태에서 페이지네이션 버튼을 클릭하면 setSearchParams가 호출되면서 리렌더링이 발생하지만 검색창에 입력한 텍스트가 그대로 남아있음.

https://github.com/remix-run/react-router/issues/8908

상태를 관리할 수 있는 state가 두 개

setParams()가 호출되면 setSearchParams() 호출

그룹 페이지에서 리렌더링이 무분별하게 일어나는 문제

문제 상황

그룹 모집 페이지에서 여행 일정을 등록하고, 기본 정보를 입력한 뒤 여행 일정을 수정하기 위해 돌아가면

폼 데이터가 초기화되는 문제

문제 원인

기본 정보 등록 컴포넌트가 언마운트되면서, 컴포넌트가 자체적으로 가지고 있던 상태값이 휘발되어서 생긴 문제

해결 시도

react-hook-form의 useForm에 있는 shouldUnregister props를 false 전달했으나 문제 해결 실패 →

shouldUnregister는 폼이 언마운트 되었을 때 값을 유지할지, 유지하지 않을 지 선택하는 옵션입니다. 기본값이 false로 지정되어 있어 굳이 지정할 필요가 없는 속성입니다.

폼 뿐만 아니라 폼을 담고 있는 컴포넌트 자체가 언마운트 되기 때문에 이 방법으로는 문제를 해결할 수 없었습니다.

문제 해결

언마운트 될 때 값이 저장되지 않고 있기 때문에 생기는 문제이기 때문에, 세션이 유지되거나 영구적으로 값이 저장되는 웹 스토리지에 저장을 하고, 마운트 되면 값을 가져오는 방식으로 해결하기로 했습니다.

컴포넌트가 언마운트 될 때 폼 데이터 초기화 되는 문제

문제 상황

빌드 후 배포 사이트에서 api 요청에 대한 응답으로 index.html만 보이는 상황이 발생

문제 원인

Proxy는 개발 서버에서만 작동하기 때문에 배포 환경에서는 프록시의 타겟으로 설정한 백엔드 서버의 주소가 /api와 매칭되지 않아 생긴 문제

해결시도

Vite의 Proxy 설정이 제대로 작성되어 있는가?

Proxy를 통해 CORS를 우회할 수 있기 때문에, Vite.config.ts가 제대로 작성되어 있는지 확인 → 로컬에서는 api 요청이 제대로 이루어지고 있기 때문에 Proxy 설정문제는 아닌 것으로 판단했습니다.

서버에 Access-Control-Allow-Origin가 제대로 등록되어 있는가?

CORS 에러의 가장 주요 원인은 허용되지 않은 주소에서 서버로 요청을 보냈기 때문이라고 판단했기 때문에

백엔드에게 제대로 배포 사이트의 주소가 등록되어 있는지 확인 요청

배포 후 API Response가 제대로 오지 않는 문제

문제 상황

프로필 이미지 업데이트 시

S3 버켓 기존 이미지 삭제 안되는 문제 발생

문제 원인

•

S3 버켓 정책 권한에서 삭제와 관련된 권한이 없었음

•

생성된 이미지 URL이 Encoding 된 문자열이라 “/”가 “%2F"로 변경되어있어
String.replace 메서드가 제대로 안됨
기존 URL 입력시 제대로 버킷 내 폴더 안의 파일을 제대로 찾지 못함

문제 해결

•

S3 버켓 정책 관련해 검색해보고 현재는 덮어쓰기는 활용하지 않아 삭제 권한 추가

•

현재 저장된 이미지 URL 주소 currentKey 생성 코드 수정

S3 버킷 내 이미지 삭제 안되는 이슈

문제 상황

•

S3에 이미지 파일을 업로드한 후, 이 파일들이 퍼블릭 도메인 주소를 통해 노출되고 직접적으로 S3 버킷에 접근 가능한 상태가 되었습니다.

•

프론트엔드에서 이미지 URL 주소만을 사용하여 데이터를 제어하는 환경을 구축하고자 했습니다.

문제 원인

•

S3 버킷의 공개 접근 설정: S3 버킷 또는 개별 객체에 대한 공개 접근 권한이 설정되어 있어, 누구나 해당 URL을 통해 이미지에 접근할 수 있습니다.

•

CloudFront 설정 부족: CloudFront를 통한 접근 제어 또는 보안 설정이 적절히 구성되지 않았을 수 있습니다. 이는 직접적인 S3 접근을 허용하고, URL을 통한 데이터 제어를 제한하지 않는 원인이 될 수 있습니다.

문제 해결

S3 버킷 정책 수정

CloudFront 설정 조정

Signed URL 또는 Signed Cookies 사용

IAM 정책 및 역할 설정

HTTPS 사용 강제

기대 효과

AWS CloudFront 사용

문제 상황

•

MySQL 데이터베이스에서 데이터 생성 시간이 UTC 기준으로 설정되어 있어서, 실제 한국 시간(KST)과 9시간의 차이가 발생합니다.

문제 원인

•

EC2 인스턴스와 MySQL 서버가 UTC 시간대로 설정되어 있습니다. 이 때문에 데이터베이스의 타임스탬프가 UTC로 기록되고 있습니다.

해결 시도

EC2 인스턴스의 한국 시간대 변경: 시도했으나 실패. EC2 인스턴스의 시간대 변경은 인스턴스 내의 모든 서비스와 애플리케이션에 영향을 미치지만, MySQL 서버의 기본 시간대 설정을 바꾸진 않습니다.

MySQL 서버의 한국 시간대 변경: 시도했으나 실패. MySQL 서버의 time_zone 설정을 변경하는 것은 데이터베이스 세션의 시간대를 변경할 수 있지만, 서버 재시작시 기본 설정(UTC)으로 다시 돌아감 , cnf 파일을 변경해 설정해주었지만 실패

Docker RUN 시 시간대 설정: 성공. Docker 컨테이너 실행 시 시간대를 한국 시간대(KST)로 설정하여, 컨테이너 내에서 실행되는 모든 서비스와 애플리케이션의 기본 시간대를 KST로 맞춘 것이 효과적이었습니다.

Docker 컨테이너의 환경 변수 설정

•

Docker 컨테이너 실행 시 -env 또는 e 옵션을 사용하여 시간대를 설정한 것이 성공적이었습니다. 예를 들어, docker run -e TZ=Asia/Seoul ... 와 같은 방식으로 한국 시간대를 설정

•

이 설정은 Docker 컨테이너 내에서 실행되는 모든 프로세스와 애플리케이션에 적용(스프링부트)

•

외에도 Dockerfile 또는 docker-compose.yml을 통한 시간대 설정해주면 해결이 가능하다.

데이터베이스 생성 시간 등 한국 시간

문제 상황

최단 경로로 모든 경로를 들르기 위한 알고리즘의 선택의 어려움

해결 시도

다익스트라 알고리즘 : 간선에 가중치가 있는 방향 그래프에서 최단거리 경로를 구하는 방식

그리드 알고리즘 : 각 단계에서 지금 당장 최적인 선택을 계속해서 내려가면서 최종적으로 전체적으로 최적해를 찾아내는 방식

지점들의 구역을 나눠서 구역별 완전탐색으로 적은 시간으로 최적의 근사치로 추천 경로를 계산하는 방식

완전 탐색 알고리즘 : 경로의 모든 경우의 수를 다 채크해서 정답을 찾는 방식

해결 과정

모든 지점의 x, y좌표를 받아서 모든 경우의 수를 순열(Permutation)로 정리

모든 순열에 대한 거리를 모두 계산해 본 후 가장 적게 나온 값을 return

문제 상황

카카오 모빌리티 api 호출 할 때, 지점 간 거리가 10Km 이상으로 지정하면 에러 발생

문제 원인

카카오 모빌리티 다중 목적지 길찾기 api를 이용한 지점 사이의 거리를 사용하여 각 지점 사이의 거리를 구하는 로직을 구현. 하지만 반경 10Km라는 제한이 있었기 때문에 구하려는 두 지점의 거리가 10Km를 초과하게 되면 api 호출에서 304번 에러 발생

문제 해결

카카오 모빌리티의 다중 목적지 길찾기 api에서 자동차 길찾기 api로 거리구하기 로직을 변경하여 지점사이의 10km 반경 제한없이 거리를 구할 수 있도록 수정

카카오 모빌리티 다중 목적지 반경 최대 10Km 이슈

지점 간의 경도와 위도로 단순한 직선 거리를 비교하는 것이 아니라 지점 간의 실제 이동거리로 경로를 추천하고 싶다. 따라서 카카오 모빌리티 Api를 통해 이동거리를 받아서 비교 기준으로 두고 싶다.

문제 상황

카카오 모빌리티 api 선정 문제 최대 지점 개수인 10개이 모든 지점 사이의 양방향의 거리가 필요하기 때문에, 단순 두 지점 씩의 이동거리를 받아 온다면 한다면 최대 90번의 api를 호출해야하는 문제

해결 시도

자동차 길찾기 api

다중 목적지 길찾기 api

다중 경유지 길찾기 api

문제 해결

다중 목적지 길찾기로 10번에 api호출만으로 모든 양방향 거리를 구해서 그래프로 정리

추천 경로 모든 지점 사이 거리 구하기

문제 상황

알람 구독후 쓰레드가 요청을 대기하면서 서버를 점유하고 있는 문제

문제 해결

알람이 필요한 경우 ApplicationEventPublisher 를 사용해서 이벤트를 발생 시켜

SSE알림 기능 쓰레드 비동기 이슈