좋아요 기능 구현 원리?
-
좋아요 추가 API와 삭제 API 두 가지로 나눠서 구현했습니다.
-
유저가 좋아요를 클릭했을 때, 좋아요 테이블 안에 누른 적이 있는지 row를 스캔하고 없을 경우에 추가한 후, post table안에 좋아요 카운트를 1 증가시킵니다.
-
유저가 좋아요를 취소 할 경우, 좋아요 테이블 안에 정보가 있는지 스캔하고, 있을 경우 row를 삭제한 후에, post table안에 좋아요카운트를 1 감소 시키는 방식으로 구현했습니다.
조건 검색 기능 구현 원리?
- 조건들을 클릭 하고 검색을 했을 때, 해당 조건들의 아이디 값을 토대로 inner join문을 활용해서 조건에맞는 데이터를 조회합니다.
토탈 검색 기능은 어떻게 구현했나요?
추후 추가
메인페이지의 기능은 어떻게 구현하셨나요?
-
메인페이지의 기능은 스케줄러를 사용해 외부OpenAPI인 OpenWeather와 기상청을 10분에 한번씩 요청하여 현재 날씨정보와 미세먼지를 조회한 다음 현재날씨의 테이블에 저장합니다.
-
사용자가 메인페이지에 접속했을때, 현재날씨 테이블을 조회하여, 날씨에 맞는 포스트, 추천횟수가 많은 포스트, 그리고 운영자가 추천하는 포스트들을 가져옵니다.
왜 메인페이지 기능에서 스케쥴러를 사용하셨나요?
-
처음 사용자가 접속하게 되면 메인페이지가 먼저 열려 현재 날씨를 조회하게 되는데, 그때마다 외부 API의 요청을 기다리는것은 속도적으로 매우 느렸고, 발급받은 Access Key로는 하루 요청 가능한 조회 횟수를 쉽게 초과할수 있다고 판단했습니다.
-
이를 방지하고 속도적인 측면을 올리고자, 사용자 API를 요청하는 것이 아닌, 서버가 스케쥴러를 통해 정보들을 데이터베이스에 저장하고, 사용자는 데이터베이스에 있는 현재 날씨들을 조회하게 됨으로써 초기 조회 속도인 500ms에서 75ms미만으로 줄일 수 있었고 AccessKey의 하루 한도치를 넘지 않게 되었습니다.
찜한 포스트 조회는 어떻게 구현하셨나요?
- 사용자가 찜하기 버튼을 누를 경우 현재 사용자의 고유 ID와 누른 포스트의 고유ID가 Favorites라는 테이블에 저장됩니다.
- 찜한 포스트를 조회하게 된다면, 현재 사용자의 ID와 서버로 요청한 사용자의 ID값이 맞는지 비교검증하는 작업 후, 만약 맞다면 현재 사용자의 찜한 포스트 목록 테이블로 부터 불러옵니다.
가본 리스트 조회는 어떻게 구현하셨나요?
-
사용자가 가 본 리스트를 누를 경우 현재 사용자의 고유 ID와 누른 포스트의 고유ID가 Visited라는 테이블에 저장됩니다.
-
가본 리스트를 조회하게 된다면, 현재 사용자의 ID와 서버로 요청한 사용자의 ID값이 맞는지 비교검증하는 작업 후, 만약 맞다면 현재 사용자의 가본 목록 테이블로 부터 불러옵니다.
소셜로그인은 어떻게 구현하셨나요?
-
카카오 로그인 API를 사용하여 소셜로그인을 구현했습니다.
-
프런트엔드에서 받은 인가코드로 유저 토큰을 받고 토큰으로 유저정보를 확인한 후 존재하는 유저라면 바로 로그인, 아니라면 회원가입 후 로그인을 하는 방식으로 구현하였습니다.
상세페이지는 어떻게 구현하셨나요?
-
상세페이지는 포스트 좋아요, 리뷰 좋아요, 리뷰 작성 여부에 따라 달라지기 때문에 로그인한 유저와 그렇지 않은 유저를 나눌 필요가 있었습니다.
-
로그인 한 유저라면 포스트 좋아요 여부, 리뷰 작성 여부, 리뷰 좋아요 여부를 확인을 해서 상태값 1로 응답했고 만약 로그인을 안한 유저라면 이런 것들의 상태값을 0으로 줘서 응답했습니다.
-
프런트에서는 이러한 상태값들을 보고 좋아요나 리뷰 작성 여부를 판단 할 수 있었습니다.
