API 폴더 관리 방식

[dkslel1225]

1️⃣ "최상단 api 폴더에 따로 관리"

장점
✅ api 경로와 책임이 명확 → 공통 관리 용이
✅ api layer 에 대한 일관성 확보 가능 (ex: 공통 fetch wrapper 사용 등)
✅ 서버 API 구조와 client 구조가 분리 → 덜 꼬임

단점
❌ feature 쪽에서 보면 의존 경로가 길어짐
❌ feature 에서 context 한 번 더 타야 함

언제 적합?
→ API 구조가 안정화되어 있고, 여러 feature 가 동일 api 를 공통으로 쓸 때
→ 공통 에러처리, auth header 등 한 번에 처리할 때

---

2️⃣ "완전히 colocation 으로 feature 내부에 관리"

장점
✅ feature + api 호출 함수가 한 눈에 보임
✅ 해당 feature 만 수정/리팩토링 시 local reasoning 쉬움
✅ feature 단위로 팀 개발 → 폴더 나누기 용이

단점
❌ api 중복 정의될 가능성 있음 (같은 api 를 여러 feature 에서 따로 구현)
❌ 공통 fetch wrapper 같은 거 적용 힘듦 → 점점 중구난방 됨

언제 적합?
→ 빠르게 프로토타이핑할 때
→ feature 단위 완전 분리 개발할 때 (ex: micro-frontend 느낌으로)
→ feature 단위 lazy load 를 고려할 때

---

내 개인적인 추천 (현재 colocation 쓰고 있다면)

혼합 전략

/api-client (최상단)
  - common fetch wrapper
  - interceptors
  - auth, error handling

/features/Todo
  - api.ts (실제 feature 에서 호출할 함수)
  - component.tsx
  - index.ts

설명

• 실제 axios 호출이나 fetch 는 api-client 에서 wrapper 만들어두고
• feature 별 api.ts 에서 wrapper 사용해서 호출 (endpoint, body 만 넘김)

---

결론

• 만약 지금 colocation 으로 잘 정리중이고 → feature 별 api 가 거의 다 다르다면
  👉 그냥 feature 내부에 api.ts 관리도 괜찮아

• 근데 점점 공통 호출이 많아지고 → 에러 핸들링, 토큰 갱신 같은 걸 하게 되면
  👉 최상단 api-client 는 따로 만들어두는게 좋아

---

혹시 지금 사용하는 라이브러리 뭐야?
예: axios? fetch? tanstack query?

쓰는 거 알려주면 → 지금 폴더 구조랑 맞는 구체적인 예시 하나 바로 짜서 보여줄게 🚀
원해?

[LeeCh0129]

axios 인스턴스나 인터셉터같은 코드만 공통 api에 두고 나머지는 colocation 방식으로 하는게 좋다고 생각합니다.

[yuj2n]

혼합해서 중복 정의될 가능성이 있는 api만 따로 빼면 좋을 것 같습니당

[Insung-Jo]

저도 찬호님처럼 공통적인 부분만 빼고 나머지는 colocation 방식이 좋은 거 같습니다.

[Insung-Jo]

결정되면 axios 파일이랑 어제 멘토님 말씀 참고해서 작업 중에 수정에서 올리도록 하겠습니당