lib

api

요청 제한과 중복 생성 방지를 위해
article과 user api에 에러 핸들링을 추가했다.

article에선 클로저를 활용해 throttling으로
중복 요청을 방지했다.

처음에는 맨 처음에 전송한 데이터로 재요청이 가게 했는데,
클로저를 쓰고 있으니 큐를 사용해서 가장 최근의 값을 빼올까 하다가
그냥 에러를 내는게 더 직관적일 것 같아 바로 에러를 내게 만들었다

types

Author 관련 타입이 여러 곳에서 중복 정의되고 있어서
하나의 중앙화된 타입에서 관리하도록 수정했다.

결합도가 조금 높아지긴 했지만..
유지보수성 측면에서는 더 나은 선택이라고 판단했다.

또한 기존에 article에서
interface로 여러 props를 정의해서 사용하던 부분을
type으로 통일해서 사용했다.

type과 interface 선택 기준은 다음과 같다.

• Type
  • 교집합(intersection)이나 복잡한 타입 조작이 필요할 때
• Interface
  • 객체의 모양을 정의할 때
  • 동일한 이름으로 extends해서 사용해야될 때

맺음말

이 디렉토리에선 타입 추가한거 말고는 한 게 별로 없는 것 같다.
에러 핸들링이 반일 것 같은데
어려워서 조금 더 고민해봐야될 것 같다

그리고 하다가 깨달은건데

1. 원래 기존 레포는 아티클이 pid 형식이었는데
   이 때 pid가 난수를 생성하는게 아니라
   title의 값을 그대로 따와서 사용했다.
2. 그래서 제목에 영어 말고는 입력할 수가 없어서
   내가 아티클의 엔드포인트를 인코딩한 slug 형태로 바꿨다.
3. 근데 이렇게 하니까
   중복된 타이틀을 가진 아티클은 생성할 수 없는 문제가 발생했다.
4. 그래서 title은 순수하게 제목으로만 사용하고 pid를 난수로 생성해서 엔드포인트 구분값에 쓰거나,
   id/slug 형태로 둘 다 사용하게 변경해야 될 것 같다.

features 디렉토리를 볼 때 그냥 흐름도를 그려보는건 어떠실련지...