안녕하세요 동료님! 영상 시청해주셔서 감사합니다. 너무너무 유익했다니.. 🥹 제가 오히려 감사의 말씀을 드리고 싶네요. 영상을 올릴까 말까 고민을 했던 시간이 너무 아깝게 느껴지네요. 차라리 더 빠르게 공개를 할걸 이라는 생각이 들게 만들어주신 동료님께 오히려 감사합니다. 영상을 올리기 전까지도 정말 많은 고민을 했거든요. 앞으로도 재밌고 유익한 영상으로 찾아뵐게요! 다시 한번 영상 시청해주셔서 감사합니다. 그럼 좋은 저녁 되세요~!!!
안녕하세요 동료님. 어머나,, 걱정을 많이 했는데, 이렇게 좋아해주셔서 감사합니다. 🙇🏻♂️ 제가 설명을 잘 했다기 보다 동료님께서 아시는게 많아서 쉽다고 느끼셨던거 같아요. 원래 계획은 없었는데,, 2탄을 한번 제작을 해볼게요. 스포를 하나 하자면 "사이드 프로젝트 나라 여행기"를 지금 찍고 있어서 조금 시간이 걸릴진 모르겠어요. 다른 여행기도 좋은 내용으로 찾아뵐 예정이니 많은 관심 부탁드립니다! 그럼 다시 한번 영상 시청해주셔서 감사합니다. 그럼 좋은 저녁 되세요!
전자상거래는 가장 대표적인 ssr 활용 사례가 아닐까 싶음. seo 장점도 있고 수 많은 트래픽을 csr로만 처리하면 과도한 번들 용량과 느린 렌더링 시간으로 인해 사용자 이탈이 발생하고 그로 인해 매출에 영향이 가장 빠르게 감. csr에서 부드러운 로딩 경험을 위해 스켈레톤 UI도 인기가 많지만 답답한 느낌을 주는 건 매한가지임. 이제 next에서는 "use cache"를 만들고 있던데 지시문이 벌써 3개가 된... ㅜㅜ
안녕하세요 예비 동료님! 만나서 반갑습니다. 너무 이해가 잘된다니... 눙물... 🥹 정말 감동입니다. 개발을 공부하시는 입장이심에도 불구하고 이런 내용을 이해하실수 있는 후니쨩님은 도대체 누구세요.... ~예전의 저였다면 영상 바로 껏을텐데...~ 더 좋은 영상으로 찾아뵐게요! 그럼 좋은 저녁 되세요~~!
안녕하세요 동료님! 영상 시청해주셔서 감사합니다. 그리고 수준 높은 질문 감사합니다! 질문 주신 것처럼 > fetch와 isr방법이외에도 리액트쿼리방법도 있지않나요?? 이 방법도 존재합니다! 앞서 말씀드렸던 fetch의 방식과 동일하게 캐슁을 해볼 수 있고, 옵션으로 조작이 가능하죠. 해당 영상에서 tanstack/react-query까지 다루진 않은 이유는 next의 기본적인 기능에 초점을 두고 싶어서 였어용. 그래서 말씀하신것처럼 react-query를 사용하는 방법은 "fetch의 캐쉬를 이용하는 전략과 동일"합니다! > 하이드레이션을 사용해서하면 서버사이드 환경에서도 사용이가능하고 빠르게 불러올수있구여 이 말씀은 결국 SSR을 한다는 것인데, 이게 ISR과는 차이가 있어용. 말씀주신 방법을 제 나름의 플로우로 표현 하자면, SSR은 1) '/' 요청 2) next 서버에서 필요한 데이터 요청(이때 react-query 사용) 3-1) 요청 완료된 데이터로 HTML을 그림 3-2) react-query의 QueryClient에서 json 응답을 string으로 변환 3-3) 변환한 데이터를 html에 삽입 4) client 사이드 일때 html에서 삽입된 응답을 Hydration 컴포넌트에서 불러와 QueryClient에 데이터 적용 대략적으로 이런 방식일텐데, 대규모 트래픽일때 문제가 되는 부분은 "3-1과 3-2"입니다. 영상에서 잠깐 언급하고 지나갔는데 싱글 스래드에서 CPU 집약적인 작업을 진행하면, 그 뒤에 작업들이 pending이 되요. HTML을 string으로 만들어주는 작업도 대규모 트래픽에서는 꽤 큰 작업이고 react-query에서 데이터 요청을 보내고 받는 그 200ms 내외의 시간 조차 부하로 이어집니다. 그래서 ISR로 바꿔보면 cache-hit일때의 경우는 "3-1"과 "3-2" 작업이 생략이 됩니다. 1) '/' 요청 2) next 서버에서 캐쉬된 페이지가 있는지 찾아봄 3) 만약 유효한 데이터라면 캐쉬된 페이지를 내려줌 (여기에 data는 이미 포함이 되어있음) 신나서 글을 쓰다보니 길어졌네요 ㅠㅠ.. 도움이 되셨으면 좋겠네요. 다시 한번 영상 시청해주셔서 감사합니다 🙇🏻♂️ 그럼 좋은 저녁 되세요!
@@eddie_the_traveler 와.. 정말 너무나 감사합니다!! 다시한번 영상 정주행 하고 내용정리겸 블로그에 작성해야겠습니다. 진짜 다시 한번 너무 감사합니다. 글을 읽었는데 진짜 머리가 번뜩 하고 깨달음이 온것만 같은 기분입니다. 구독박겠습니다 좋은 양질의 컨텐츠 너무나 감사드립니다.
안녕하세요 도라방스님~~ 오랜만에 뵙네요! 허걱.. 이렇게 극찬을 해주시다뇨! 영상을 찍고 공개를 할까말까 고민했던 시간이 바보같이 느껴지게 해주셔서 감사합니다. 항상 제 채널에 관심 가져주셔서 감사해요. 앞으로도 더 좋은 영상으로 찾아뵙겠습니다! 그럼 좋은 저녁되세요!!
안녕하세요 동료님! 저의 영상 관심가져 주셔서 감사합니다! 심지어 너무 좋으시다니 감동입니다 🥰 앞으로 더 좋은 영상으로 찾아뵐 수 있도록 할게용! 🙇🏻♂️ 날씨가 많이 추워졌네요. 항상 건강 유의하시고 행복한 일만 가득하세요! 다시 한번 영상 시청해주셔서 감사합니다.
영상 재밌게 보았습니다 역시 에디님 😊 다만 영상을 보면서 몇가지 궁금한점이 생겼어요! 캐싱을 일정시간동안 해두고 데이터가 있다면 SSR을 통해서 그리는거라고 하셨는데요 만약 30초 이내에 데이터가 바뀌었고 그사이에 유저가 새로고침을 하면 최신 정보가 반영이 안되는건지 궁금합니다 추가로 에디님이 설명하신 두 발식이 햇살리는데 ISR방식에서 revalidate주기로 저장하는것과 fetch에서의 revalidate랑 같은역할을 하는 것 처럼 보이는데 어떤 차이점이 있는건가요?
안녕하세요 버그하우스님! 우와,,, 좋은 질문 주셔서 감사합니다 > 캐싱을 일정시간동안 해두고 데이터가 있다면 SSR을 통해서 그리는거라고 하셨는데요 만약 30초 이내에 데이터가 바뀌었고 그사이에 유저가 새로고침을 하면 최신 정보가 반영이 안되는건지 궁금합니다 네 맞아요. 정말 핵심을 찔러주셨네요. 이게 캐슁의 단점이기도 합니다. 최신화된 데이터를 못보는게 단점이죠. 그래서 캐쉬를 사용하는 상황은 조금 더 많은 상황이 고려되어야 하기도 해요. 말씀해주신 데이터 갱신이 민감한 상황이라면, 캐쉬를 쓰는게 오히려 독이 될 수 도 있어요. > 추가로 에디님이 설명하신 두 발식이 햇살리는데 ISR방식에서 revalidate주기로 저장하는것과 fetch에서의 revalidate랑 같은역할을 하는 것 처럼 보이는데 어떤 차이점이 있는건가요? ISR 방식은 페이지 자체를 캐슁 해놓는 방식이고 fetch는 서버 데이터만 캐쉬처리 하는 방법입니다. 각각의 방식의 가장 큰 차이점은 cache-hit일때 "html을 서버에서 그리냐 안그리냐"의 차이에요. 📌 fetch에서의 cache-hit일때: 1) '/' 요청 2) '/'에 필요한 데이터를 json 호출 2-1) '/'에 필요한 데이터가 캐슁되어 있기 때문에 바로 응답 3) 필요한 데이터를 통해 html을 stringify함 4) 사용자에게 내려줌 📌 ISR일때 cache-hit: 1) '/' 요청 2) '/' 캐쉬된 페이지 있어서 바로 페이지 내려줌 그럼 여기서 하나 궁금증이 드실텐데, html을 stringify를 하는게 그렇게 오래 걸려? 라고 물어보신다면, 아마 대략 200ms 내외 혹은 그것보다 훨씬 빠른 처리 속도일텐데, 이것도 페이지를 어떻게 구성을 하고 있느냐에 따라 달라요. 굉장히 짧은 시간처럼 느껴질 수 있지만 이것도 대규모 트래픽일때는 부하가 됩니다. 왜냐하면 nextjs 프로젝트는 node 서버에서 구동을 하고 있고, node 서버는 싱글 스레드이기 때문에 원래 요청이 처리가 되지 않았다면 다른 요청을 처리할 수가 없어서 pending 이 걸려버려요. 끊임없이 html을 stringify를 해야하는데, 이렇게 html을 조립하는 것도 자칫 부하로 이어질수 있거든용. ㅠㅠㅠ... 그래서 스트래스 테스트를 통해 정말 부하가 걸리는게 맞는지, 요청을 다 수행할 수 있는지를 테스트를 돌려보면서 찾아내고 개선을 해야하는 거 였어요! 오늘도 정말 좋은 질문 남겨주셔서 감사해요 버그하우스님! 그럼 도움이 되셨길 바라면서...! 글을 마쳐보겠습니다. 그럼 좋은 저녁되세요!
안녕하세요 동료님!!! 도움이 되셨다니...! 제가 고민 고민을 몇개월을 했는데... 찍어놓고도 공개를 누를까 말까를 정말 많이 고민했는데...!! 그냥 일찍 공개를 할걸 그랬나봐요 ㅠㅠㅠ. 도움이 되셨다니 오히려 제가 더 감사합니다. 앞으로도 재밌고 유익한 영상으로 찾아뵐게요~~! 다시 한번 영상 시청해주셔서 감사합니다. 🙇🏻♂️ 그럼 좋은 저녁되세요~~~!
어떻게 하면 잘 설명드릴수 있을까... 를 1시간 동안... 고민하며 쓰고 지우기를 계속 반복했네요. 아무래도 실제 데이터를 보고 싶어하시는 거 같아서 관련해서 글을 찾아봤어요: fe-developers.kakaoent.com/2024/240418-optimizing-nextjs-cache/ 저보다 더 훌륭하신 개발자분이 실제 현업 데이터로 공개 + 글을 적어두신게 있어 공유드립니다! 제가 설명드리는 것보다 100배 1000배 더 잘 적어주셨어서, 더 이해가 가실거 같아요! 도움이 되시길 바라면서.. 영상 시청해주셔서 감사합니다!
요즘 서버사이드 랜더링이 새로운 기술? 뭔가로 강조 되고 있는데 ㅎㅎㅎ 우리 같은 옛날 개발자들은 무슨 느낌이냐면 마치 핸드폰 밧데리를 분리해서 따로 충전하게 하면 좋지 않을까요? 이런 느낌임. 원래 웹개발은 그냥.. 서버에서 앞에 아파치나 nginx두고 php,jsp,asp뭐 이런거 써서 대충 html말아가지고 던지는 거였음.
맞아요.. 예전에 비하면 정말 많이 복잡해졌죠.. 그리고 단어도 너무 헷갈리는거 같아요... 애쓰봇 동료님께서 말씀주신건 SSR이고 언잉 동료님께서 말씀주신건 SSR with hydration이라는 명칭이더라구요. 그리고 최신 react, next.js 버전에서는 server component 라고 부릅니다. 이 세개가 비슷해 보이긴 해도 무명 동료님께서 말씀주셨던 것처럼 디테일이 다릅니다. 애쓰봇이 말씀주신 SSR은 MPA(multi page app)고 언잉 동료님께서 말씀주신건 SPA(single page app) 이어서 다르고.. 최신 react, next.js 버전에서의 server component는 SPA + streaming의 개념에서 조금 씩 차이가 있어요. 이 영상에서 하고 싶은 이야기중에 하나는 기술을 쓸때는 "약점과 강점"을 알고 그걸 잘 활용하자! 였어용. 사실 애쓰봇 동료님께서 말씀해주신 것처럼 jsp와 같은 것들로도 훌륭한 프로젝트를 만들어낼 수 있어요. 항상 최신 기술이라고 좋은 면만 있진 않거든요. 많은 분들이 요즘 next.js를 학습을 하시고 많은 프로젝트를 진행중 이신데, 이러한 단점을 모르고 있었다면, 나중에 그걸 극복하기에는 이미 유저들은 다 떠나갔을 거 같아요 ㅠㅠ... :( 다시 한번 영상에 관심 가져주셔서 감사합니다! 더 좋은 영상으로 찾아뵐게요! 그럼 좋은 저녁 되세요~~!
안녕하세요 동료님. 영상 시청해주셔서 감사합니다. 저도 동료님께서 말씀하신 부분에 전적으로 공감이 갑니다. 영상 더보기에서도 말씀드렸던 것처럼 단순 부하 문제로 해당 주제를 말씀드렸던건 아니었어용. 포트폴리오에 적기 좋은 주제이기 때문에 이야기를 나눠봤던거 였어요. 그리고 여러가지 방법들중 가장 빠르고 효과적으로 문제를 해결할 수도 있는 방법이기도 합니다. TTI, FCP, TPS,.. 와 같은 수치들에 최적화 및 공부를 하기 좋은 주제기도 하죠. "개발자에게 기술은 도구로써 취급 되어야 한다." 저는 이 말을 굉장히 좋아해요. 그리고 왜 이런 기술을 사용하셨어요? 라는 질문을 받을때를 가장 좋아해요. 많은 분들이 next.js를 공부하시고 좋다고만 알고 계시지만, 이 서버가 얼마나 쉽게 죽을 수 있는지는 잘 모르시는 분들이 많아 해당 영상을 제작하게 되었습니다 ! 기술의 장점과 단점을 명확하게 알고 있어야 특정 상황에 최선의 기술을 사용한다고 믿거든요. 영상을 이해하기 힘드셨겠지만 그래도 도움이 되셨길 바라면서 글 줄여볼게요. 다시 한번 영상 시청해주셔서 감사합니다! 그럼 좋은 저녁 되세요~!
이거 좋은내용이네요 싱글 스레드는 cpu 집약적인 작업에는 적합하지않죠 그럼 pm2 같은걸로 클러스터 모드로 늘리면 되겠네 해도 되지만 이것도 문제가 생기는게 로드 밸런싱이 적절히 처리가 되지않을수 있고 라우트로 다른 요청이 일어나면 다른 인스턴스로 요청이 전환되어 상태가 유지가 되지않을수도있지요 그래서 언급해주신거처럼 레디스 같은거 붙여서 상태를 공유하는 전략까지 생각해야하는데 ㅎㅎ 여튼 프론트도 빡시네요
server 부하 작업을 이렇게 쉽게 풀어서 영상까지 ㅎㅎ 너무 좋은 영상입니다 감사합니다
수..쉽게 풀었다니 ㅠㅠㅠ 너무 좋네요. 제가 쉽게 풀었다기 보다 동료님의 실력이 출중하셔서 일거예요!!! 오히려 이렇게 어려운 영상을 좋아해주셔서 감사합니다 🙇🏻♂️🙇🏻♂️🙇🏻♂️ 다음에 더 좋은 영상으로 자주 찾아뵐게요~~!
너무너무 유익했습니다ㅎㅎ 좋은 영상 감사드립니다!
안녕하세요 동료님! 영상 시청해주셔서 감사합니다.
너무너무 유익했다니.. 🥹 제가 오히려 감사의 말씀을 드리고 싶네요. 영상을 올릴까 말까 고민을 했던 시간이 너무 아깝게 느껴지네요. 차라리 더 빠르게 공개를 할걸 이라는 생각이 들게 만들어주신 동료님께 오히려 감사합니다. 영상을 올리기 전까지도 정말 많은 고민을 했거든요. 앞으로도 재밌고 유익한 영상으로 찾아뵐게요!
다시 한번 영상 시청해주셔서 감사합니다.
그럼 좋은 저녁 되세요~!!!
좋은 영상 만들어주셔서 감사합니다. 이해가 잘가도록 정말 쉽게 만드셨네요. 설명하는 능력이 좋으신거 같아요. 다음영상은 꼭 이 내용을 이어서 다른 해결방법들을 알려주셨으면 좋겠습니다
안녕하세요 동료님.
어머나,, 걱정을 많이 했는데, 이렇게 좋아해주셔서 감사합니다. 🙇🏻♂️ 제가 설명을 잘 했다기 보다 동료님께서 아시는게 많아서 쉽다고 느끼셨던거 같아요.
원래 계획은 없었는데,, 2탄을 한번 제작을 해볼게요.
스포를 하나 하자면 "사이드 프로젝트 나라 여행기"를 지금 찍고 있어서 조금 시간이 걸릴진 모르겠어요. 다른 여행기도 좋은 내용으로 찾아뵐 예정이니 많은 관심 부탁드립니다!
그럼 다시 한번 영상 시청해주셔서 감사합니다.
그럼 좋은 저녁 되세요!
전자상거래는 가장 대표적인 ssr 활용 사례가 아닐까 싶음. seo 장점도 있고 수 많은 트래픽을 csr로만 처리하면 과도한 번들 용량과 느린 렌더링 시간으로 인해 사용자 이탈이 발생하고 그로 인해 매출에 영향이 가장 빠르게 감. csr에서 부드러운 로딩 경험을 위해 스켈레톤 UI도 인기가 많지만 답답한 느낌을 주는 건 매한가지임. 이제 next에서는 "use cache"를 만들고 있던데 지시문이 벌써 3개가 된... ㅜㅜ
스트레스 테스트를 이렇게 편하게 할 수 있다니; 요즘 진짜 좋아졌네요! 방금 막 해봤는데 리포트가 쌈뽕하게 잘 나옵니다 굳굳
오오오오오 직접 실습까지 해봐주셔서 너무 좋네요!! 근데 요즘 세상이라뇨 ㅠㅠㅠㅠ... 대 선배님이신거예요...? 🙇🏻♂️🙇🏻♂️🙇🏻♂️🙇🏻♂️🙇🏻♂️
도움 많이 됩니다 감사합니다 코드를 같이 보여주시니까 훨씬 직관적으로 잘 이해가돼요
헛... 너무 어려운 영상이 아닐까 고민이 많이 되었는데 ㅠㅠ 그래도 쉽게 받아드려 주셔서 감사합니다. 도움이 되셨다니 제가 더 감사한걸요..? 🥹
항상 더 좋은 영상으로 찾아뵐게요~~!
그럼 좋은 저녁 되세요!
개발공부하는 입장에서 너무너무 좋은영상입니다 !! 이해 너무 잘되요!! ㅎㅎ
안녕하세요 예비 동료님!
만나서 반갑습니다.
너무 이해가 잘된다니... 눙물... 🥹 정말 감동입니다.
개발을 공부하시는 입장이심에도 불구하고 이런 내용을 이해하실수 있는 후니쨩님은 도대체 누구세요.... ~예전의 저였다면 영상 바로 껏을텐데...~
더 좋은 영상으로 찾아뵐게요!
그럼 좋은 저녁 되세요~~!
최근 프로젝트를 next를 쓸지말지 너무 고민인데, 좋은 영상 감사합니다. dx는 좋은데 인프라 구성으로 인한 업무가 너무 많아지기도 하고 비용도 비용이고 고민이네요. 결정해주세요.. 🥹
궁금한게 있습니다!
fetch와 isr방법이외에도 리액트쿼리방법도 있지않나요??
하이드레이션을 사용해서하면 서버사이드 환경에서도 사용이가능하고 빠르게 불러올수있구여
fetch와 isr을 사용하는것보다 기능과 옵션또한 더 많고여!
안녕하세요 동료님!
영상 시청해주셔서 감사합니다. 그리고 수준 높은 질문 감사합니다!
질문 주신 것처럼
> fetch와 isr방법이외에도 리액트쿼리방법도 있지않나요??
이 방법도 존재합니다! 앞서 말씀드렸던 fetch의 방식과 동일하게 캐슁을 해볼 수 있고, 옵션으로 조작이 가능하죠. 해당 영상에서 tanstack/react-query까지 다루진 않은 이유는 next의 기본적인 기능에 초점을 두고 싶어서 였어용. 그래서 말씀하신것처럼 react-query를 사용하는 방법은 "fetch의 캐쉬를 이용하는 전략과 동일"합니다!
> 하이드레이션을 사용해서하면 서버사이드 환경에서도 사용이가능하고 빠르게 불러올수있구여
이 말씀은 결국 SSR을 한다는 것인데, 이게 ISR과는 차이가 있어용.
말씀주신 방법을 제 나름의 플로우로 표현 하자면,
SSR은
1) '/' 요청
2) next 서버에서 필요한 데이터 요청(이때 react-query 사용)
3-1) 요청 완료된 데이터로 HTML을 그림
3-2) react-query의 QueryClient에서 json 응답을 string으로 변환
3-3) 변환한 데이터를 html에 삽입
4) client 사이드 일때 html에서 삽입된 응답을 Hydration 컴포넌트에서 불러와 QueryClient에 데이터 적용
대략적으로 이런 방식일텐데, 대규모 트래픽일때 문제가 되는 부분은 "3-1과 3-2"입니다.
영상에서 잠깐 언급하고 지나갔는데 싱글 스래드에서 CPU 집약적인 작업을 진행하면, 그 뒤에 작업들이 pending이 되요. HTML을 string으로 만들어주는 작업도 대규모 트래픽에서는 꽤 큰 작업이고 react-query에서 데이터 요청을 보내고 받는 그 200ms 내외의 시간 조차 부하로 이어집니다.
그래서 ISR로 바꿔보면 cache-hit일때의 경우는 "3-1"과 "3-2" 작업이 생략이 됩니다.
1) '/' 요청
2) next 서버에서 캐쉬된 페이지가 있는지 찾아봄
3) 만약 유효한 데이터라면 캐쉬된 페이지를 내려줌 (여기에 data는 이미 포함이 되어있음)
신나서 글을 쓰다보니 길어졌네요 ㅠㅠ.. 도움이 되셨으면 좋겠네요.
다시 한번 영상 시청해주셔서 감사합니다 🙇🏻♂️
그럼 좋은 저녁 되세요!
@@eddie_the_traveler 와.. 정말 너무나 감사합니다!!
다시한번 영상 정주행 하고 내용정리겸 블로그에 작성해야겠습니다.
진짜 다시 한번 너무 감사합니다.
글을 읽었는데 진짜 머리가 번뜩 하고 깨달음이 온것만 같은 기분입니다.
구독박겠습니다 좋은 양질의 컨텐츠 너무나 감사드립니다.
너무 좋네요 ㅎㅎ감사합니다.
어머 상체충님~ 또 뵙게 되어 반갑네요!
영상이 많이 도움되셨으면 좋겠네용!!! 다음에 더 좋은 내용과 재밌는 내용으로 찾아뵐게요!
그럼 좋은 저녁 되세요~!
이런 내용 너무 좋네요.. 재밌게 잘봤습니다 ㅎㅎ
우와 민찬님~~ 오랜만이네요! 재밌게 잘 보셨다니 오히려 제가 감사하네요.
앞으로도 좋은 영상으로 찾아뵐게요~ 그럼 좋은 저녁되세요!
영상 너무 재미있어요. 에디는 무적이고 캐시는 신이야!
안녕하세요 도라방스님~~ 오랜만에 뵙네요!
허걱.. 이렇게 극찬을 해주시다뇨! 영상을 찍고 공개를 할까말까 고민했던 시간이 바보같이 느껴지게 해주셔서 감사합니다. 항상 제 채널에 관심 가져주셔서 감사해요. 앞으로도 더 좋은 영상으로 찾아뵙겠습니다!
그럼 좋은 저녁되세요!!
너무 좋아요 더 주세요 필살기!!!!
안녕하세요 동료님!
저의 영상 관심가져 주셔서 감사합니다! 심지어 너무 좋으시다니 감동입니다 🥰
앞으로 더 좋은 영상으로 찾아뵐 수 있도록 할게용! 🙇🏻♂️
날씨가 많이 추워졌네요. 항상 건강 유의하시고 행복한 일만 가득하세요!
다시 한번 영상 시청해주셔서 감사합니다.
영상 재밌게 보았습니다 역시 에디님 😊
다만 영상을 보면서 몇가지 궁금한점이 생겼어요!
캐싱을 일정시간동안 해두고 데이터가 있다면 SSR을 통해서 그리는거라고 하셨는데요
만약 30초 이내에 데이터가 바뀌었고 그사이에 유저가 새로고침을 하면 최신 정보가 반영이 안되는건지 궁금합니다
추가로 에디님이 설명하신 두 발식이 햇살리는데 ISR방식에서 revalidate주기로 저장하는것과
fetch에서의 revalidate랑 같은역할을 하는 것 처럼 보이는데 어떤 차이점이 있는건가요?
안녕하세요 버그하우스님!
우와,,, 좋은 질문 주셔서 감사합니다
> 캐싱을 일정시간동안 해두고 데이터가 있다면 SSR을 통해서 그리는거라고 하셨는데요
만약 30초 이내에 데이터가 바뀌었고 그사이에 유저가 새로고침을 하면 최신 정보가 반영이 안되는건지 궁금합니다
네 맞아요. 정말 핵심을 찔러주셨네요. 이게 캐슁의 단점이기도 합니다. 최신화된 데이터를 못보는게 단점이죠. 그래서 캐쉬를 사용하는 상황은 조금 더 많은 상황이 고려되어야 하기도 해요. 말씀해주신 데이터 갱신이 민감한 상황이라면, 캐쉬를 쓰는게 오히려 독이 될 수 도 있어요.
> 추가로 에디님이 설명하신 두 발식이 햇살리는데 ISR방식에서 revalidate주기로 저장하는것과
fetch에서의 revalidate랑 같은역할을 하는 것 처럼 보이는데 어떤 차이점이 있는건가요?
ISR 방식은 페이지 자체를 캐슁 해놓는 방식이고 fetch는 서버 데이터만 캐쉬처리 하는 방법입니다. 각각의 방식의 가장 큰 차이점은 cache-hit일때 "html을 서버에서 그리냐 안그리냐"의 차이에요.
📌 fetch에서의 cache-hit일때:
1) '/' 요청
2) '/'에 필요한 데이터를 json 호출
2-1) '/'에 필요한 데이터가 캐슁되어 있기 때문에 바로 응답
3) 필요한 데이터를 통해 html을 stringify함
4) 사용자에게 내려줌
📌 ISR일때 cache-hit:
1) '/' 요청
2) '/' 캐쉬된 페이지 있어서 바로 페이지 내려줌
그럼 여기서 하나 궁금증이 드실텐데, html을 stringify를 하는게 그렇게 오래 걸려? 라고 물어보신다면, 아마 대략 200ms 내외 혹은 그것보다 훨씬 빠른 처리 속도일텐데, 이것도 페이지를 어떻게 구성을 하고 있느냐에 따라 달라요. 굉장히 짧은 시간처럼 느껴질 수 있지만 이것도 대규모 트래픽일때는 부하가 됩니다. 왜냐하면 nextjs 프로젝트는 node 서버에서 구동을 하고 있고, node 서버는 싱글 스레드이기 때문에 원래 요청이 처리가 되지 않았다면 다른 요청을 처리할 수가 없어서 pending 이 걸려버려요. 끊임없이 html을 stringify를 해야하는데, 이렇게 html을 조립하는 것도 자칫 부하로 이어질수 있거든용. ㅠㅠㅠ... 그래서 스트래스 테스트를 통해 정말 부하가 걸리는게 맞는지, 요청을 다 수행할 수 있는지를 테스트를 돌려보면서 찾아내고 개선을 해야하는 거 였어요!
오늘도 정말 좋은 질문 남겨주셔서 감사해요 버그하우스님!
그럼 도움이 되셨길 바라면서...! 글을 마쳐보겠습니다.
그럼 좋은 저녁되세요!
@@eddie_the_traveler답변감사합니다. csr일때가 뭔가 가장 편했던 것 같네요ㅋㅋㅋ
진로 고민 끝에 웹 개발자를 하기로 결정한지 몇 주 되지 않은 대학교 4학년입니다.
다 이해할 수는 없지만, 내용이 흥미롭고 잘 설명해주셔서 재밌게 보았습니다.
여러가지 동기부여가 되었습니다. 감사합니다.
허걱.... 이 영상에 동기 부여를 받는 예비동료님의 정체가... 궁금합니다!!!
웹 개발자로 진로를 정하셨군요! 축하드려요. 꼭 꽃길만 걸으시면서, 취업까지 바로 되셨으면 좋겠네요!! 개발자로 취업하시면 제 채널에 자랑하러 오셔야해요!
좋은 팁 알려주셔서 감사합니다!
안녕하세요 동료님! 영상이 도움 되셨다면 제가 더 감사하죠!
영상 시청해주셔서 감사합니다!
도움이 됩니다!! 감사합니다
안녕하세요 동료님!!!
도움이 되셨다니...! 제가 고민 고민을 몇개월을 했는데... 찍어놓고도 공개를 누를까 말까를 정말 많이 고민했는데...!! 그냥 일찍 공개를 할걸 그랬나봐요 ㅠㅠㅠ. 도움이 되셨다니 오히려 제가 더 감사합니다. 앞으로도 재밌고 유익한 영상으로 찾아뵐게요~~!
다시 한번 영상 시청해주셔서 감사합니다. 🙇🏻♂️
그럼 좋은 저녁되세요~~~!
더빙이 야무지시네용
ㅋㅋㅋㅋ 먼말인가 했네
이번에 (부끄) 새로운 방법으로 (부끄) 영상을 제작해봤는데요 (부끄) 좋아해주셨던거 (부끄) 맞죠? (부끄)
@@eddie_the_traveler 항상 잘 보고있습니다 ㅎㅎ 좋은 영상 감사합니다!
부하 테스트를 어떻게 하나 싶었고 어떻게 대처하나 알고싶었는데 정말 감사합니다.
안녕하세요 동료님! 영상 시청해주셔서 감사합니다!!!
그리고 영상이 도움이 되셨다니 너무 좋네요..! 항상 도움이 되는 영상들로 찾아뵐게요!!
그럼 좋은 저녁되세요!
영상 핵잘만드시네요
헛... 제가 오히려 감사합니다;; 영상 공부를 한게 도움이 되었나보네요 ㅠㅠㅠㅠ 이렇게 알아주셔서 제가 오히려 감사합니다 흑흑흑흑
감사합니당 ㅎㅎ
어머 이빨없는 아이님!! 오랜만이네요~~ 시험은 잘 끝나신거 맞죠~?
@@eddie_the_traveler네 ㅎㅎ 근데 또 기말고사 기간이네요ㅜㅜ
nextjs 는 기본적으로 서버컴포넌트로 생성하면 ssg 로 프로젝트가 빌드 될때 html을 만들어 두는데 그럼에도 서버 부하가 많이 생기나요??? 단순히 만들어져있는 html을 클라이언트에게 건내주는일인데.. 부하테스트 같응걸 해본적이 없어서 궁금하네요
staletime 옵션이나 캐시컨트롤에 의해 ssg가아닌 ssr로 동작할수도있고 이는 클라이언트 요청에대한 서버의 처리로 이어지기때문에 부하가 언급되는것같아요
어떻게 하면 잘 설명드릴수 있을까... 를 1시간 동안... 고민하며 쓰고 지우기를 계속 반복했네요.
아무래도 실제 데이터를 보고 싶어하시는 거 같아서 관련해서 글을 찾아봤어요:
fe-developers.kakaoent.com/2024/240418-optimizing-nextjs-cache/
저보다 더 훌륭하신 개발자분이 실제 현업 데이터로 공개 + 글을 적어두신게 있어 공유드립니다! 제가 설명드리는 것보다 100배 1000배 더 잘 적어주셨어서, 더 이해가 가실거 같아요!
도움이 되시길 바라면서.. 영상 시청해주셔서 감사합니다!
개발초보자 입장에서는 데이터만 fetch해서 csr로 하는게 제일 좋은거같네요
seo에 불리하다곤 해도 서버터지거나 반응속도가 늦어지는것보단 나은거 같네요
문제는 기업이나 다양한 업체들은 전부 seo에 유리한걸 원하니깐 의미가 없음 개인사이트를 만들어도 seo에 유리한 사이트가 수익의 핵심이니깐
방문자가 없으면 사이트를 운영하는 의미가 없으므로 seo도 충분히 고려되어야 합니다.
저런 기법이 있다는 걸 기억하고 필요할 때 적용하면 됩니다.
언제까지 초보자만 하실 수는 없잖아요.
@@jung-holee3675 당연히 seo도 고려가 되야지요 로그인 없이 보여지는 부분이 정적페이지면 csr에서도 충분히 프리렌더링을 이용할 수 있고요
어머,, 이런 토론 너무 좋네요....! ❤️
저의 답변은 "프론트엔드 대규모 트래픽 - 2탄"에서 한번 풀어볼게용
요즘 서버사이드 랜더링이 새로운 기술? 뭔가로 강조 되고 있는데 ㅎㅎㅎ 우리 같은 옛날 개발자들은 무슨 느낌이냐면 마치 핸드폰 밧데리를 분리해서 따로 충전하게 하면 좋지 않을까요? 이런 느낌임.
원래 웹개발은 그냥.. 서버에서 앞에 아파치나 nginx두고 php,jsp,asp뭐 이런거 써서 대충 html말아가지고 던지는 거였음.
그거랑 지금 ssr은 전혀 궤가 다른데 ㅋㅋㅋㅋ
@@언잉-s8i전혀까진 ㅋㅋ
기술은 원형으로 도는게 아니라 나선형으로 발전하죠 요즘의 서버 렌더링이 과거에 템플릿 통해 만들어진 html 던져주는 방식과 방향성 면에서 통하는 면이 있지만 디테일이 막상 많이 다르죠 게다가 서버 렌더링만 하는게 아니라 컴포넌트별로 렌더링 방식이 다른 하이브리드라..
맞아요.. 예전에 비하면 정말 많이 복잡해졌죠..
그리고 단어도 너무 헷갈리는거 같아요...
애쓰봇 동료님께서 말씀주신건 SSR이고
언잉 동료님께서 말씀주신건 SSR with hydration이라는 명칭이더라구요.
그리고 최신 react, next.js 버전에서는 server component 라고 부릅니다.
이 세개가 비슷해 보이긴 해도 무명 동료님께서 말씀주셨던 것처럼 디테일이 다릅니다.
애쓰봇이 말씀주신 SSR은 MPA(multi page app)고
언잉 동료님께서 말씀주신건 SPA(single page app) 이어서 다르고..
최신 react, next.js 버전에서의 server component는 SPA + streaming의 개념에서 조금 씩 차이가 있어요.
이 영상에서 하고 싶은 이야기중에 하나는 기술을 쓸때는 "약점과 강점"을 알고 그걸 잘 활용하자! 였어용. 사실 애쓰봇 동료님께서 말씀해주신 것처럼 jsp와 같은 것들로도 훌륭한 프로젝트를 만들어낼 수 있어요. 항상 최신 기술이라고 좋은 면만 있진 않거든요.
많은 분들이 요즘 next.js를 학습을 하시고 많은 프로젝트를 진행중 이신데, 이러한 단점을 모르고 있었다면, 나중에 그걸 극복하기에는 이미 유저들은 다 떠나갔을 거 같아요 ㅠㅠ... :(
다시 한번 영상에 관심 가져주셔서 감사합니다!
더 좋은 영상으로 찾아뵐게요!
그럼 좋은 저녁 되세요~~!
중간중간 악가 못알아 듣겠는데...부하가 걸린다고 데이타 접근에 캐싱을 사용하자는 전략은 근본적으로 반다네.
안녕하세요 동료님. 영상 시청해주셔서 감사합니다.
저도 동료님께서 말씀하신 부분에 전적으로 공감이 갑니다.
영상 더보기에서도 말씀드렸던 것처럼 단순 부하 문제로 해당 주제를 말씀드렸던건 아니었어용. 포트폴리오에 적기 좋은 주제이기 때문에 이야기를 나눠봤던거 였어요. 그리고 여러가지 방법들중 가장 빠르고 효과적으로 문제를 해결할 수도 있는 방법이기도 합니다. TTI, FCP, TPS,.. 와 같은 수치들에 최적화 및 공부를 하기 좋은 주제기도 하죠.
"개발자에게 기술은 도구로써 취급 되어야 한다."
저는 이 말을 굉장히 좋아해요. 그리고 왜 이런 기술을 사용하셨어요? 라는 질문을 받을때를 가장 좋아해요. 많은 분들이 next.js를 공부하시고 좋다고만 알고 계시지만, 이 서버가 얼마나 쉽게 죽을 수 있는지는 잘 모르시는 분들이 많아 해당 영상을 제작하게 되었습니다 ! 기술의 장점과 단점을 명확하게 알고 있어야 특정 상황에 최선의 기술을 사용한다고 믿거든요.
영상을 이해하기 힘드셨겠지만 그래도 도움이 되셨길 바라면서 글 줄여볼게요.
다시 한번 영상 시청해주셔서 감사합니다!
그럼 좋은 저녁 되세요~!
CSR 만세
흠흠,, 저도 CSR 참 좋아하는데요...
라떼이야기를 한번 하자면... 이렇게 복잡한거 없이...그냥 막 알짤딱깔센으로 간단하게 했었는데 말이죠......
이거 좋은내용이네요
싱글 스레드는 cpu 집약적인 작업에는 적합하지않죠
그럼 pm2 같은걸로 클러스터 모드로 늘리면 되겠네 해도 되지만 이것도 문제가 생기는게 로드 밸런싱이 적절히 처리가 되지않을수 있고 라우트로 다른 요청이 일어나면 다른 인스턴스로 요청이 전환되어 상태가 유지가 되지않을수도있지요 그래서 언급해주신거처럼 레디스 같은거 붙여서 상태를 공유하는 전략까지 생각해야하는데 ㅎㅎ 여튼 프론트도 빡시네요
프론트는 웁니다 ㅠㅠ
뤼발리데잍ㅋㅋㅋ
이건 제가 못 따라가는거 같은데 😅,,, 혹시 어떤 부분이 웃기셨던걸까요..?
리벨리데이트 .. 로 읽을줄알았슴다
감사합니다!
안녕하세요 동료님! 영상이 도움이 되셨다면, 제가 더 감사하죠!
영상 시청해주셔서 감사합니다!