TIL - 20250905

0905 Full-Stack: 인증 기반 데이터 조회 및 API 리팩토링

---

✅ 1. 백엔드(BE): 인증 상태에 따른 데이터 필터링

• 기존에는 모든 사용자에게 동일한 이벤트 목록을 보여주었지만, 이제는 로그인한 사용자 본인이 작성한 게시물만 볼 수 있도록 API의 데이터 조회 로직을 수정했습니다.

➕ 주요 개념

1. Repository 쿼리 수정:

   • 서비스 계층(Service Layer)은 클라이언트로부터 전달받은 사용자 ID를 Repository 계층으로 넘깁니다.
   • 기존의 "모든 이벤트 조회" 쿼리를 "특정 userId를 가진 이벤트만 조회"하도록 수정합니다.
   • 이를 통해 데이터베이스 레벨에서부터 데이터가 필터링되므로, 애플리케이션 레벨에서 불필요한 데이터를 처리할 필요가 없어 효율적입니다.

2. API의 역할 변화:

   • GET /api/events 엔드포인트는 이제 "전체 이벤트 목록"이 아닌, "나의 이벤트 목록"을 반환하는 API로 역할이 명확해졌습니다. 이는 RESTful 원칙에 따라, 동일한 URL이라도 사용자의 인증 상태에 따라 다른 결과를 보여주는 좋은 예시입니다.

---

✅ 2. 프론트엔드(FE): 인증이 필요한 API 호출 처리

• 백엔드 API가 이제 인증된 사용자 정보(JWT)를 요구하게 되었으므로, 프론트엔드의 데이터 요청 로직도 이에 맞춰 수정해야 합니다.

➕ 주요 개념

1. 인증 토큰 포함 요청:

   • 이벤트 목록을 조회하는 loader 함수나 useEffect 내의 fetch 요청 시, 브라우저 저장소(e.g., localStorage)에서 저장해 둔 JWT를 꺼내옵니다.
   • 꺼내온 토큰을 HTTP 요청의 Authorization 헤더에 Bearer 스킴과 함께 포함하여 전송합니다.
   • 예시: headers: { 'Authorization': 'Bearer ' + token }

2. 토큰 부재 시 예외 처리:

   • 만약 브라우저에 토큰이 저장되어 있지 않은 경우(로그인하지 않은 상태), API를 호출하는 것 자체가 의미가 없으므로 요청을 보내지 않거나, 접근을 차단하고 로그인 페이지로 리다이렉트시키는 로직을 추가합니다.

---

✅ 3. 프론트엔드(FE): API 호출 로직 리팩토링

• 애플리케이션 곳곳에 흩어져 있던 fetch 코드는 중복이 많고 유지보수가 어렵습니다. 이를 개선하기 위해 API 호출 로직을 중앙에서 관리하도록 리팩토링했습니다.

➕ 주요 개념

1. API 유틸리티 함수 생성:

   • 별도의 파일(api.js)을 만들어, API 요청을 보내는 공통 함수를 작성합니다.
   • 이 함수는 URL, 메서드, 본문(body), 헤더 등을 인자로 받아 fetch 요청을 실행하고, 응답을 처리(e.g., JSON 파싱, 에러 처리)한 후 결과를 반환합니다.

2. 인증 토큰 자동 주입:

   • 리팩토링된 API 유틸리티 함수 내부에, 인증 토큰을 자동으로 헤더에 포함시키는 로직을 추가합니다.
   • 이제 각 컴포넌트나 loader에서는 API를 호출할 때마다 토큰을 직접 꺼내서 헤더에 넣는 코드를 반복해서 작성할 필요가 없습니다. 공통 함수를 호출하기만 하면, 함수 내부에서 토큰 존재 여부를 확인하고 알아서 헤더를 설정해줍니다.

3. 코드의 가독성 및 유지보수성 향상:

   • API 서버의 주소가 변경되거나, 모든 요청에 공통적으로 추가해야 할 헤더가 생기는 등의 변경사항이 발생했을 때, 이제 API 유틸리티 파일 하나만 수정하면 되므로 유지보수성이 크게 향상됩니다.

---

📌 요약

• 백엔드는 "나의 데이터"만 조회하도록 DB 쿼리 레벨에서 데이터를 필터링하는 로직을 추가했습니다.
• 프론트엔드는 인증이 필요한 모든 API 요청에 JWT를 Authorization 헤더에 담아 보내도록 수정했습니다.
• 반복적인 fetch 코드를 인증 토큰을 자동으로 주입하는 중앙화된 API 유틸리티 함수로 리팩토링하여, 코드의 중복을 제거하고 가독성과 유지보수성을 효과적으로 개선했습니다.