팀프로젝트 3일차까지 거의 기획 및 밑 작업을 한것같습니다. 21일(4일차)는 댓글, 좋아요 관련해서 작업을 했기에 크게 기록할만한 내용은 없습니다. 22일(5일차)에는 본격적으로 기능들이 다 완성되어가면서 테스트를 해보니 실수한 것들이 좀 있어서 수정하는 과정을 거쳤습니다.
22일(5일차)에 반려 동물에게 필요한 시설들의 위치를 보여주기 위해 지도 API 관련해서 찾아보고 어떻게 만들어야 될까 고민했습니다. 그래서 팀원들이 모여 튜터님과 얘기하던 도중 위 사진의 사이트를 알게되었는데 비슷한 형식으로 작업을 하려고 결정했습니다.
23일(6일차) 새벽 쯤에 완성한 프로토타입입니다. 리액트는 잘 모르기에 AI의 도움을 받고 카카오 API를 연결하면서 완성했습니다. 프론트엔드에서 카카오 REST API를 이용해서 하기에 이 부분만 옮기면 되지않을까 싶었습니다.
하지만 튜터님과 얘기를 하다보니 단순 API 연결이 비용도 그렇고 의존성이 너무 높아지는 것이 아닐까라는 질문을 하셨을 때 속으로 이런 내용까지 깊게 고민을 해보지않았구나라는 생각이 들었습니다. 나중에 카카오가 API 비용을 올렸을 때 회사 입장에서는 API를 교체할 수 있는 것이고 항상 바뀌는 것을 염두에 두어야하는데 검색 엔진과 데이터까지 의존하게 되면 사실상 프론트만 바꿔도 되는 작업을 프론트엔드, 백엔드 다 갈아엎어져야되는 것입니다.
그래서 방향을 수정하게 되었습니다. 프론트엔드에서는 지도는 카카오 Map을 이용하되, 정보는 저희 서버에서 제공하는 것으로 되는 것입니다.
지금은 너무 많은 데이터를 제공할 순 없으니 데이터를 조금 넣어두고 나중에 크롤링을 생각해보는 것을 고민해보라고 하셨습니다. 저희가 정해진 기간에 보여줘야할 것이 있으니 이 방향이 맞는 것같습니다. 일단 기능이 완성되고 데이터를 늘리기만 하면 되는 것이라 데이터가 많아져 쿼리가 느려지는 상황은 그때 고민해봐도 될 것같습니다. 그래도 너무 고민 안해보는 것은 그러니 MVP때까지 적용해볼 법한 기술은 쿼리 최적화나 인덱싱 기법이 최선일 것 같습니다.
24일(7일차)에 구조를 잡고 만들기 시작했습니다. 찾아보기도하고 저와 비슷한 작업물들이 많이 나오는 걸 보면 많은 분들이 거쳐간... 다들 비슷하게 생각한 것 같습니다.
그래도 추후에 확장 될 기능들을 생각하면 팀원들과 정한 지금 방향도 나쁘지않다고 생각합니다..!
Entity를 동물 병원이 아닌 시설쪽으로 이름 지었습니다. 추후에는 카테고리화 시켜서 동물 병원만 표시 될 것이 아니기 때문이기도 합니다.
RequestParam으로 쿼리에 필요한 정보를 프론트에서 전달받도록 제작했습니다.
searchFacilities(@RequestParam String category, @RequestParam double x,
@RequestParam double y, @RequestParam double radius, @RequestParam int page, @RequestParam int size,
@RequestParam String sort)범위 검색도 위도, 경도로 판단하는 식들이 많이 나와있길래 해당 내용을 참고하여 작업했습니다.
(6371 * acos(cos(radians(:y)) * cos(radians(f.latitude)) * cos(radians(f.longitude) - radians(:x)) + sin(radians(:y)) * sin(radians(f.latitude)))) <= :radius)생각만큼 순조롭지가 않았는데 쿼리가 생각만큼 잘 작동하지 않았습니다. 쿼리를 수정하고 프론트엔드에서도 요청이 쉴새없이 전송이 되어서 디바운싱(Debouncing) 기법을 적용했습니다.
const searchFacilities = useCallback(debounce(async (centerPoint, radius) {
...
}디바운싱 기법은 좋아요를 구현할 때도 적용하면 좋을 것 같습니다.
그래서 완성된 결과물...!
근데 뭔가 잇아합니다. 중심을 기준으로 원 반경을 그리는데 그게 이상한걸까요 뭐가 이상하긴한데 설명이 안되는 이상함이 있습니다.
범위가 없어서 그런가 싶어서 넣어줬는데 그래도 뭔가 이상합니다... 아무래도 지도 크기에 비례하지 않는 것이 문제라 생각이 됩니다. 단순 zoom level로 판단하기엔 유저 경험이 나빠보입니다.
백엔드가 고민할 문제는 아닐 수 있겠지만 지도의 크기를 반환하는 getBound() 함수를 알아냈습니다.
이걸 이용해서 지도 크기에 맞는 원을 그릴 수 있다면 최선이 아닐까 생각이 듭니다.
그리고 페이징 처리를 해서 데이터를 넘기는데 범위에 걸리는게 많아지면 페이징에 걸려서 문제가 될 수도 있으니 최대 줌 레벨도 조절을 해줘야될 듯 싶습니다. 아니면 그냥 범위에 걸리는건 다 가져오는 걸로 해도 될지 질문을 해도 좋을 것같습니다. 계속 달리고 싶지만 이제 1주차가 넘었습니다. 다른 팀들은 좀 느긋하게 한다해서 저희 팀만 달리고 있나 너무 빨리 지치는 건 아닐까 싶어 고민이 되기도 합니다.
그래서 오늘은 이정도로 끝!!
