🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 목적: 라이브러리 선택에 필요한 커뮤니티 활성도·유지보수 상태 질적 정보 확보.
- 수집원:
GitHub GraphQL API, GitLab GraphQL API.
- 지표: Stars / Forks / Commits / 기여자 수 등.
- 핵심 전략: 컴포넌트별 중요도·인기도 점수화 → 점수 높을수록 자주 갱신하는 차등 수집.
1왜 차등 수집인가
수집 대상 컴포넌트는 많지만 크롤링 자원(API rate limit, 시간)은 한정된다. 모든 컴포넌트를 동일 주기로 갱신하면 인기 없는 컴포넌트에도 자원이 똑같이 들어가 비효율이다. 그래서 인기도 점수로 우선순위를 매겨 갱신 주기를 차등화했다.
2수집 모듈
- GitHub·GitLab의 GraphQL API로 저장소별 Stars / Forks / Commits / 기여자 수 등을 조회.
- GraphQL을 쓰면 필요한 필드만 골라 한 번에 가져올 수 있어 호출 효율이 좋다.
- 수집한 지표를 컴포넌트 메타데이터로 저장.
3점수화 & 차등 스케줄
- 수집된 활성도 지표(Stars·Forks·Commits·기여자 등)를 합산/가중해 중요도·인기도 점수 산출
- 점수 구간별로 갱신 주기 결정 (점수 높음 → 짧은 주기, 낮음 → 긴 주기)
- 스케줄러가 주기에 맞춰 재수집 큐를 구성하고 수집 모듈 호출
- 인기 컴포넌트 정보의 최신성을 우선 보장
결과: 풍부한 라이브러리 정보 제공 + 한정 크롤링 자원의 효율적 사용 + 핵심 데이터 최신성 유지.
4온보딩 포인트
- 활성도 지표는 소스 저장소 → GraphQL 수집 → 점수 → 차등 스케줄 흐름으로 처리한다.
- "전부 같은 주기"는 자원 낭비. 가치(인기도) 기준 우선순위가 기본 원칙.
- GraphQL은 필드 선택이 가능하므로 rate limit 절약에 유리.
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/component-popularity-scoring.html)은 내부 식별자(테이블명·코드네임·호스트명 등)를 제거하고 문제·접근·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용이며 내부 식별자를 남길 수 있다.
🕷 라이브러리 크롤러 시리즈 ② — ① 멀티 언어 크롤러 구축 · ② 인기도 차등 수집 · ③ 크롤러 현대화