🏠

방갑고

생성일

2024/08/26 01:39

태그

룸메이트 매칭 서비스

깃허브

https://fab-fe-rust.vercel.app/

발표 영상

https://youtu.be/T61bLiATLN0

프로젝트 설명

룸메이트 매칭 플랫폼 - 방갑고 를 통해 사회 초년생들은 주거비용 부담을 줄이고, 적합한 룸메이트를 찾을 수 있습니다.

유형

명예의 전당

시연 영상

Project

프로젝트 아키텍쳐

기술 스택

Frontend

•

React

•

Typescript

•

Redux

•

React-router-dom

•

StompJs

•

Vite

styles

•

module.css

•

Ant Design

Communication

•

Slack

•

Discord

•

Gather town

Backend

•

Java

•

JDK 11

•

SpringBoot

•

Build Tool : Gradle

•

DB : Mysql, MongoDB, Redis

•

JPA, JDBC,Query Dsl

•

Test : Junit, Postman, Apic, Swagger-ui

•

Auth : Jwt

•

WebClient

•

WebSocket, Stomp, RabbitMQ

•

Cloud Storage Service : AWS S3

•

Spring Security

•

Swagger

CI / CD

function

Search

화면

게시글 (CRUD)

게시글 찜하기

1:1 룸메이트 매칭 (CRUD)

배경

유저들이 룸메이트를 찾기 위해 신청을 할 수 있는 게시글을 읽을 수 있고, 작성, 수정, 삭제를 할 수 있습니다. 원하는 게시글에 룸메이트 신청을 하고, 신청 받은 사람은 승인

구현한 기능

BE

룸메이트 매칭 시스템

화면

배경

로그인 한 사용자의 프로필 설정을 바탕으로, 자신과 성향이 비슷한 사람들을 쉽게 찾을 수 있습니다.

구현한 기능

BE

Querydsl을 사용해 추천 목록 불러오기 로그인한 유저의 정보를 받으면, 룸메이트 모집 글을 작성한 유저 중에서 흡연 유무, 원하는 지역, 활동 시간이 같고 희망 연령대에 해당하는 나이를 가진 유저 목록을 가져옵니다. 요청하는 size 수 만큼 가져오고, 무작위로 가져옵니다. 비교하는 조건들이 다양하고 룸메이트 모집 글을 작성한 유저 중에서 추천 목록을 가져와야 하기 때문에 JPA 대신 Querydsl을 사용했습니다.

FE

백엔드에서 내 프로필을 토대로 나이, 지역, 흡연 유무, 성별, 활동 시간대가 같은 유저를 필터링하여 그 유저의 정보를 랜덤으로 보내줍니다. 그 유저에서 mbti 궁합 계산기를 토대로 5단계 중 중간 이상으로 궁합이 맞는 유저만 추천하게 만들어 주었습니다.

룸메이트 추천

화면

배경

사용자가 지역, 기간, 보증금, 성별 검색 조건으로 원하는 목록만 조회할 수 있습니다.

구현한 기능

BE

Querydsl을 사용해 검색 결과 가져오기 사용자가 설정한 지역, 기간, 보증금, 성별 검색 조건에 해당하는 게시글 목록을 가져옵니다. 지역, 기간, 성별은 일치하고 보증금은 선택한 값 보다 작거나 같은 보증금으로 작성된 게시글들을 가져옵니다. isRecruiting 값을 받아서 모집 상태의 글만 불러오거나 전체 글을 가져옵니다. 페이징 처리를 해서 요청한 page, size 에 해당하는 결과를 응답합니다. 검색 조건 값을 “상관 없음”으로 보내면 해당 검색 조건은 필터링 대상에서 제외됩니다. 검색 조건이 다양하고, 요청으로 들어온 값이 “상관 없음”인 검색 조건은 필터링에서 제외해야 하기 때문에 Querydsl을 사용하여 검색 기능을 구현했습니다.

FE

유저가 지역 ,기간 ,보증금 , 성별을 선택하고 검색을 실행하면 handleSearch 함수를 내에 각 값들을 기반으로 searchParams라는 객체를 생성하고 이 객체가 api요청 url을 만듭니다. 그 url이 fetch를 통해 get 요청으로 서버에 보냅니다. 서버로부터 응답을 받으면 post상태를 useState로 저장하고 그 결과값들을 post와 postCard 컴포먼트에 전달되어 화면에 게시글 목록에 표시되게 합니다.

