Cloudflare 작업자의 Astro

Update: Astro now ships an official cloudflare integration, you should probably use that instead :)

Cloudflare의 플랫폼 주간입니다. 이와 함께 Wrangler 2.0 beta의 릴리스와 같은 모든 종류의 혜택이 제공됩니다. 새로운 기능에 관심이 있으십니까? Sunil Pai는 여기에 모든 것을 썼습니다: 10 things I love about Wrangler v2.0 .

또한 Astro는 최근 server-side rendering Astro apps에 대한 실험적 지원을 발표했습니다.

이 두 가지를 결합하고 광고에 뛰어들어 Astro용 Cloudflare Worker 어댑터를 만들기에 더할 나위 없이 좋은 때입니다. 이 어댑터를 만드는 동안 나는 약간 곁길로 갔습니다. 서비스 작업자와 매우 유사한 환경인 Cloudflare 작업자용 Astro 어댑터를 만들 수 있다면 서비스 작업자에서 Astro를 실행할 수 없는 이유는 무엇입니까? 🤯. 당신은 완전히 할 수 있고 그 분야에 대한 나의 미친 실험에 대해 모두 썼습니다. SWSR(Service Worker Side Rendering)을 통한 streaming future에 대해 기대하고 있습니까? 나는 알아!

시작하기

먼저 다음을 사용하여 Astro 프로젝트를 스캐폴드합니다.

npm init astro@latest

다음으로 몇 가지 종속성을 설치해야 합니다. 새로운 랭글러 CLI 및 Cloudflare Worker 어댑터:

npm install -D wrangler
npm install -S astro-service-worker

설치가 완료되면 어댑터를 astro.config.mjs에 추가합니다.

import { defineConfig } from 'astro/config';
import worker, { cloudflare } from 'astro-service-worker/adapter';

export default defineConfig({
  adapter: worker(cloudflare)
});

이제 다음을 실행하여 프로젝트를 빌드할 수 있습니다.

npm run build

아직 wrangler.toml 파일이 없는 경우 빌드 중에 어댑터가 파일을 생성합니다. 가지고 있는 경우 main 및 bucket 속성이 올바른 위치를 가리키도록 해야 합니다. 다음은 속성의 예입니다.

name = "my-project"
main = "dist/worker/index.js" # The adapter will output the worker in this location
compatibility_date = "2022-05-10"

[site]
bucket = './dist' # The adapter will output static assets in this folder

모든 설정이 완료되면 이제 앱을 배포할 수 있습니다.

wrangler publish

사방에 노동자

cloudflare() 어댑터를 배송하는 대신 astro-service-worker가 미리 설정된 개체를 사용하는 worker() 어댑터를 배송한다는 사실을 눈치채셨을 것입니다. 많은 다른 공급자와 조직이 작업자와 같은 환경을 수용하는 것으로 보이며 심지어 Community Group for web-interoperable JavaScript runtimes을 설정하기 위해 힘을 합쳤으며 심지어 Ryan Dahl(Node/Deno의 작성자)도 최근 유사한 미래에 대해 블로그에 올렸습니다.

이러한 종류의 표준화는 훌륭하며 worker() 어댑터는 여러 작업자와 유사한 환경과 호환되도록 구축되었습니다. 사실로; 브라우저에서 실행되도록 의도된 클라이언트 측 서비스 작업자 통합과 동일한 서비스 작업자 진입점을 사용합니다.

자바스크립트 컨테이너 Shim 환경별 세부 정보

이러한 환경의 대부분은 fetch 및 Response 등과 같은 API를 지원하는 이벤트 처리 방식에서 동일한 기본 사항을 지원하므로 worker() 어댑터를 모듈식으로 만드는 것이 좋습니다. 그러나 예를 들어 정적 파일이 처리되는 방식이나 폴리필링과 같은 환경별 세부 정보와 제공자 간의 차이점이 여전히 있을 수 있습니다.

이른바 사전 설정 개체에서 이러한 것들을 처리할 수 있습니다. 사전 설정 개체는 환경별 폴리필/shim을 가리키는 모듈 지정자의 배열인 선택적shim 배열과 환경별 구성 파일을 설정하는 데 사용할 수 있는 선택적initConfig 함수를 사용합니다. wrangler.toml Cloudflare의 경우.

예를 들어 cloudflare 사전 설정에는 다음 shim이 포함됩니다.cloudflare/static-assets.js :

import { getAssetFromKV } from '@cloudflare/kv-asset-handler';

self.MIDDLEWARE.push(async (event) => {
  try {
    return await getAssetFromKV(event);
  } catch {}
});

That's all the cloudflare-specific logic required!

자신의 작업자와 같은 환경을 지원하는 데 관심이 있는 경우 사전 설정을 쉽게 만들고 다음과 같이 환경별 코드를 제공할 수 있습니다.

const myEnvironment = {
  /** Polyfill environment specific handling */
  shim: ['my-environment/static-assets.js'],
  /** Scaffold environment specific configuration file, like for example `wrangler.toml` */
  initConfig: (dir) => {}
}

worker(myEnvironment);

자세한 내용은 을 참조하십시오.

선적 서류 비치 오프라인

또한 serviceWorker 통합을 추가하여 이 통합을 결합하고 완전 작업자가 될 수 있습니다.

import { defineConfig } from 'astro/config';
import worker, { cloudflare } from 'astro-service-worker/adapter';
import serviceWorker from 'astro-service-worker';

export default defineConfig({
  adapter: worker(cloudflare),
  integrations:[
    serviceWorker()
  ]
});

이제 Astro SSR 앱은 처음에 Cloudflare Worker에 의해 렌더링된 다음 완전히 Service Worker에서 렌더링됩니다!