안녕하세요. 강의 잘 보고 있습니다. LIST, Set, ZSet의 item을 정렬하여 반환하는 SORT 명령어의 시간 복잡도가 O(N)이라고 설명해주셨는데, 어떻게 O(N)이 나온건지 궁금합니다.

SET inflearn-redis:ko:price 200 은 어떤 명령어 인가요?OK 가 뜨긴 했는데다시 get inflearn-redis 해도 전이랑 변함 없이{\"price\":100,\"language\":\"ko\"} 가 리턴이 되서요asdf

@Entity내에서 one to one, many to one 등등 과 같은것들도 쿼리가 발생하자나요근대 이부분에 대해서 Cacheable을 적용할 방법은 없나요?찾아도 없는거같아서 문의드려봅니다 

logout과정에서 질문이 있습니다. 로그인을 할때 서버에서 클라이언트로 res .cookie("x_auth", user.token) .status(200) .json({ loginSuccess: true, userId: user._id });이렇게 json 형식으로 성공여부와 user_id값을 보냅니다. 로그아웃을 할때는 axios로 /api/users/logout" 에 요청을 보내기만 합니다. 그리고 server는 req로 user_id값을 받아서 로그아웃을 진행합니다. client에서는 userid를 보낸적이 없는데 서버는 어떻게 req를 통해 user_id에 접근할 수 있나요? client는 로그인시에 서버에서 json으로 데이터를 받았는데 이것은 어디에 저장되는 것인가요? 또한 저장되는 공간은 누가 정하게 되는 것인지 궁금합니다. 스토리지 종류가 여러가지 인데 말이죠.확인해보니 local storage, session storage, lndexeddb등은 다 비어있고 쿠키에만 x_auth가 저장되어있습니다. 음... 브라우저가 알아서 보내주는 건가요..?

ssr 적용한 페이지가 a.js 페이지라고 가정 한 후 a.js에서 b.js 간 후 뒤로가기 버튼을 누르면 a.js로 와질때 cache가 안먹던데 next.js 공식 문서들어가서       context.res.setHeader(         'Cache-Control',         'public, max-age=100, s-maxage=100, stale-while-revalidate=100'     ) 이런식으로 넣으면 캐싱이 된다는데 안되더라고요 혹시 이런 이슈에 대해서는 어떻게 생각하시는지 궁금합니다.

Nextjs 프로젝트를 배포했습니다. index.js에서 getServerSideProps()로 데이터를 가져와 next build 시에 index.html은 생성되지 않았습니다! Express로 next routing을 연결해 페이지가 보이도록 하고 있으며 pm2 로 무중단배포 중에 있습니다.!   메인 페이지에 접속했을 때 나타나는 페이지의 html 내용을 추출해 캐시파일로 생성하고 싶습니다. .  Express로 구현이 가능할지 궁금합니다!

안녕하세요. 해당 강의를 수강중인 김승수라고 합니다. 항상 좋은 강의를 제공해주심에 감사드립니다.   이번 강좌에서 Cache-Control: no-cache 부분을 들으며 이것을 사용하는 실제 사례가 궁금해서 문의드립니다.   Cache-Control: no-cache는 데이터를 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용해야한다고 설명들었습니다. 내용 자체는 이해가 가능하나 이 방식이 사용되는 실제 사례가 궁금합니다.   만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높으나, 데이터 자체의 크기가 커서 변경이 일어나지 않은 경우에는 데이터를 다시 가져오는 부하를 줄이기 위해 사용하는 것일까요? 만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높다면, 캐시 유효 시간을 짧게 설정하면 될 것인데... no-cache를 왜 만들었을까요? 캐시로 관리하는 데이터가 원 서버의 실제 데이터와 동일한지 매번 검증한다면 이 작업 자체도 오버헤드라고 볼 수 있지 않을까요? 아니면 드물게 사용하는 매우 큰 데이터를 캐시에 두고 캐시 유효 시간을 길게 가져가기 위해 사용하는 것일까요? 캐시 자체는 빈번하게 조회할 데이터를 빠르게 가져오기 위해 조회 데이터를 가까이 두는 기술로 알고 있는데요. 드물게 사용할 데이터를 캐시에 보관하는 것도 이상하다고 생각됩니다.   강사님의 답변 기다리겠습니다. 감사합니다.   김승수 드림

강의 잘 듣고 있습니다! 이번 강의 3:30 쯤에서 말씀하신 내용인데, 이전에도 다뤘지만 캐싱되는 방식이 애매하여 질문드립니다. 1. `COPY package.json ./` 과정이 생략된 경우 - 빌드 할 때마다 의존성 설치가 이뤄지는 것은 이해가 갑니다. 2. `COPY package.json ./` 과정이 추가된 후 `npm install` 을 실행한 후, `COPY ./ ./` 를 실행하는 경우 - 제 생각에는 npm install을 실행하는 시점에서 컨테이너의 working directory 에는 package.json 하나만 있는데 파일에 변경이 없으니 캐싱된 데이터(node_modules, package-lock.json)를 가져와서 복사해서 넣어준다. - 여기까지 수행하면 의존성이 설치된 상태이니, 나머지 모든 파일들을 복사해서 넣어준다. 다만 여기에는 package.json 이 겹치는 파일이나, 내용에 차이가 없기 때문에 문제가 발생하지 않는다. 위 작성한 내용 중 제가 잘못 이해한 부분이 있다면 지적해주시면 감사하겠습니다. 항상 감사합니다 :-) + 추가로 든 의문인데, 캐싱된 데이터는 이전에 생성했던 컨테이너에서 가져오는 걸까요?