화면

배경

매칭 된 사람들끼리 채팅을 할수있도록 합니다.

구현한 기능

BE

채팅 - Websocket과 Stomp,RabbitMQ를 이용하여 채팅 시스템을 구현하였습니다. RabbitMQ 로 외부 브로커를 구현함으로써 API서버가 여러 대 가 운영되는 환경에서도 같은 topic에 대해 구독 상태라면 메세지를 송/수 신 할 수 있도록 하였습니다.

채팅 저장/불러오기 - 채팅 을 저장하는데에는 MongoDB를 사용하여 추후 사용량이 늘어나도 수평적 확장이 용이하게 구성하였습니다. (채팅의경우 다수의 사용자가 채팅을 읽고 쓰는 일이 많으며 추가적으로 join 필수적으로 안해도되도록구성하였습니다.)

채팅방 생성/채팅방 목록 불러오기(roomId) 각각의 채팅방에서는 채팅 유저정보 가 필요하기 때문에 mysql에 채팅방에 관련된 정보들을 구성하였습니다.

FE

채팅 roomId 생성 및 채팅 목록 생성 - 1:1 채팅을 위한 roomId를 생성하기 위해 서버에 ‘POST’ 요청을 보낸 후, 채팅방으로 이동 함과 동시에 ‘GET’ 요청을 통해 채팅 목록 상태 관리를 하였습니다.

채팅 서버 연결 및 구독 설정 - WebSocket을 이용해 STOMP 서버와 연결을 수립하며, 연결이 성공적으로 이루어지면 특정 주소(’/topic/chat.history …’)를 구독(subscribe)하여 이전 대화 내용을 서버로부터 받아옵니다. - 이전 대화 내용을 받아온 후 구독한 주소를 unsubscribe하고, roomId를 추가한 새로운 주소에 구독합니다. - 대화 도중 채팅 목록에 있는 다른 사용자를 선택할 경우, STOMP 연결을 해제(deactivate)하고 사용자를 초기화 합니다. 선택된 사용자와의 채팅을 위해 WebSocket 연결을 다시 설정합니다.

룸메이트 간 실시간 채팅

화면

배경

사용자가 프로필을 변경 할 경우 이미지 서버에 등록하고 반영 합니다.

구현한 기능

BE

이미지 업로드 S3 버킷을 이용하여 외부 이미지 스토리지를 구현 하였으며 api를 통해 요청온 multipart file 을 가공하여 S3로 업로드합니다. 이미지의 최대크기는 10MB로 설정하였습니다. :) user정보의 img 링크를 업로드한 링크로 변경됩니다.

FE

이미지 업로드 전 - 사용자가 업로드 하려는 이미지의 유형이 JPEG 또는 PNG에 해당 하는지와 크기가 10MB 이하인지 검사합니다. 조건 외에 해당 한다면 서버로 요청을 보내기 전 사용자에게 경고 메시지를 출력합니다.

이미지 업로드 - 해당 이미지는 FormData 객체에 담겨 ‘POST’ 요청으로 전송되며, 서버로부터 응답 받은 데이터에 포함된 이미지 URL을 상태 관리하여 업데이트합니다.

이미지 업로드

화면

일반 로그인

구글 로그인

카카오 로그인

배경

구현한 기능

BE

트러블 슈팅

TroubleShooting

Search

배경

로컬 환경이 아닌 배포 환경에서 서비스가 돌아가야 하기 때문에 백엔드 서버를 배포했습니다.

문제점

Commit 된 수정 사항들이 EC2 서버에 반영이 안 됨.

Vercel로 배포한 프론트엔드 배포 주소와 백엔드 서버 연결 실패.

이미지 업로드 과정에서 413 Request Entity Too Large 에러 발생

해결

Github Actions workflow에 작성한 대로 ‘main’ 브랜치에 merge가 될 때 마다 새로운 버전의 Image가 Docker Hub에 push가 되는 것 까지 확인했지만 그 후 docker compose up으로 재실행 시킨 서버에 해당 내용이 반영 안 되는 문제를 발견했습니다. 문제의 원인을 찾아본 결과, “docker ps”로 확인했을 때 컨테이너들이 재실행 되는 것은 맞았지만 “docker images”로 확인하니 Docker Image가 갱신이 안 되는 것을 알 수 있었습니다. 이 문제를 해결하기 위해 “docker compose up” 명령을 실행시키기 전에 프로젝트 Image를 pull 받아오고, “docker compose up” 실행 이후 “docker image prune -f” 명령을 통해 이미지를 새로운 버전으로 갱신하도록 했습니다. 이 방식으로 Github Actions workflow를 수정한 결과 내용이 ‘main’ 브랜치에 merge가 될 때 마다 해당 내용이 바로 서버에 반영되었습니다.

