How we make npm packages work in the browser

2017.10.6 - ✏️Ives van Hoorne

How we make npm packages work in the browser

CodeSandbox의 초기 개발 과정에서는 항상 npm 의존성 지원 범위를 벗어났다. 브라우저에 임의의, 랜덤한 양의 패키지를 설치하는 것이 불가능하다고 생각했으며 심지어 내 뇌가 막혔다고 생각했다.

요즘 npm 지원은 CodeSandbox의 가장 정의 된 기능 중 하나로, 어떻게든 작동 할 수 있다. 모든 시나리오에서 작동하려면 많은 반복이 필요했고, 여러 번 다시 작성했으며 심지어 이제는 논리를 개선 할 수 있다. 현재 가진 기능과 그것을 개선하기 위해 여전히 할 수 있는 작업, 그리고 npm 지원이 시작된 방법을 설명하겠다.

'First' Version

나는 npm 의존성에 접근하는 방법을 정말로 몰랐기 때문에, 매우 간단한 npm 지원 버전으로 시작했다.

이 버전의 npm 지원은 매우 간단했다. 실제로 npm을 지원하지는 않았으므로 의존성을 로컬로 설치하고, 모든 의존성 호출을 이미 설치된 의존성으로 stub 했다. 물론 이것은 다른 버전의 400,000가지의 패키지로 확장 할 수는 없었다.

이 버전은 그다지 유용하지는 않았지만, 프로젝트 환경에서 적어도 두 가지의 의존성을 작동시킬 수 있음을 알게되었다.

webpack Version

사실 첫 번째 버전에 매우 만족했으며 MVP(CodeSandbox의 첫 번째 릴리스)에는 충분하다고 생각했다. https://esnextb.in 을 우연히 발견하기 전 까지는 마법을 부리지 않고서는 의존성을 설치하는 것은 가능할 것이라고 생각하지 않았다. 그들은 이미 npm의 모든 종속성을 지원했고, 사용자가 package.json 에서 정의하면 마술처럼 작동했다.

이것은 나에게 큰 학습 순간이었다. 나는 그것이 불가능하다 고 생각했기 때문에, 적절한 npm 지원을 생각도 하지않았다. 가능성 에 대한 살아있는 증거를 본 후에야 더 깊이 생각하기 시작했다. 아이디어를 기각하기 전에, 먼저 가능성을 살펴 봤어야한다.

그래서, 나는 이것에 접근하는 방법에 대해 생각하기 시작했다. 나는 그것을 너무 복잡하게 생각했다. 첫 번째 버전은 내 머리로는 불가능 했으므로 다이어그램을 그려야했다.

이 지나치게 복잡한 접근법의 한 가지 장점이 있었다. 실제 구현은 예상보다 훨씬 쉬웠다.

webpack 의 DllPlugin 이 의존성을 bundle 하고, JS 번들을 manifest 로 뱉어 낼 수 있다는 것을 알게되었다. 이 manifest 는 다음과 같습니다.

{
  "name": "dll_bundle",
  "content": {
    "./node_modules/fbjs/lib/emptyFunction.js": 0,
    "./node_modules/fbjs/lib/invariant.js": 1,
    "./node_modules/fbjs/lib/warning.js": 2,
    "./node_modules/react": 3,
    "./node_modules/fbjs/lib/emptyObject.js": 4,
    "./node_modules/object-assign/index.js": 5,
    "./node_modules/prop-types/checkPropTypes.js": 6,
    "./node_modules/prop-types/lib/ReactPropTypesSecret.js": 7,
    "./node_modules/react/cjs/react.development.js": 8
  }
}

모든 경로는 module id 에 매핑된다. React가 필요한 경우 dll_bundle (3) - 즉, ./node_modules/react 만 호출하면 React를 얻을 수 있다. 이것은 우리의 use case 에 완벽했기 때문에, 입력을 시작하고 이 실제 시스템을 생각해냈다.

packager 에 대한 모든 요청에 대해 /tmp/:hash 에 새 디렉토리를 작성하고, yarn add $ {dependencyList} 를 실행한 다음, webpack bundle 을 나중에 사용할 수 있다. 나는 캐싱 방법으로 새 번들을 gcloud 에 저장한다. 주로 의존성 설치를 yarn 으로 대체하고 webpack 으로 bundling 하기 때문에, 다이어그램보다 훨씬 간단하다.

프로젝트를 load 할 때, 먼저 evaluation 전에 manifest 와 bundle 이 있는지 확인한다. evaluation 하는 동안 모든 의존성에 대해 dll_bundle (id) 를 호출한다. 이것은 매우 잘 작동했으며, 적절한 npm 의존성이있는 첫 번째 버전이 되었다.

