`authGuardedFetchers`를 기존 fetcher와 통합

[giwan-dev]

triple-frontend/packages/fetcher/src/auth-guarded-methods.ts

Line 9 in 9382d73

export const authGuardedFetchers = {

authGuardedFetchers는 로그인 실패시 재시도 로직을 내장한 fetch 함수 모음입니다. 그래서 인증이 필요없는 API도 사용할 수 있는데, 이름에 "가드"라는 의미가 들어가 인증이 필요할 때만 쓸 수 있다는 인상을 줍니다. 따라서 원래의 역할을 더 잘 설명하는 이름으로 바꿔야 합니다.

다만, 로그인 여부를 체크하기 때문에 타입 정의에 무조건 "NEED_LOGIN"이 포함되는 건 개발자가 부담스럽게 느낄 수 있습니다. 인증이 필요 없더라도 "NEED_LOGIN"을 예외처리 해줘야하기 때문입니다. 그냥 fetcher를 쓰면 쉽게 넘어갈 수 있는데, 이걸 쓰면 일어나지도 않을 에러 때문에 코드를 3줄 더 써야하는 것이죠.

하지만 API가 인증을 검사하는지 않는지는 프론트엔드 소스코드의 범위를 넘어서는 일이고, 방어적으로 생각하면 무조건 예외가 있어야 합니다.

@titicacadev/frontend 둘 중 어떤 방식으로 가는 게 좋을까요?

1. 인증이 필요한 API와 필요없는 API를 fetch하는 함수를 각각 사용하는 컨벤션

• 장점: 개발자가 코드를 쉽게 작성. 간결한 코드 작성 가능.
• 단점: 방어적이지 않은 코드. 백엔드 API가 변경되었을 때 프론트 코드가 바뀌어야 함.

2. 인증이 필요하든 안 하든 같은 fetcher 함수를 사용하고, "NEED_LOGIN"을 예외 처리하는 컨벤션

• 장점: 방어적인 코드. 백엔드 API와 상관없이 하나의 fetcher 사용 가능
• 단점: 일일히 예외처리가 필요함. 일어나지도 않을 에러를 관리해야함.

[dddeok]

1, 2 너무 명확한 장단점이 존재하는거 같네요 😢
개인적으로 2번이라 생각합니다. 예외처리적인 단점부분 보다는 백엔드의 의존성을 낮추는면에서 확실히 더 안전하다고 판단되네요

[pgs787]

저도 2번입니다!
1번의 방어적이지 않은 코드. 백엔드 API가 변경되었을 때 프론트 코드가 바뀌어야 함.
이 부분이 안정적이지 않고 수동적인 부분이 크게 보이네요! 🤔

[zhsks528]

저도 2번입니다!
안정성과 의존성 측면에서 좋아보입니다 👍

[giwan-dev]

이름 개선 대신에 기존 fetcher로 통합하겠습니다.