Apollo Client의 cache-and-network 재요청 중 이전 값을 지키는 법
useQuery를 통째로 감싸는 낯선 코드를 만났다. 캐시를 쓰는 GraphQL 클라이언트라면 새로고침 중에도 화면에 값이 남아있을 거라고 막연히 생각하고 있었다. 왜 이런 패턴을 사용하고 있었을까?
getServerSideProps에서 실제로 일어나는 일
getServerSideProps 코드를 보다가 "그래서 이 함수는 내부적으로 어떻게 동작하는거지?"라는 의문이 생겼다. props가 페이지 컴포넌트로 전달된다는 사실은 알고 있었지만, 그 사이 서버에서 정확히 무슨 일이 일어나는지는 설명하지 못했다. 요청 하나가 들어오는 순간부터 화면에 그려지기까지의 경로를 처음부터 따라가보고자 했다.
nginx와 애플리케이션 코드의 리버스 프록시 구분하기
nginx 뒤에 있는 Node.js 애플리케이션 코드를 들여다보다가, 그 안에도 "프록시"라고 부르는 코드가 있는 걸 봤다. 리버스 프록시는 nginx 같은 별도 서버의 몫인 줄 알았는데, 같은 이름의 개념이 애플리케이션 코드 안에도 있다는 사실이 한동안 헷갈렸다. 공식 문서를 하나씩 짚어가며 확인해보니, 두 프록시는 이름은 같아도 어느 프로세스 경계 안에 서 있는지부터 달랐다.
Apollo Client의 fetchPolicy 기본값이 cache-first인 이유
Apollo Client의 fetchPolicy 옵션 중, 최신값까지 확인하는 cache-and-network가 가장 좋은 선택이라 생각했다. 하지만, 라이브러리의 기본값은 캐시에 값이 있으면 네트워크조차 안 쓰는 cache-first였다. 왜 라이브러리는 이쪽을 선택했을까?
WebSocket부터 이해하자
웹소켓 복구 전략을 알아보기 전, 먼저 웹소켓의 개념과 동작 원리부터 살펴보았다. 단순히 코드 수준의 복구 로직을 다루기보다는, 웹소켓이 기존 통신 방식과 어떻게 다른지부터 이해하고자 했다.
쉘 내부 명령어와 외부 명령어
쉘에서 명령어를 처리할 때 외부 파일 명령어와 내장 명령어의 차이가 존재한다는 것을 알게되었고 조금 더 깊게 알아보았다.
터미널 명령어 실행 과정
OS와 유사한 시스템을 구현하기 위하여 실제 OS의 동작 방식을 학습하며 적용해보고자 했다.
로그인 및 사용자 세션 시작 과정
컴퓨터 부팅 후 사용자가 로그인한 뒤, 어떤 과정이 이루어지는지 고민하며 정리하게 되었다.
컴퓨터 부팅 이후 프로세스 실행 과정
컴퓨터 부팅 과정에서 사용자가 시스템을 실제로 사용할 수 있게 될 때까지의 과정을 궁금하여 찾아보게 되었다.
컴퓨터 부팅 과정
사용자가 컴퓨터의 전원을 켜면, 시스템이 어떤 과정을 거쳐 시작되는지 차근차근 정리해 보았다.