<aside> ❗ Redux Toolkit이 아니라 React Query를 쓴 이유가 무엇인가요?
</aside>
Redux Toolkit에서 제공해주는 쿼리도 사실 React Query와 거의 동일한 기능을 제공한다고 알고 있으면 좋을 것 같다. (API 호출 값을 캐싱한다거나 키 값을 캐싱한 것을 다른 컴포넌트에서 재활용할 수 있다던가)
동일한 기능을 React Query나 Redux Toolkit이 가지고 있다 하더라도 Redux에 대한 코드를 사용하지 않기 때문에 쓸 필요가 없는 것. 그리고 .. 되었을 때 파일 사이즈도 경량화될 것
<aside> ❗ JWT에 Refresh Token이 왜 필요할까요?
</aside>
Refresh Token을 통해 몇초 동안의 valid time을 주면 탈취되었다 하더라도 시스템에 접근할 수 있는 시간 자체가 줄어든다. 너무 길게 하면 오버헤드가 적지만 탈취했을 때 위험성이 커지고, 짧게 하면 오버헤드가 크다.
<aside> ❗ 프론트엔드 쪽에 API 호출할 때 CORS 헤더를 setting 했는데 의도가 있나요? 서버 단에서는 CORS에 대한 처리를 한게 무엇이 있을까요?
</aside>
프론트엔드에서 백엔드를 호출할 때 여러가지 API .. 를 쓰는데 일반적으로 이미지나 CSS를 가져올 때는 문제가 없다. (서버한테 어떠한 조작도 가해지지 않음) 그러나 Post라거나 Push, Delete 같은 것들은 클라이언트가 서버의 상태를 바꾸는 것이므로 그것을 제압하기 위해서 SOP라 하는 정책이 적용된 것. 그러면 브라우저가 의도대로 서버한테 호출하는 것인지 확인이 필요하고, 서버한테는제압하는 것이 필요하다.
프론트엔드 헤더에 들어간 값들은 클라이언트(브라우저)에서 서버에 알려주는게 아니라 서버가 브라우저 한테 이것만 허용해야 한다고 알려주는 값이라 보면 될 것 같다.
<aside> ❗ return 할 때 Status Code가 다를 수 있는데 그에 대한 처리가 없다는 것을 감안했으면 좋겠다.
</aside>
(상황에 따른 에러 처리는 추후에 협의해서 추가할 예정)
<aside> ❗
Lambda와 이미지 프로세싱을 어떻게 연결할 것인지에 대한 전략이 있는가?
</aside>
S3 앞단에 Cloud Front가 붙어 있는가? → O
업로드할 때 트리거가 발생 하면 S3가 아니라 Cloud Front에 hook을 연결시키는 것으로 알고있다.
<aside> ❗ 컨트롤러 레벨에서 공통 Response를 사용하지 않고 서비스에서 공통 Response로 매핑해서 반환해주고 있는데 이에 대한 이유가 있을까요?
</aside>
질문한 의도는 서비스에서는 반환하고자 하는 ..만 반환하고 컨트롤러에서 공통된 dto에서 매핑하면 되지 않을까 하는 생각이 들었다. 왜냐하면 컨트롤러와 서비스 중간에 새로운 서비스가 있을 수 있다. (그 서비스는 기존에 만든 서비스와 조합할 수 있다.) 이 경우에 만약에 서비스에서 공통 dto에서 묶어서 반환해주게 되면 demapping을 해야 될 것. (mapping을 떼야 한다는 뜻) 그래서 번거롭지 않을까 하는 생각이 든다.
<aside> ❗ if else문이 굉장히 많은데 그게 절차지향적으로 프로그래밍 했다는 의미라서 로직 분기 기준을 서비스에 사용하지 않고 컨트롤러나 프론트엔드에 전가하는 방법이 있다 라는 것을 말씀드리고 싶었다.
</aside>
부가 설명:
admin에 대한 접근과 admin이 아닌 고객에 대한 접근을 if문으로 나눴는데 그것을 API로 나누는 것이 더 좋다고 생각한다. API가 두 개로 나뉘게 되면 Spring Security에 의해 admin API는 admin만 접근할 수 있도록 컨트롤 제어가 가능하다. 그런데 지금 서비스단에 admin 로직과 일반 로직이 다 들어가있으면 API 호출할 때 권한 제어가 힘들다. 그러므로 컨트롤러 레벨에서 API를 쪼개는 것이 어떨까?