함께 알아가는 IT 정보

지금 로그인 상태를 확인하는 방법이 꽤나 괴랄하다.세션 유지 방식sessionManagement.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)이 설정은 인증된 사용자가 있을 경우 세션을 생성해서 인증 상태를 유지하겠다는 의미. 즉, 로그인한 사용자는 세션을 통해 계속 인증 상태를 유지할 수 있음.인증 상태 확인Spring Security는 SecurityContextHolder와 Authentication 객체를 사용해 인증 상태를 자동으로 확인.예를 들어, /api/** 경로에 접근하려면 사용자가 인증되어야 하도록 설정되어 있고, 인증되지 않은 경우에는 자동으로 customAuthenticationEntryPoint가 호출되서 401 Unautho..

일단 유성우든 대접근이든 한번에 요청해야하는 데이터량이 적지는 않을 것이라 판단한다.그럼 API 호출을 여러번 하게 되고, 그건 성능과 비용문제로 직결됨.그래서 이번에 도입해놓을 것은 Betch임.Batch가 유용한 상황대량의 이벤트 추가/수정/삭제:유성우나 행성 대접근 데이터처럼 수십 개, 수백 개의 이벤트를 한꺼번에 처리해야 할 때.개별 요청을 보내면 네트워크 부하와 속도 문제가 생길 수 있는데, Batch로 묶으면 한 번에 처리 가능.API 호출 비용 절감:구글 캘린더 API는 호출 횟수 제한(쿼터)이 있음.Batch를 사용하면 여러 요청을 하나의 HTTP 요청으로 합쳐 보내므로 쿼터 소모량 감소.일관된 데이터 처리:여러 이벤트를 처리하는 중 일부 실패할 수 있음.Batch를 사용하면 요청 단위로 ..

우선은 리포지토리와 엔티티를 생성하고 그에 맞게끔 연결은 했는데.DB를 추가 한 이유가 사용자 UI 개선의 목적도 있지만 결국 결론은이제 DB저장을 하면 고유한 ID 번호가 생김 -> 복잡한 형태의 고유 ID를 입력하기 싫음.이거임.그래서 지금 작성한 로직을 DB ID 번호로 돌아가게끔 해야됨. 지금은 googleEventId를 내가 입력을 해줘야지 찾는데, 그게 아니고 고유 번호를 따라서 googleEventId를 찾아서 캘린더까지 접근해서 수정 삭제 읽기가 가능하게끔. 현재 코드는@Service@RequiredArgsConstructorpublic class PublicCalendarEventService { private final CalendarEventManager calendarEvent..

우선 API 연결을 위해서 다시 구글 콘솔로 진입.추가해줬음.우선 약간의 문제가 있다면 나는 데이터를 보여줄 캘린더 하나, 그리고 사용자가 천체 관측 일정을 관리할 수 있는 캘린더 하나를 이 구글 캘린더로 제공을 하고 싶었는데, 이게 내 공용 캘린더를 읽기전용으로 전환해서밖에 보여줄 수 없다는 결론에 도달함.그게 아니라면 데이터를 보여줄 캘린더 따로 구축, 또 사용자는 구글 캘린더를 사용해야되는데, 이 과정에서 공용 데이터 캘린더 -> 사용자 캘린더로의 일정 복사도 복잡해질 것 같고.. 그래서 일관성 있게 그냥 내 구글 계정에 캘린더를 희생하기로 함.여튼 결론이 뭐냐?공용 캘린더에 이벤트 추가 및 공유: 천문 이벤트와 관련된 정보를 하나의 공용 캘린더에 추가하고, 이 캘린더를 사용자들에게 읽기 전용으로 ..

유성우 데이터도 API 수정이 들어가면서 꽤나 요청 시간이 오래걸리게 되었다.그래서 우선은 요청을 날릴 때, // 위도와 경도를 1도 간격으로 반올림 처리const roundedLatitude = Math.round(location.latitude);const roundedLongitude = Math.round(location.longitude);해당 코드로 1도 간격으로 반올림 처리를 함.어차피 국내 아니면 사용할 일이 없을 것 같다는 판단으로 이렇게 처리하고 이제 고민인데 여기 데이터에 영속성을 더할까 말까이다. 지금 프로젝트만 보자면 영속성없이 Redis로도 충분히 감당 가능할 것 같은데 나중을 생각하면 과거의 데이터까지 제공할 수 있을 것 같아서 DB 도입을 할까도 싶고..우선 서비스를 진짜로 ..

그니까 뭐가 맘에 안들었냐 하면 지금 로직은 UTC 시각 기준으로 하루만 요청을 하는데 이러면 24시간중 UTC 시간 기준으로 0시만 요청하게 되어서 데이터의 의미가 없어짐.이게 이유를 설명하자면지구는 자전중임. -> UTC기준 0시만 검증함. -> 위도 경도 값을 받는 이유가 없어짐. -> 왜? 애진작 UTC 기준으로 0시만 요청하면 위도 경도를 받아봤자 가시성에 대한 평가는 명확하게 처리를 못함. -> 그래서 로직 자체를 UTC 기준 24시간을 1시간 단위로 나눠서 하기로 함.일단 이게 결론인데, 또 다른 문제는 피크타임의 start_date에서만 이 계산을 했다는거.그래서 피크타임의 시작점과 끝점을 순회하면서 고도와 달의 위상을 비교해서 Best_time을 뽑아내고 그 결과를 포함한 결과를 보여주도..

이제 유성우 데이터 통신 로직을 짜면 됨.뭐 기존에 했던 별자리, 행성과 같음.MeteorShowerController와 MeteorShowerService생성하고 기반 다져놓고..이제 또 다 프론트에서 처리해야됨.그전에 시큐리티에 등록해두자.징글징글하구만여튼 백엔드 로직은 이제 준비 다 됐음. 추후에 DB에 저장해놓고 꺼내쓸거라 이건 일단 나중에 하자. (유성우는 주기가 많이 일정해서 이렇게 써도 됨.)간만에 Postman 한번써볼까?이렇게 요청 보내보자구굳 이럼 이제 프론트 로직을 짜면 되는데 그전에 이걸 DB에 어떻게 집어넣을지 고민 좀 해보자.아 내가 지금 내가 만든 API 명세서를 다시 보고 왔는데 저것도 로우데이터였음 ㅋㅋmeteor_shower_visibility라는 경로로 위도 경도값으로 ..

나는 몰랐는데 팀원들이 내 코드를 받아서 요청보낼 때 행성 하나씩 오류가 나는걸 발견함.지금 문제는 ->동시에 다수의 행성 데이터를 요청할 때, SQLAlchemy 세션이 동일 트랜잭션 상태를 공유하거나 적절히 초기화되지 않아 Can't reconnect until invalid transaction is rolled back 에러가 발생함. 이로 인해 트랜잭션 충돌이나 데이터베이스 연결 문제가 간헐적으로 나타남.으로 정리할 수 있음.그래서 이걸 근본적으로 해결하기 위해서는SQLAlchemy 세션 관리 최적화retry_query 개선데이터베이스 연결 풀 확인 및 최적화캐싱 도입이정도?순차적으로 해보자.우선은 app/__init__.py에 # scoped_session 설정Session = scoped_s..

처음 계획은 백엔드로 통신하고 값까지 검증해서 관측 가능한 상태랑 불가능한 상태로 나눌까 했었는데, 가만 생각해보니까 비효율적이라는 것을 깨닫고 오직 프론트에서만 돌아가도 된다고 결론이 났음.왜? 데이터는 데이터대로 보여주고 마지막에 요청 위치의 날씨를 확인하고 그날 기후는 뭐 흐리니 관측이 어려울 수 있음. 만 말해주면 끝날 문제라 프론트에서 충분히 처리 가능함.기존에 학원 과제 때문에 약식으로 만든 Weather API 프로젝트가 있어서 거기서 API KEY 가져와서 재사용하면 됨.여튼 .env KEY 값 저장하고 시작하자.useUserLocation훅을 사용해서 요청을 보낼거고, WeatherPage.js에서 mainPage접근시에 알아서 요청되게 했음.그래서 일단 요청에는 성공했음.여기 비회원이면..

이거 컨트롤러랑 서비스 준비는 해둠 사실.근데 캐싱은 안만져놔서 해놓자고@Cacheable(value = "planetVisibility", key = "#planetName + '-' + #latitude + '-' + #longitude + '-' + #startDate + '-' + #rangeDays")@Retryable(value = {RestClientException.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000))캐싱 설정도 했고, @Retryable은 재시도 로직인데 Spring Retry의존성 주입해서 사용함. 이런게 있길래 넣어둠.여튼 백엔드 준비는 끝남.그래서 이제 프론트 작성하고 요청 해봤는데이게 백엔드 로직이 파라미터가 da..