어떤 것이 궁금한지 Next.js에서 미들웨어를 사용하여 서버 측에서 페이지 접근을 막는 것이 좋을지, 클라이언트 컴포넌트를 사용하여 클라이언트 측에서 페이지 접근을 막는 것이 좋을지 고민된다. 왜 궁금한지 (상황) 서버와 클라이언트 모두 구현 가능하지만, 최선의 방법을 선택하기 위해 각 접근 방식의 장단점을 비교하고 싶다. 미들웨어 사용 장점 보안 강화: 서버에서 직접 관리하므로 클라이언트가 우회하기 어렵다. 중앙 집중 관리: 모든 접근 제어 로직을 한곳에서 관리할 수 있어 유지보수와 일관성이 용이하다. 단점 복잡성 증가: 미들웨어 설정 및 관리가 까다로울 수 있다. 서버 부하: 모든 요청에 대해 미들웨어가 실행되어 서버..

글을 작성하게 된 이유현재 하고 있는 프로젝트는 Next.js와 TypeScript를 사용한 프로젝트다. 그러던 와중에 SSR의 개념에 대해서 얘기가 나왔다.팀원 의견 : getserversideprops 를 사용해야 SSR이다. 내 의견 : Next.js 자체로 SSR이 지원되니까 SSR을 하고 있는 것이다.CSR vs SSRCSR과 SSR에 대해서는 해당 POST에 정리해두었다. 넥스트 공식 홈페이지에서 설명https://nextjs.org/docs/basic-features/pagesNext.js는 기본으로는 정적 페이지를 생성해주는 프레임워크이다.SSR은 개발자의 선택사항으로 정하면 된다.hydrationPre-Rendering된 웹 페이지를 클라이언트에게 먼저 보내고, 번들링 된 자바스크립트 ..
CSR : Client Side Rendering 클라이언트 측의 브라우저가 JS파일을 다운로드하고 직접 실행하여 렌더링을 하는 것을 말함 인터넷이 느리거나 사용자가 JS를 비활성한다면 아무것도 나오지 않을 수 있다. 앵귤러, 뷰, 리액트 등 쉽게 말해서 클라이언트 측에서 다하는 것을 말함 서버에서 전체 페이지를 다시 읽어 오고 필요한 부분만 받아오기에 빠른 인터렉션이 가능하다. 문제점 사용자가 첫화면을 보기까지의 시간이 좀 걸린다. 구글 네이버와 같은 검색엔진이 해당 페이지를 빈 페이지로 인식하여 검색엔진이 인식을 못한다. 클라이언트 측에서 사용자의 정보를 쿠키에 저장하기에 보안상의 문제가 발생한다. SSR에서는 서버측에서 세션으로 관리한다. SSR : Server Side Rendering UI를 서..
- HTTP
- SSG
- Typescript
- 웹 접근성
- 성능최적화
- s3
- 브라우저
- Proxy
- toast
- 프론트엔드
- server
- 실용주의 프로그래머
- styled component
- SSR
- lazyloading
- IP
- 도메인
- Next
- base64
- https
- Next.js
- CSR
- 선언적 프로그래밍
- 노션
- editor
- Section
- React
- 철학
- NextJS
- 궁금증
- 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 |