이 시스템에는 여전히 큰 한계가 있었다. webpack 의 의존성 그래프에 없는 모듈은 지원하지 않았다. 처음에는 의존성의 entry point 이 필요하지 않기 때문에 예를 들어, require ( 'react-icons / lib / fa / fa-beer') 와 같은 것이 작동하지 않는 것을 의미한다.

나는 이 버전으로 CodeSandbox를 배포했으며, WebpackBin Christian Alfoni 의 저자와 연락했다. 우리는 npm 의존성을 지원하기 위해 매우 유사한 시스템을 사용했으며 동일한 한계를 가지고 있었다. 그래서 우리는 힘을 합쳐 궁극적인 pacakger 를 만들기로 결정했다.

webpack with entries

Christian이 중요도에 따라 번들에 파일을 추가하는 알고리즘을 생성 한 것을 제외하고는, 궁극적인 패키지 프로그램은 이전 패키지 프로그램과 동일한 기능을 유지했다. 이는 webpack 이 해당 파일들도 bundle 로 제공할 수 있도록 entry potin 를 수동으로 추가했음을 의미한다. 이 시스템을 많이 조정 한 후에는 모든(?) 조합에서 작동하게 되었다. 따라서 react-icons와 CSS 파일도 작동할 수 있었다 🎉.

새로운 시스템에는 또한 아키텍처 업그레이드가 있었다. load balancer 및 캐시 역할을하는 DLL 서비스 가 하나 있다. 그 다음, 번들링을 수행하는 여러 패키지 관리자(packager) 가 있으며, 이 패키지 관리자를 동적으로 추가 할 수 있다.

우리는 모든 사람이 packager service 를 사용할 수 있도록하고자했다. 그렇기 때문에 서비스 작동 방식과 서비스 활용 방법을 설명하는 웹 사이트를 구축했다. 우리는 codePen 블로그 에서도 언급되다!

이 궁극적인 패키지 프로그램에는 여전히 몇 가지 제한과 단점이 있다. 인기가 높아지면서 비용이 기하 급수적으로 증가했으며, 패키지 조합을 통해 캐싱하고 있었다. 이것은 의존성(모듈) 을 추가 한 경우 전체 패키지 조합을 다시 묶어야한다는 것을 의미한다.

Going Serverless

나는 항상 serverless 라는 멋진 기술을 사용하고 싶었다. serverless 를 사용하면 요청시 실행할 함수를 정의하고, 함수가 spin up(가동) 되고, 요청을 처리 한 다음 일정 시간이 지나면 자체적으로 종료된다. 이는 확장성이 매우 높다는 것을 의미한다. 즉, 1000개의 동시 요청을 받으면 1000대의 서버를 즉시 가동 할 수 있다. 또한 서버가 실제로 실행되는 시간에 대해서만 비용을 지불한다는 의미이다.

Serverless sounds 는 우리의 서비스에 완벽하다. 풀타임으로 실행되지 않으며, 동시에 여러 요청이 있는 경우 높은 동시성이 필요하다. 그래서 Serverless 라는 적절한 이름의 프레임 워크로 열심히 개발을 시작했다.

Serverless 덕분에 서비스가 순조롭게 진행되었다. 2일 이내에 작동하는 버전이 있었고, 나는 serverless 함수 3개를 만들었다.

1. A metadata resolve: 이 서비스는 버전 및 peerDependencies를 확인하고, 패키지 기능을 요청한다.
2. A packager: 이 서비스는 의존성의 번들링 및 실제 설치를 수행한다.
3. An uglifier: 결과 번들을 비동기 적으로 uglifling 한다.

이전 서비스와 함께 새 서비스를 실행했는데 실제로 효과가 있었다! 이전에 $100였던 것에 비해, 예상 비용은 한 달에 $0.18로 줄었고 응답 시간은 40% 에서 700% 로 향상되었다.

며칠 후 제한 사항에 주목하기 시작했다. lambda 함수에는 최대 500MB 의 디스크 공간만 있으므로 일부 의존성 조합을 설치할 수 없었다. 이것은 deal breaker 였고 나는 drawing board 로 돌아와야했다.

Serverless Revisited

몇 달이 지나서 CodeSandbox 용 새 번들러를 출시했다. 이 번들러는 매우 강력하여, Vue 및 Preact 와 같은 더 많은 라이브러리를 쉽게 지원할 수 있다. 이 라이브러리를 지원함으로써 흥미로운 요청을 받았다. 예를 들어, Preact 에서 React 라이브러리를 사용하려면 require ( 'react') 를 require ( 'preact-compat') 라는 별칭으로 지정해야한다. Vue 의 경우, @/components/App.vue 를 샌드 박스 파일로 해석 할 수 있다. packager 는 의존성을 위해, 이 작업을 수행하지 않지만, 번들러는 이 작업을 수행한다.

