팀플) 유성우 데이터 백엔드 전략

유성우 데이터도 API 수정이 들어가면서 꽤나 요청 시간이 오래걸리게 되었다.

그래서 우선은 요청을 날릴 때,

// 위도와 경도를 1도 간격으로 반올림 처리
const roundedLatitude = Math.round(location.latitude);
const roundedLongitude = Math.round(location.longitude);

해당 코드로 1도 간격으로 반올림 처리를 함.

어차피 국내 아니면 사용할 일이 없을 것 같다는 판단으로 이렇게 처리하고 이제 고민인데 여기 데이터에 영속성을 더할까 말까이다. 지금 프로젝트만 보자면 영속성없이 Redis로도 충분히 감당 가능할 것 같은데 나중을 생각하면 과거의 데이터까지 제공할 수 있을 것 같아서 DB 도입을 할까도 싶고..

우선 서비스를 진짜로 하는건 아니니까 그냥 DB는 도입하지 말고 Redis로만 처리하자.

이건 배포할 때 이제 캐싱 타임을 6개월로 고칠 것.

---

근데 가만 생각해보니까 캘린더도 쓰려면 그냥 캐싱 DB 다 있는게 좋을 것 같음.. 어차피 프론트 코드는 건드릴 필요없으니까 DB 어떻게 도입할지 고민 좀 해보자.

일단

-- astronomical_event 의 자식 meteor_shower_visibility 테이블
CREATE TABLE meteor_shower_visibility (
                                          visibility_id BIGINT NOT NULL AUTO_INCREMENT COMMENT '고유 가시성 ID (Primary Key)',
                                          event_id INT NOT NULL COMMENT '천문 현상 ID (Foreign Key)',
                                          comet_name VARCHAR(100) NOT NULL COMMENT '관련 혜성 이름',
                                          altitude DOUBLE NOT NULL COMMENT '고도',
                                          direction VARCHAR(50) NOT NULL COMMENT '방위각',
                                          distance DOUBLE NOT NULL COMMENT '거리',
                                          illumination DOUBLE NOT NULL COMMENT '달빛 비율',
                                          moon_phase DOUBLE NOT NULL COMMENT '달의 위상',
                                          phase_description VARCHAR(100) NOT NULL COMMENT '달 위상 설명',
                                          latitude DOUBLE NOT NULL COMMENT '위도',
                                          longitude DOUBLE NOT NULL COMMENT '경도',
                                          sunrise_time DATETIME NOT NULL COMMENT '일출 시간',
                                          sunset_time DATETIME NOT NULL COMMENT '일몰 시간',
                                          time_zone_id VARCHAR(50) NOT NULL COMMENT '타임존 정보',
                                          visibility_message VARCHAR(255) NOT NULL COMMENT '가시성 메시지',
                                          conditions_status VARCHAR(50) NOT NULL COMMENT '혜성 상태 (closing 등)',
                                          peak_start_date DATE NOT NULL COMMENT '피크 기간 시작일',
                                          peak_end_date DATE NOT NULL COMMENT '피크 기간 종료일',
                                          best_peak_datetime DATETIME NOT NULL COMMENT '최적 관측 시간',
                                          visibility_rating VARCHAR(50) NOT NULL COMMENT '가시성 평가',
                                          PRIMARY KEY (visibility_id),
                                          FOREIGN KEY (event_id) REFERENCES astronomical_event (event_id) ON DELETE CASCADE
);

이렇게 저장함.

---

우선 구조는 이렇게 되었고,

VisibilityResultsWrapper 클래스에서

{
  "visibility_results": [
    {
        //결과
    }
  ]
}

이걸 벗겨내는 역할.

DTO들은 요청 로직에 따른 Json 형태에 따라 나눴고, 엔티티, DTO 때문에 매핑을 위한 매퍼 생성, 리포지토리 생성.

service에서의 로직은

컨트롤러에서 파라미터 전달 받음 -> DB조회 -> 반환
데이터가 없어? -> 외부 API 요청 -> DB 저장 -> 저장한 DB 조회 -> 반환

이런식으로 구조를 짬.

사실 진짜 오류 엄청 많이 겪었는데 상세하게 쓰지는 못했음..

---

저장은 잘 됨 이제 조회 시키면 된다.

조회도 성공.

그럼 이걸 이제 Json으로 변환해서 보내주면..

완료.

기존 Util클래스를 활용함.

---

제일 큰 문제를 겪었던 것은 DTO와 Jackson이슈였는데,

OffsetDateTime 타입의 필드(sunriseTime 등)를 JSON에서 String으로, 또 그 반대로 변환하는 데 문제가 생김.
ObjectMapper는 기본적으로 Java 8의 날짜와 시간 API(java.time 클래스들)를 지원하지 않기 때문에 변환이 실패했던 것. 문제를 해결한 방법은 Jackson의 JSR310 모듈을 추가로 등록해줘서 해결함.

이게 문제라는걸 찾는데 좀 오래 결렸음.

여튼.. 일단 마무리 하고 다음으로 캘린더 로직 완성 후에 행성대접근을 처리해보자.