The auction-map from positoy

auction-map's People

Contributors

Watchers

auction-map's Issues

(modeling) 대법원, onbid, KDIC 데이터 정리

약 60개 법원 x 3개 매각기일 로 분류 가능
url :
데이터
- 사건번호
- 물건번호
- 물건종류
- 입찰방법
- 소재지및내역
- 비고
- 감정평가액
- 최저매각가격
- 담당계
- 매각기일
- 유찰내역

할일

데이터뱅크 구축
- modeling
  - 대법원, onbid, KDIC 데이터 정리
  - 서비스 로직 검토 및 entity 개선
- database
  - entity 및 테이블 쿼리 작성
  - 데이터 라이프사이클 및 처리 방법에 대한 정책 정리
- crawling & batch
  - entity model (java class 로 관리할 것인지?)
  - 배치 구현 방법 (jenkins, github action, next.js buildtime crawling)
    크롤링을 어느 시점에 할 것인지에 대한 고민이 필요하다. 보통 경매 물건 상태는 공시[→유찰]→매각 의 순서를 따른다. 라이프 사이클의 어느 단계까지 데이터를 유지할 지, 어떤 주기로 어떤 시각에 크롤링을 할 지 고려가 필요하다. jenkins 등의 배치를 사용한다면 크롤링의 주기와 시각에 유연하게 대응할 수 있다. 데이터를 적재한다면 중복 데이터의 생략에 대한 고려가 필요하다. 데이터베이스를 누적하지 않고 next.js 등의 배포 시점에 크롤링을하여 배포시간 단위로 db 를 유지하는 방법도 있다. 이 때에는 배치의 실행 시간과 데이터의 시간 등에 대한 검토가 필요할 것이다.
서비스
- map : 일단 naver 지도를 사용하면 어떨지
- frontend (react, next.js) : FE 프레임워크를 학습하여 실제로 적용. 지도의 확대/축소에서 실시간으로 fetch 하며 발생할 수 있는 이벤트/성능 이슈를 경험할 수 있음
- backend (spring) : 지도의 이동 확대/축소에 대응하는 fetch API 설계 및 구현

Recommend Projects