로컬 환경에서 기능 구현 및 API 연결 테스트를 끝내고 프론트엔드와 백엔드가 각각 배포를 하고 난 뒤, 배포 환경에서 연결이 잘 되는지 확인했는데 처음에 405 에러가 발생했습니다. 405 에러 관련해서 검색한 결과, 프론트엔드 배포 설정에 문제가 있었다는 점을 발견하고 해당 문제를 해결하여 405 에러는 발생하지 않았습니다. 하지만 405 에러가 나오지 않는 대신 Mixed Content 에러가 발생했습니다. 해당 에러에 대해 검색을 한 결과, 프론트엔드는 Vercel로 배포하여 https로 배포가 되었지만 서버는 따로 https 설정을 해주지 않아 발생한 문제였습니다. 해당 문제를 해결하기 위해 백엔드 서버도 https 설정을 하기로 결정했고, CloudFlare를 사용하기로 했습니다. CloudFlare에 DNS를 등록하고 Page Rule 설정을 통해 서버 https 설정을 할 수 있었습니다. CloudFlare 적용 후 프론트엔드 배포 주소와 백엔드 서버 주소 연결이 정상적으로 된 것을 확인했습니다.

배포 후 프로필 사진 변경 기능 구현 테스트를 했을 때, 413 Request Entity Too Large 라는 에러가 발생했습니다. 처음 이 에러를 발견했을 때 S3 설정에서 파일 크기 설정이 잘못 되었다고 생각했습니다. 하지만 로컬 환경에서 테스트 했을 때에는 정상적으로 이미지 업로드가 되었기 때문에 배포하는 과정에서 문제가 발생했다는 것을 알 수 있었습니다. 관련 에러에 대해 검색한 결과 Nginx http 설정에서 client_max_body_size 설정을 따로 하지 않으면 기본 설정은 1m 이기 때문에 발생한 문제였다는 것을 알게 되었습니다. 그래서 nginx.conf 파일에 프로필 사진 업로드 기능 구현 당시 정해 놓은 파일 크기로 client_max_body_size 값을 설정했습니다. 변경된 설정으로 다시 테스트 한 결과 이미지 업로드가 정상적으로 실행된 것을 확인했습니다.

백엔드 서버 배포

배경

프론트엔드, 백엔드 배포하기 전 로컬 환경에서 구현한 기능들이 정상적으로 작동하는지 테스트 했습니다.

문제점

프론트 로컬 환경에서 백엔드 서버에 연결할 때 Ngrok을 사용했지만 CORS 에러 발생.

해결

백엔드 서버에서 CORS 설정을 적용시키고, Ngrok 실행할 때 ngrok http -host-header=rewrite 8080 명령어로 실행시켰습니다. 그리고 프론트엔드에서는 Proxy 설정을 해주어서 CORS 에러를 해결할 수 있었습니다. 회원 가입, 로그인 API 테스트를 성공하고, 게시글 목록을 불러오는 API 테스트 했을 때 다시 Ngrok 연결에서 에러가 발생했습니다. 해당 에러는 GET 요청시에만 발생하는 에러로 GET 요청을 보낼 때 헤더에 "ngrok-skip-browser-warning": "69420” 를 추가해서 에러를 해결할 수 있었습니다. 헤더 내용 추가는 프론트엔드 배포할 때 모두 제거했습니다.

로컬 환경에서 프론트와 백엔드 API 연동

배경

사용자에게 ‘로그인’, ‘찜하기’, ‘1:1 매칭의 신청, 취소, 승인, 삭제, 거절’ 등의 기능을 제공

문제점

위의 기능을 구현하는 과정에서 상태 관리 이슈 발생 초기 useState를 이용하여 간단하게 데이터를 관리 하였지만, 사용자가 액션을 취했을 때, 실시간 반영이 되지 않아 문제 발생 사용자 경험(UX)를 저하시키는 요소로 작용

해결

