[TIL] 2024.04.05 인기순 정렬과 스크래핑 데이터 중복처리

1. news 인기순 탭을 만들기 위한 생각 정리

• 레디스 sorted set을 활용한 인기순 정렬
  - 이 방법은 인메모리 기반이기때문에 서버가 꺼지면 저장된 데이터가 사라진다.
    장점은 엄청난 스피드라는 것 하나인데 이 장점을 사용하기 위해 주기적으로 레디스
    스냅샷을 이용해 데이터를 백업하는 등의 방법을 사용하기에는 적합하지 않다고 판단.
• 조회수 기반의 인기순 정렬은 데이터베이스에 저장하여 사용하는 것이 좋을 것 같다.

 

2. 각각의 엔드포인트와 단일 엔드포인트에 대한 핸들링 고민

• nestjs에서 각각의 덴드포인트를 활용할땐 가독성과 모듈화 및 유지보수하는데 장점이 있다
  다만 중복된 코드를 사용해야하고, URL 충돌 가능성이 발생 가능하다는 단점도 존재한다.
• 단일엔드포인트를 적용한다면 코드 중복화와 URL 충돌회피에는 장점이 있을 수 있지만,
  가독성이 감소하고 유지보수가 어려워 질 수 있다. 단, 단일 엔드포인트 적용시 복잡한 상황에서
  유지보수가 어려운거지 프로젝트 규모, 구조에 따라 다르니 깔끔하게 유지 시킬 수 있다면 적용 가능

위 고민에서 한가지 핸들링 방법을 채택해야했는데 가장 이유를 뒷받침 해주었던 근거는

프론트단에서는 단일 엔드포인트 방식을 사용해 동적으로 처리하는게 더 좋다는 의견을 보았다.

 

단일 엔드포인트에 쿼리 파라미터를 사용해 동적으로 처리하면 얻을 수 있는 이점으로는

별도의 엔드포인트를 생성해서 경로가 중복되는 것 보다는 쿼리ㅐ 파라미터로 가져오는 방식이

효율적이라고 생각했기 때문이다.

 

여기서 문제가 생겼다. 단일 엔드포인트로 인기순과 최신순 정렬을 구현하였지만,

첫 요청에만 인기순으로 정렬된 후 그 다음 요청부터는 제대로 먹히지 않았다.

이유는 경로 설정에 있었다.

 

위 부분을 보면 인기순으로 조회를 할때 원래는 'find' 로만 경로를 주었다.

이렇게 하니 서버에 요청을 할 때 find가 파라미터인 id 값으로 인식이 되어

오류를 발생하던 것이였다. 

그래서 find/finds로 경로를 다시 지정해주니 오류가 깔끔하게 처리되었다.

3. 스크래핑 데이터 중복성 처리

• 스크래핑 데이터를 저장할 때 어떻게 중복되지 않게해야될까? 라는 생각을했다.
  해결법은 간단했다. entity에 unique 속성을 줘 중복처리를 하는데 쉽게 적용할 수 있었다.