그때, 브라우저 번들러가 실제로 packaging 을 할 수 있다고 생각하기 시작했다. 관련 파일을 브라우저로 보내면, 번들러가 의존성의 실제 번들링을 수행하게 한다. 전체 번들을 evaluating 하지 않고 일부만 evaluating 하기 때문에 더 빠르다.

이 접근 방식에는 독립적으로 의존성을 설치하고 캐시 할 수 있다는 큰 이점이 있다. 의존성 파일을 클라이언트에 merge 할 수 있다. 즉, 기존의 의존성 위에 새로운 종속성을 요청하면 새 종속성에 대한 파일만 수집하면 된다. 우리는 하나의 종속성만 설치하기 때문에, AWS Lambda 의 500MB 제한을 해결한다. 이제 packager 는 어떤 파일이 관련성이 있는지 알아내고 전송해야 할 책임이 있기때문에 packager 에서 웹팩을 삭제할 수도 있다.

참고 : 패키저를 삭제하고 unpkg.com 에서 모든 파일을 동적으로 요청할 수도 있다. 이것은 아마도 앞서 말한 새로운 접근법보다 훨씬 빠르다. 하지만 우리는 오프라인 지원을 제공하고 싶기 때문에, 패키저 (적어도 편집기의 경우)를 계속 유지하기로 결정했다. 가능한 모든 관련 파일이있는 경우에만 가능하다.

How it works in practice

종속성 조합을 요청하면 먼저이 조합이 S3에 저장되어 있는지 확인합니다. S3에 없으면 API 서비스에서 조합을 요청합니다. 이 서비스는 모든 종속성에 대해 모든 패키저를 독립적으로 요청합니다. 200 OK를 되찾자 마자 S3을 다시 요청합니다.

패키저는 yarn을 사용하여 종속성을 설치하고 진입 점 디렉토리에있는 모든 파일의 AST를 통과하여 모든 관련 파일을 찾습니다. require 문을 검색하여 파일 목록에 추가합니다. 이것은 재귀 적으로 발생하므로 의존성 그래프를 얻습니다.

Advatages

Save in cost

이틀 전에 새로운 패키지를 배포했고, 그동안 $0.02 를 지불했다. 그리고 이것은 캐시를 구축하기위한 것이다. 이는 한 달에 $100달러 에 정도 크게 절약된다.

Higher performance

이제 모든 조합에 대해 3초 이내에 새로운 종속성 조합을 얻을 수 있다. 기존 시스템에서는 때때로 1분이 소요된다. 조합이 캐시되면 연결이 빠른 상태에서는 50ms 이내에 얻을 수 있다. Amazon Cloudfront 를 사용하여 의존성을 캐시한다. 프로젝트에 대한 관련 JS 파일만 파싱하고 실행하기 때문에 프로젝트도 더 빠르게 실행된다.

More flexibility

번들러는 이제 로컬 파일인 것처럼 의존성을 처리한다. 즉, 오류 스택 추적이 훨씬 명확해졌으며 이제 .scss, .vue 등과 같은 의존성으로 부터 모든 파일을 포함할 수 있으며, 별칭과 같은 항목을 쉽게 지원할 수 있다. 의존성이 로컬에 설치된 것처럼 작동한다.

Release

이틀 전에 캐시를 구축하기 위해 이전 패키지와 함께 새로운 패키지를 사용하기 시작했다. 이미 2,000개의 서로 다른 조합과, 1400개의 서로 다른 종속성을 캐시했다. 실제로 이동하기 전에, 새 버전을 광범위하게 테스트하고 싶었다.

또한 소스에 관심이있는 경우 여기에서 찾을 수 있다.

Go Serverless!

serverless 에 깊은 인상을 받았기 때문에 서버 확장성과 관리가 매우 쉬워졌다. 항상 serverless 에서 나를 방해하는 유일한 것은 매우 복잡한 설정이지만, serverless.com 의 사람들은 이것을 어린이도 할 수 있게 만들었다. 그들의 작업에 매우 감사하며, serverless 는 많은 다른 응용 프로그램 양식의 미래라고 생각한다.

Future

우리는 여전히 많은 방법으로 시스템을 개선 할 수 있다. 나는 embede 에서 요구를 동적으로 요청하고, 오프라인을 보존하기 위해 노력하고 싶다. 유지하기 어려운 균형이지만 가능해야한다. 브라우저가 허용하는 내용에 따라, 브라우저에서 독립적으로 의존성 캐싱을 시작할 수도 있다. 이 경우 다른 의존성 조합을 사용하여 새 프로젝트를 방문할 때 새 의존성을 다운로드하지 않아도 된다. 나는 또한 의존성 해결을 더 탐구 할 것이다. 완전해지기 전에 해결하려는 새로운 시스템과 버전이 충돌할 가능성도 있다.

그럼에도 불구하고 CodeSandbox의 새로운 작업을 진행하면서 새 버전에 매우 만족한다.

CodeSandbox의 가장 많은 활동이 여기 있다.