이 글은 Vite 공식 문서를 번역한 글입니다. JavaScript 모듈화 브라우저에서 ESM(ES Module)을 지원하기 전까지, JavaScript 모듈화를 네이티브 레벨에서 진행할 수 없었다. 그래서 소스 모듈을 브라우저에서 실행할 수 있는 파일로 크롤링, 처리 및 연결하는 "번들링"이라는 해결 방법을 사용해야 했다. Webpack, Rollup, Parcel 등과 같은 툴은 번들링 작업을 진행해주면서 프론트엔드 개발자의 생산성을 크게 향상시켰다. 그러나 애플리케이션이 거대해지고 복잡해짐에 따라서 처리해야 하는 JavaScript 모듈의 개수도 기하급수적으로 증가하고 있다. 심지어 수천 개의 모듈이 존재하는 대규모 프로젝트도 존재하며, 이런 상황에서 JavaScript 기반의 툴은 성능 병목 현상..
Apollo Client를 사용하기 시작할 때 가장 처음으로 어려움을 겪는 부분이 cache 관련한 부분 아닐까 생각한다. (적어도 나는 그랬다.) 그래서 오늘은 개인적으로 Apollo Client의 caching(이하 캐싱)에 대해서 정리도 해볼 겸 추가적으로 공부하고자 포스팅을 하게 되었다. 개요 Apollo Client는 기본적으로 GraphQL의 모든 쿼리를 알아서 자동으로 캐싱한다. 기본 설정을 아무것도 건드리지 않았다면, 모든 쿼리 요청에 대해 캐싱된 데이터를 우선으로 응답한다. 요청이 발생했을 때 Apollo Client가 이 요청을 가로채서 실제로 서버로 요청을 보내지 않고 캐싱된 데이터를 응답으로 반환한다. 이 때문에 서버에서 실시간으로 바뀌는 값을 가져오고자 할 때는 난감한 경우_(이런..
최근 사내에서 서버 모니터링을 진행하는 도중에 Node App Memory 사용량이 지속적으로 증가하는 현상이 관찰되었다. 즉, 메모리 누수 현상이 발생한 것이다. 메모리 누수라는 것은 불필요한 메모리를 특정 프로그램이 지속적으로 점유하고 반환하지 않는 현상을 일컫는다. 메모리 누수가 누적되면 메모리가 낭비되고, 심해질 경우 누수되는 메모리가 메모리의 대부분을 차지해서 애플리케이션이 정상적인 동작을 할 수 없게 된다. 이러한 메모리 누수에 대해서 원인을 추적하고 최종적으로 도달한 결론에 대해 복기하고 공유하기 위해 오늘의 포스트를 작성하게 되었다. 살짝 스포일러를 하자면, 원인은 Recoil이었다. Recoil의 어느 부분이 문제가 되었고, 이 문제를 해결하기 위한 방법과 현재 Recoil이 당면한 추가..
React의 함수형 컴포넌트에서 사용하지 못했던 상태 관리, Lifecycle Method 등 여러 기능을 대체하기 위해 등장한 개념. React 16.8 버전에서 추가되었다. 클래스형 컴포넌트의 단점 번들링 시 코드 압축이 잘 되지 않는다. 컴파일 단계에서 코드를 최적화하기 어렵게 만든다. 서로 연관성이 없는 여러 로직을 하나의 생명 주기 메서드에 작성하는 경우가 많다. Hot Reload를 적용한 상황에서 개발자가 개발 시 디버깅하기 힘든 버그를 발생시키는 경우가 있다. 재사용 가능한 로직을 만들 때 고차 컴포넌트를 사용하거나 렌더 속성값 패턴을 사용함으로써 React Element Tree가 깊어지면서 성능에 부정적 영향을 끼친다. Hook의 장점 앞서 말한 클래스형 컴포넌트의 단점이 해결한다. 비..
이 글은 토스 개발자 컨퍼런스 SLASH 21 중 박서진 님의 프론트엔드 웹 서비스에서 우아하게 비동기 처리하기를 보고 내용을 정리한 글입니다. 정말 좋은 영상이니 여러분들도 꼭 보면 좋을 것 같습니다. 웹 서비스에서 다루기 어려운 "비동기" 비동기 프로그래밍은 프론트엔드 개발에 있어서 필수적인 존재다. 가장 큰 이유는 브라우저가 서버에 요청을 보낸 후에 아직 응답이 오지 않은 상황에서도 사용자와 인터랙션을 멈추면 안 되기 때문이다. 즉, 서버로 요청을 보내는 코드를 작성했을 때 해당 요청에 대한 응답이 담긴 변수의 값이 정해지기 전에도 다른 코드가 실행될 수 있어야 한다. 더 나은 사용자 경험을 위해서다. 그럼에도 불구하고, 비동기 개념은 초보 개발자들의 뒷목을 잡게 하고 어느 정도 개발을 해 본 개발..
이번에 Create React App으로 만들지 않고 직접 Webpack(내 기준 v5.54.0) 설정을 통해 만든 React 프로젝트의 환경변수를 설정하는 과정에서 참담한 경험을 해서 이렇게 글로 남긴다! 만약 이 글을 읽는 당신이 아래 중 하나 이상의 상황에 속해있다면 이 글을 꼭 읽고 환경변수 설정에 성공하기를 바란다^^ 당신의 React 프로젝트가 CRA(Create React App)로 만들어지지 않았을 때 당신의 React 프로젝트가 Webpack 5버전 이상을 통해 구축됐을 때 dotenv 쓰라 해서 썼는데 에러가 발생할 때 그냥 문제에 대한 해결 방법을 알고 싶다면 스크롤 쭉 내려서 마지막 3줄 요약을 읽어주세요. 길고 긴 여정 일단 한국어로 React 환경변수 설정에 대해 구글링을 해보면..
최근 Node.js 기반 서버 프레임워크 중 많은 각광을 받고 있는 NestJS. 저번 GraphQL 포스팅과 마찬가지로, 최근 NestJS도 적극적으로 사용해 본 경험이 생겼기 때문에 NestJS에 대해서 여러 포스팅을 작성하려고 한다. 이번 글에서는 NestJS의 등장 배경과 다른 Node.js 기반 서버 프레임워크와 비교했을 때 NestJS가 가지는 장단점 등에 대해 정리해보겠다. 2021년 현재 모던 웹 애플리케이션을 개발하는 데 있어서 Node.js의 인기는 폭발적으로 상승하고 있다. 2021년에 진행된 Stack Overflow Developer Survey에 따르면 Professional Developers에 의해 가장 인기있는 언어 6위에 랭크되어 단연 최고의 인기를 구가하고 있다고 말해도..
최근 좋은 기회를 통해 GraphQL을 적극적으로 사용해볼 수 있는 경험이 생겼다. 이 과정에서 스스로 체감했던 REST API와의 차이점, 그로 인해 생기는 장단점, 그리고 REST API를 쓰면 좋을지 GraphQL을 쓰면 좋을지 고민한 내용을 적어보려고 한다. 만약 당신이 (얼마 전의 나처럼) GraphQL에 대한 간단한 정의만을 알고 있고 실제로 사용해본 적은 없으며 REST API만 사용해 봤다면 이 글에서 얻어갈 수 있는 게 많을 것이라고 생각한다. GraphQL이 무엇인가? GraphQL은 QL이라는 단어가 끝에 붙었듯이 Query Language다. 대부분 Query Language라 하면 SQL이 가장 먼저 떠오를 것 같은데, SQL이 DB에게 데이터를 질의하기 위해 사용하는 쿼리 언어라..