상태관리 라이브러리 Redux를 적용하기 위해 Redux store 설정 및 각 기능에 대한 상태와 액션을 정의하였습니다. redux 관리가 필요한 ‘찜하기’, ‘1:1 매칭’ 기능 등의 action에 대한 처리 로직을 포함하는 reducer도 작성하였습니다. 이후, 해당 액션들이 dispatch 될 때마다, Redux store의 상태가 갱신되고 이를 구독하고 있는 컴포넌트들이 리렌더링 되도록 하였습니다. 따라서 Redux-Toolkit 도입을 통해 실시간 화면 반응 문제를 해결하였습니다.

데이터 관리 (Redux)

배경

프론트와 백엔드 서버 연동 과정 시, CORS 오류를 해결하기 위해 Proxy 설정

문제점

Proxy 설정 시, Vite TypeScript 환경에서의 import.meta.env 인식 오류 발생

해결

"vite-env.d.ts"를 tsconfig.json에 추가하고 파일 위치를 이동하였습니다. 그러나 이로 인해 src 내 TypeScript 문법 오류가 발생하였습니다. 따라서 "vite-env.d.ts"를 원 위치로 이동시킨 후, 동일한 파일을 상위 폴더에 추가하였습니다. 그러나 여전히 env 인식 문제는 해결되지 않았습니다.

import.meta 인터페이스를 확장하기 위해 "types.d.ts" 파일을 추가하고 declare global 문장을 작성하였지만, 여전히 env 인식 문제는 해결되지 않았습니다.

loadEnv(mode, process.cwd(), '')을 사용하였습니다. 이는 현재 작업 디렉토리에 있는, 모드에 해당하는 '.env' 파일을 찾아서 모든 환경 변수를 로드하는 방법입니다. 이 방법으로 import.meta.env를 사용하지 않고, .env 파일의 환경 변수에 직접 접근하여 문제를 해결하였습니다.

배경

메인페이지에 추천 시스템에 상대방 프로필을 눌렀을 시 백엔드에 무한 요청을 보냄.

문제점

ProFileDatas를 selectedUser가 열릴 때마다 계속 fecth를 하도록 설계되었습니다.

해결

profileDatasSuccess가 되었을 때만 profileDatas을 불러오도록 설계하였습니다.

프로필 모달 무한요청

배경

게시글 검색 후 모집, 전체글 모달 버튼을 눌렀을 때 검색된 게시글의 모달이 아닌 전체글이 다시 나와 모집, 전체글 모달이 실행되었습니다.

문제점

toggleRecruitOnly함수에 handleSearch함수를 호출하지 않아 토글 버튼을 눌렀을 시 검색 결과가 아닌 전체글이 토글되었습니다.

해결

useState로 handleSearch에 있는 값들을 관리하고 toggleRecruitOnly에 handleSearch를 호출하여 검색 결과를 업데이트 하도록 반영하였습니다.

검색 후 모집글, 전체글 모달 문제

배경

로그인하지 않은 유저가 메인페이지로 왔을 시 메인페이지에서 추천하는 사람이 없다는 에러를 계속 보냈습니다.

문제점

게시글을 불러오는 과정에서 로그인한 상태임의 조건문을 넣지 않아 계속 서버에서 요청이 되었습니다.

해결

로그인 상태를 불러오는 값인 isLogged를 만들고 useEffect 안에 isLogged의 조건문을 로그인 되었을 때만 Fetch하도록 수정하였습니다. 또한 useFetch를 사용하여 리팩토링도 진행하였습니다.

메인페이지 추천부분

배경

현재 각각의 테이블에 대해 jpa auditing의 기능을 통해 생성일, 수정일을 자동으로 입력하였습니다.

신청현황을 담당하는 테이블(apply) 에서 두명의 유저가 하나의 신청현황을 공유하고있어, 삭제에 대한 처리를 유저 각각 soft delete 처리하여 한쪽이 지우더라도 다른한쪽에는 영향이 없도록 처리했습니다.

상태가 가장 최신에 변경된 신청현황 기준으로 신청목록을 불러올때 정렬되며 이는 jpa auditing에서 수정된 modified date time을 사용하여 정렬하였습니다.

문제점

한 유저가 삭제(soft delete)에 의해 modified date time이 변경되었고 이는 공유하고 있던 다른 유저의 신청목록에 영향을 끼쳤습니다.

해결

query dsl의 벌크연산을 활용하여 jpa auditing 기능을 회피하여 사용했습니다.

원하지 않는 jpa auditing

발표 내역(용)?

ERD