softcon#

소프트콘은 스트리머의 데이터를 분석하는 사이트로 제가 구현하는 기능의 카테고리 변경 내역을 가지고 있습니다.

하지만 이 사이트의 경우 많은 스트리머의 뷰어쉽에 초점을 맞추고 있으며, 제가 구현하려는 알람 기능과 스트리머 채팅 추적의 기능을 가지고 있지 않았습니다.

익스텐션#

치즈나우나 콘치즈처럼 익스텐션 기반 서비스들은 로컬 스토리지에 저장하는 형식으로서 서비스 워커의 생명 주기가 크롬과 같기 때문에 스마트폰으로 알림을 받을 수 없다고 생각했습니다.

이는 방송을 보고 있지 않은 사람들을 대상으로 하는 것이 아닌, 다른 방송을 보고 있는 도중 알람을 받을 수 있는 프로그램이라고 생각했습니다.

치지직 타임라인#

치지직 타임라인은 오픈 소스로서 제가 구현하고자 하는 내용과 가장 비슷한 사이트입니다.
카테고리 변경 내역도 존재하며, 해당 방송과 다시보기도 연결 할 수 있습니다.

하지만 이 서비스 또한 특정 방송인이 어떤 카테고리를 했느냐가 아닌 키워드 기반의 채팅 수집이기 때문에 제가 지향하고자 하는 방향과 다르다고 생각했습니다.

공식 API#

공식 API는 사이트가 제시하는 가장 최우선 시 되는 방법입니다.

법적 문제 없이 안전한 호출이 가능하기 때문에 공식API를 사용하려 했으나,
치지직의 공식 API는 로그인 리다렉션이 필요하여 클라이언트에서의 사용에 초점을 맞추고 있습니다.
또한 다른 사람의 채널을 검사하는 기능이 없고 전체 채널과 자신의 채널만 검사할 수 있습니다.

얼마 없는 채널의 카테고리 변경 추적을 하기 위해 채널을 전부 불러와 검사해야됐으며,
타인의 채팅 로그를 수집하기 위해 이 방법을 포기하게 되었습니다.

Scraping#

그 다음으론 API호출보다 스크래핑으로 데이터를 가져오는건 어떨까 생각했습니다
하지만 API보다 웹 UI가 변경 가능성이 높고, 데이터를 가져오는 비용이 JSON형식보다 많다고 하여 포기하게 됐습니다.

비공식 API 라이브러리#

비공식 라이브러리 kimcore/Chzzk은 제가 구현하려고 하는 기능의 대부분을 가지고 있습니다.
하지만 치지직의 API 주소가 바뀔 경우 바로 대응이 안될 수 있고 학습의 목적과 맞지 않다고 생각하여 이 라이브러리의 사용을 피했습니다.

Reverse-engineered API#

그래서 저는 직접 네트워크 요청을 분석하여 공개 API를 요청하는 방법을 선택했습니다.

이는 법적문제 위험이 있지만 관리하는 채널을 10개 미만으로 줄여 요청 수를 줄였고,
비영리적으로 운영하는 사이트라고 생각하여 괜찮을거라 생각했지만 문제가 될 여지가 많습니다.

하지만 치지직의 비공식 API를 이용하여 운영하는 서비스 중 치지직 랜덤 추첨기는 많은 방송에서 공공연하게 쓰이고 있었기 때문에 저도 이 방법을 선택하게 되었습니다.

PollingScheduler#

1
#scheduleNext(timerKey, interval, fn) {
2
  if (this.#timers.has(timerKey)) clearTimeout(this.#timers.get(timerKey));
3
  const timerId = setTimeout(fn, interval);
4
  this.#timers.set(timerKey, timerId);
5
}

1
const timerKey = `${type}_${channelId}`;
2
this.#scheduleNext(timerKey, nextInterval, scheduleMethod.bind(this, channelId));

타이머를 Map객체로 만들어 해당 채널의 아이디와 사용할 메서드명을 조합해 키를 만들어 각각의 풀링을 관리했습니다.
자기 자신을 호출하기 위해 bind를 걸어주고, 두번째 인자로 채널 아이디를 넘겨 채널마다 풀링을 수행할 수 있었습니다.

PollingProcessor#

1
const { isLive, closeDate } = await this.#liveLogService.processLiveLog(channelId);
2
if (isLive) {
3
    return PollingPolicy.getOpenInterval();
4
}
5
return PollingPolicy.getCloseInterval(closeDate);

변경 이력 추적의 기준은 LiveLog 서비스에서 진행하게 됩니다.
서비스는 isLive와 closeDate를 주어 다음 풀링 주기를 판단할 수 있게 합니다.
풀링 주기 판별은 PollingPolicy에서 하니 방송이 켜졌을 때와 꺼졌을 때의 기준만 넘겨줬습니다.

비디오 매칭또한 마찬가지로 비디오 매칭의 결과match를 받아 기준만 넘겨주도록 하였습니다.

PollingPolicy#

1
static WAIT_LIVE_STAND = 8 * 60 * 60 * 1000;
2
//...
3
static getCloseInterval(closeDate) {
4
  const time = Date.now() - new Date(closeDate).getTime();
5
  if (PollingPolicy.RESTART_STAND < time && time < PollingPolicy.WAIT_LIVE_STAND) {
6
    return { interval: PollingPolicy.LIVE_CLOSE_INTERVAL };
7
  }
8
  return { interval: PollingPolicy.LIVE_CLOSE_INTERVAL };
9
}

