티스토리 뷰
반응형
어떤 것이 궁금한지
Next.js에서 미들웨어를 사용하여 서버 측에서 페이지 접근을 막는 것이 좋을지, 클라이언트 컴포넌트를 사용하여 클라이언트 측에서 페이지 접근을 막는 것이 좋을지 고민된다.
왜 궁금한지 (상황)
서버와 클라이언트 모두 구현 가능하지만, 최선의 방법을 선택하기 위해 각 접근 방식의 장단점을 비교하고 싶다.
미들웨어 사용
장점
- 보안 강화: 서버에서 직접 관리하므로 클라이언트가 우회하기 어렵다.
- 중앙 집중 관리: 모든 접근 제어 로직을 한곳에서 관리할 수 있어 유지보수와 일관성이 용이하다.
- 복잡성 증가: 미들웨어 설정 및 관리가 까다로울 수 있다.
- 서버 부하: 모든 요청에 대해 미들웨어가 실행되어 서버에 부담이 될 수 있다.
클라이언트에서 구현
장점
- 유연성: 클라이언트 측에서 동적으로 접근 제어를 수행해 사용자의 경험을 향상시킬 수 있다.
- 간단한 구현: 상태 관리 및 조건부 렌더링을 활용해 접근 제어를 쉽게 구현할 수 있다.
- 보안 취약성: 클라이언트 측 접근 제어는 우회될 가능성이 있다.
- 초기 로딩 시간 증가: 클라이언트가 모든 로직을 처리하므로 초기 로딩 시간이 길어질 수 있다.
결론
- 클라이언트에서 구현: 구현이 간단하거나 사용자 경험이 중요하거나, 서버 부하를 최소화하려는 경우 적합하다.
- 미들웨어에서 구현: 보안이 중요하거나 접근 제어 로직을 한곳에서 관리하고 싶은 경우 적합하다.
배운 것 / 다음 목표
보안의 중요성과 사용자 경험의 비중을 상황에 따라 잘 판단할 것.
반응형
'개발 > 개발일지' 카테고리의 다른 글
SSR인 페이지에서도 lazy loading이 필요할까? (1) | 2024.12.05 |
---|---|
모든 컴포넌트를 lazy loading한다면? (0) | 2024.12.04 |
현업에서 웹 접근성 얼마나 지키면서 일하시나요? (0) | 2024.12.02 |
Prop style did not match. (feat. Next.js, fullcalendar, SSR) (0) | 2022.11.17 |
Editor 완성!! feat.버그 (0) | 2022.05.10 |
TAG
- 실용주의 프로그래머
- Typescript
- toast
- 선언적 프로그래밍
- 도메인
- 노션
- CSR
- React
- IP
- HTTP
- NextJS
- Section
- Proxy
- s3
- 웹 접근성
- 브라우저
- styled component
- Next.js
- server
- 성능최적화
- https
- 궁금증
- base64
- Next
- 프론트엔드
- editor
- 철학
- SSR
- lazyloading
- SSG
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
글 보관함
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
반응형