Skip to content

hyerijang/FoodieFinder

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

310 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

logo

FoodieFinder - 지리기반 맛집 추천 웹 서비스


Redis Amazon EC2 Amazon RDS

FoodieFinder는 공공데이터를 활용하여, 지역 음식점 목록을 자동으로 업데이트 하고 이를 활용합니다. 사용자 위치 에맞게 맛집 및 메뉴를 추천하여 더 나은 다양한 음식 경험을 제공하고, 음식을 좋아하는 사람들 간의 소통과 공유를 촉진하려 합니다.

☄️ Team Q members

김서윤 방성원 장혜리 정지원
@seoyoon047 @O0oO0Oo @hyerijang @cjw9506

0. 목차

1. 개발 기간

2023.10.31 ~ 2023.11.08 (9 days)

2. 프로젝트 요구사항

유저스토리

  • 유저는 본 사이트에 들어와 회원가입 및 내 위치를 지정한다.
  • A. 내 위치 기반 맛집추천 = (내 주변보기)
    • 도보 기준 1km 이내의 맛집을 추천한다.
    • 교통수단 기준 5km 이내의 맛집을 추천한다.
  • B. 지역명 기준 맛집추천(특정 지역 보기)
    • 지정한 지명(시군구) 중심위치 기준 10km 이내의 맛집을 추천한다.
  • C. 점심 추천 서비스
    • 점심 추천 서비스 이용을 승락한 대상에게 매일 정오, 대상의 위치를 기준으로 원하는 유형(일식, 중식 등)의 가게를 3개씩 추천 해준다.
  • A, B는 다양한 검색기준 (정렬, 필터링 등)으로 조회 가능하며 (거리순, 평점순 , 양식, 중식)
  • 해당 맛집의 상세정보를 확인할 수 있다.

3. 담당 역할

김서윤 시군구, 맛집 목록, 맛집 상세정보, 평가 API 구현
방성원 데이터 수집, 데이터 전처리, 자동화 구현 및 Redis 캐싱
장혜리 데이터 전처리, 데이터 저장, 디스코드 점심 추천 서비스 구현
정지원 사용자 관련 서비스 및 인증, 인가 구현

4. 프로젝트 아키텍처

5. ERD

자세히

6. 동작예시

RDS

디스코드 점심 추천 서비스 예시

7. API Document

최신 문서는 FoodieFinder API Document를 참조해 주세요.

8. 프로젝트 스케줄링

image

image

9. 구현 과정 (설계 및 의도)

(장혜리)

데이터 전처리 및 저장
  • JSON 데이터를 가공하여 제가 구현한 Restaurant, Raw Restaurant 엔티티에 넣어 저장
  • raw 데이터 테이블 - 특별한 변환이나 전처리 없이 String 그대로 저장
  • 실제 서비스에 이용되는 테이블 - raw 데이터 테이블에서 실제 사용되는 필드만 추리고, 데이터에 맞게 타입을 변경하여 저장
디스코드 점심 추천 서비스
  • 디스코드 메시지 양식에 데이터를 가공 후, 매일 정오 유저가 등록해 둔 웹 훅 URL로 메시지를 발송
  • 데이터 가공
    • DB에서 맛집 정보를 조회할 때 Spring Data JPA의 findAll을 쓸 경우 경기도 전체의 식당 데이터를 가져오게 되어 심각한 성능 저하가 예상되었습니다.
    • 따라서 유저를 중심으로 한 정사각형 영역의 꼭짓점을 구하여 유저 인근 N 미터 이내의 식당 정보만 가져오도록 구현하였습니다.
  • 유저 점심 추천 알림을 설정할 수 있게 하는 API 구현
    • 알림 설정 API를 통해 유저는 어느정도 거리 내의 맛집을 추천받을지, 또 한식, 중식 등 어떤 유형의 음식점을 추천받을지 선택 가능 -디스코드 메시지 발송
    • Quarz 스케줄러와 Webflux로 매일 정오 Nonblocking 하게 발송하도록 구현
      • Quarz 스케줄러의 경우 기존에 팀원분께서 데이터 수집에 이용하시던 부분을 그대로 차용해서 시간만 변경
      • Blocking 방식의 경우 메시지 발송 이후 디스코드 측의 응답이 돌아올 때까지 대기해야 했기 때문에, 유휴 시간을 줄이고자 비동기 방식으로 메시지 발송을 구현

10. 성능 개선 - 디스코드 점심 추천 서비스 (장혜리)

메시지 전송 : Blocking vs Nonblocking 성능 비교

성능 비교 결과 : 1회 전송되는 메시지 수가 많아 질 수록 Blocking vs Nonblocking에서 Nonblocking이 더욱 유리해짐. (CPU 유휴시간 감소)

보내야하는 메시지가 1건 일때, (각각 100회 수행)

  • Nonblocking으로 전환 한 결과 평균 응답 시간 403ms -> 18ms 로 감소 (약 22배 가량의 성능 개선)

보내야하는 메시지가 10건 일때, (각각 3회 수행)

  • Nonblocking으로 전환 한 결과 평균 응답 시간 3705ms -> 39ms 로 감소 (약 95배 가량의 성능 개선)

11. 기타 노력한 점

(장혜리)

  • 원활한 협업을 위해 엔티티 구현 등 다른 팀원의 업무에 필요한 부분(엔티티 등)은 우선적으로 구현하였습니다.

  • 빠르고 상세한 코드 리뷰를 위해 노력하였습니다

    코드 리뷰 예시 (자세히)

    PR 예시

  • 단위 테스트 작성을 위해 노력하였습니다.

    단위 테스트 예시 (자세히)

About

팀 프로젝트(4인) - 지리기반 맛집 추천 서비스

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • Java 99.9%
  • Dockerfile 0.1%