풀링의 주기는 스트리머의 방송 종료로 기준을 잡습니다.
치지직의 비공식 API를 사용하기 때문에 API호출을 최소화 해야됐기 때문에
스트리머의 방송 종료를 기준으로 평균 수면시간인 8시간 동안은 5분에 한번씩 풀링을 요청하도록 구현하였습니다.

방송이 잠깐 꺼지거나, 치지직 서버가 다운될 경우를 생각하여 종료 후 10분간은 1분에 한번씩(기본) 풀링을 요청하였습니다.

LiveLogService#

1
async initializeCache(channelId) {
2
  const { channelPK } = await this.#channelService.getChannelPK(channelId);
3
  const logModel = await this.#liveLogRepository.findLastLiveLog({ channelPK });
4
  this.#liveLogCache.set(channelId, logModel.toCache());
5
}

프로그램 시작 시 캐시를 세팅하여 최근 방송 중 마지막 값(close_date가 NULL인지?)을 가지고 와서 캐시를 초기화 합니다.
캐시를 설정하여 DB조회를 줄여보려고 하였습니다.

1
const liveLogDto = await this.getLiveLogFromApi(channelId);
2
const logData = liveLogDto.toProcessLiveLogData();  //DTO 사용
3

4
const { liveTitle, categoryId, categoryType, isLive, closeDate } = logData;
5
const cachedLog = this.#liveLogCache.get(channelId);
6
const sessionId = cachedLog ? cachedLog.liveSessionId : generateSessionId();
7

8
// 앞서 말한 불필요한 조회
9
const { categoryPK } = await this.#categoryService.getOrCreateCategoryPK({
10
    categoryId,
11
    categoryType,
12
});
13

14
const categoryChanged = categoryPK !== cachedLog?.categoryPK;
15
const titleChanged = liveTitle !== cachedLog?.liveTitle;

카테고리와 제목 변경의 기준은 processLiveLog에서 합니다.
API를 받아온 후, 캐시와 비교합니다.

변경 내용이 있을 때, 방송이 켜져있다면 저장, 방송이 꺼져있다면 방송 종료 로직을 실행합니다.
저장할 때에는 한 방송임을 표시하기위해 session 값을 만들어 같이 추가해줍니다.

방송 종료 로직#

1
if (!isLive && cachedLog) {
2
  const { liveSessionId } = cachedLog;
3
  await this.#liveLogRepository.updateSessionCloseDate({
4
    liveSessionId,
5
    closeDate,
6
  });
7
  this.#liveLogCache.set(channelId, null);
8
  return { isLive, closeDate };
9
}

방송이 종료된 이후에는 계속해서 CLOSE 가 들어 오기 때문에 캐시가 있는지 확인하고
있다면 해당 캐시의 session값으로 DB를 업데이트 한 후 캐시를 비워줍니다.

VideoMatchingService#

1
const matchedTitle = live_title === videoTitle;
2
const matchedDate =
3
  new Date(publishDate).getTime() - new Date(close_date).getTime() <
4
  VideoMatchingService.VIEDO_MATCH_STAND;

비디오 매칭의 기준은 최근 다시보기의 제목이 같고, 다시보기의 생성 날짜가 방송 종료 후 8시간 이내인지 검사합니다.
지금 쓰면서 보니 8시간 이내인지 확인하는 것보다 비디오의 총 시간으로 계산하는게 좋아보입니다.

API DTO#

1
  constructor(apiContent) {
2
    if (!apiContent) throw new Error("Invalid API content");
3
    //...
4
    this.#channelId = apiContent.channel?.channelId ?? null;
5
    this.#status = apiContent.status ?? null;
6
  }

해당 API DTO를 정의함으로서 실제 치지직의 깊은 데이터 구조(apiContent.channel.channelId)를 평면화하여 LiveLog Model을 일관적으로 생성할 수 있었습니다. 추후 치지직 API의 응답 형식이 바뀌어도 API DTO 만 수정하면 되니 결합도가 낮아집니다.

HashRouter#

1
navigate(path) {
2
  const hashPath = path.startsWith("#") ? path : "#" + path;
3
  window.location.hash = hashPath;
4
}

라우터는 Hash기반의 라우터를 사용했습니다.
SPA를 구현하려면 어느 링크에 들어가도 index.html을 반환했어야 됐는데, 이 과정은 서버에서 진행됩니다.
하지만 정적 페이지인 Github Pages에서는 그 과정이 불가능했기 때문에 404 page에서 처리하는 등 본래의 의도와 맞지 않는 방법으로 해결해야 됐습니다.
저는 클라이언트도 Github Pages가 아닌 다른 페이지에 배포하려고 생각 중이여서 해쉬라우터로 개발을 진행하였습니다.

Event Bubbling#

1
this.$wrapper.addEventListener("click", () => {
2
    this.$wrapper.dispatchEvent(
3
      new CustomEvent("navigateCard", {
4
        detail: this.props.channelId,
5
        bubbles: true,
6
      })
7
    );
8
});

1
this.$target.addEventListener("navigateCard", (e) => {
2
    // 해결
3
}

이벤트 버블링을 사용하여 Channel Card의 click이벤트를 App에서 처리할 수 있었습니다.