แบ็กเอนด์อิสระ: รายละเอียดการทำงาน
แบ็กเอนด์อิสระที่สร้างขึ้นประกอบขึ้นอย่างไร: ไฟล์ที่มี แพ็กเกจที่ใช้ ทรัพยากร Cloudflare ที่ใช้ วิธีแปลงเนื้อหาเป็นตาราง managed renderer ที่ export และแคชการตอบกลับ ส่วน route การยืนยันตัวตน และการดีพลอย ดู เอกสารอ้างอิง API
โครงสร้างไฟล์ที่สร้างให้
หัวข้อที่มีชื่อว่า “โครงสร้างไฟล์ที่สร้างให้”โครงสร้างนี้ย่อไว้ แสดงไฟล์หลัก ไม่ใช่ทุกไฟล์ที่สร้าง
.├── package.json├── .nvmrc / .npmrc├── wrangler.jsonc / wrangler.example.jsonc / wrangler.build.jsonc├── graduation.manifest.json / graduation.generator.json├── .dee-wan-files.json / .dee-wan-customization.json├── prisma/schema.prisma├── migrations/├── access/read-tokens.json├── data/published-snapshot.json│ (data/media-manifest.json after a media transfer)├── src/│ ├── app.ts / worker.ts / access.ts / access-policy.ts / auth.ts / security.ts / db.ts│ ├── access-config-rules.js / access-config-rules.d.ts / credential-digest.ts│ ├── response-cache.ts / query-manifest.ts / trusted-routes.ts / relation-routes.ts│ ├── sqlite-batch.ts / d1-column-types.ts / d1-schema-columns.ts│ ├── backend-customization.ts / backend-config.ts / customization-runtime.ts│ ├── local.ts / serve.ts / serve-cli.ts / migrate.ts│ ├── generated/prisma/ / generated/guard/ / generated/routes/│ └── owned/backend.ts / owned/routes.ts├── scripts/│ ├── dee-wan-generator.mjs / regenerate.mjs / check-customization.mjs│ ├── install-dependencies.mjs / emit-migration.mjs / portable-client.mjs│ ├── load-snapshot.mjs / configure-deployment.mjs / file-manifest.mjs│ ├── check-relation-ids.mjs / deploy-from-repository.mjs│ └── verify-deployment.mjs / verify-media.mjs├── .github/workflows/deploy-from-repository.yml│ (site artifacts additionally carry dee-wan-build.yml, the managed│ build contract; a `--model` artifact has no CMS-managed site build)├── managed-renderer/│ (only when the site had an active managed renderer release)│ ├── package.json / package-lock.json / astro.config.mjs / tsconfig.json│ ├── wrangler.jsonc / public/ / worker/ / src/│ └── release/release.json / template.json / route-map.json / site-chrome.json│ / managed-renderer.mjs / evidence/└── apps/site/ ├── package.json / wrangler.jsonc / astro.config.mjs / public-reads.json ├── public/.assetsignore └── src/ ├── lib/ / pages/ / components/ ├── lib/image-endpoint.ts ├── owned/ └── pages/owned/ไฟล์ generated มีค่า fingerprint กำกับและถูกสร้างใหม่ การแก้ไขจะทำให้การสร้างใหม่ครั้งถัดไปถูกปฏิเสธ ไฟล์ owned สร้างเป็นโครงเริ่มต้นเมื่อไม่มีเท่านั้นและรักษาทุกไบต์ ไฟล์ shared ถูกเก็บไว้ โดย manifest ของแพ็กเกจรวมเฉพาะส่วนที่ขาด ประวัติ migration เพิ่มต่อท้ายเท่านั้น ดูตารางพาธที่แน่นอนใน คู่มือการปรับแต่ง
ชื่อแพ็กเกจใหม่เป็น graduated-site- ตามด้วย ID เว็บไซต์ UTF-8 ที่เข้ารหัสเป็นเลขฐานสิบหกตัวพิมพ์เล็ก ชื่อคงเดิมเมื่อเรียง เพิ่ม หรือลบโมเดล ชื่อแพ็กเกจและ README เดิมของเจ้าของถูกเก็บไว้
เทคโนโลยีและรายการแพ็กเกจ
หัวข้อที่มีชื่อว่า “เทคโนโลยีและรายการแพ็กเกจ”Hono จัดการ HTTP ส่วน Prisma ใช้ query compiler และ D1 adapter ใน API Worker prisma-generator-express สร้างขั้นตอน CRUD ของ Hono และ OpenAPI และ prisma-guard บังคับรูปแบบ query เซิร์ฟเวอร์ในเครื่องใช้ better-sqlite3 adapter ส่วน eav-to-prisma แปลงโมเดล CMS ที่ยอมรับแล้วระหว่างการสร้าง Generator ถูกแนบเป็นสคริปต์บิลด์ที่ตรึง digest ด้วย ไม่ใช่บริการ CMS ระหว่างรัน
รายการต่อไปนี้ตรวจเทียบกับ ARTIFACT_TOOLCHAIN_PACKAGES, SITE_MANIFEST และค่าคงที่ของตัวติดตั้ง เวอร์ชันใน root มาจากระบบที่สร้างจริงและ graduation.manifest.json.toolchain เอกสารไม่ได้สมมติเวอร์ชันที่ติดตั้ง ทุกรายการใน root ตรึงเวอร์ชันแน่นอน ส่วนเว็บไซต์ยอมรับช่วงที่ระบุและล็อกผลใน lockfile ของตัวเอง
| Install root | Package | Package block | Version authority |
|---|---|---|---|
root |
@dee-wan/cache |
dependencies |
toolchain.responseCache (exact) |
root |
@prisma/adapter-d1 |
dependencies |
toolchain.prismaAdapterD1 (exact) |
root |
@prisma/client |
dependencies |
toolchain.prismaClient (exact) |
root |
hono |
dependencies |
toolchain.hono (exact) |
root |
yaml |
dependencies |
toolchain.yaml (exact) |
root |
prisma-generator-express |
dependencies |
toolchain.prismaGeneratorExpress (exact) |
root |
prisma-guard |
dependencies |
toolchain.prismaGuard (exact) |
root |
jsonc-parser |
dependencies |
toolchain.jsoncParser (exact) |
root |
@cloudflare/workers-types |
devDependencies |
toolchain.workersTypes (exact) |
root |
eav-to-prisma |
devDependencies |
toolchain.eavToPrisma (exact) |
root |
@prisma/adapter-better-sqlite3 |
devDependencies |
toolchain.prismaAdapterBetterSqlite3 (exact) |
root |
@types/node |
devDependencies |
toolchain.nodeTypes (exact) |
root |
better-sqlite3 |
devDependencies |
toolchain.betterSqlite3 (exact) |
root |
esbuild |
devDependencies |
toolchain.esbuild (exact) |
root |
prisma |
devDependencies |
toolchain.prisma (exact) |
root |
typescript |
devDependencies |
toolchain.typescript (exact) |
root |
wrangler |
devDependencies |
toolchain.wrangler (exact) |
apps/site |
@astrojs/cloudflare |
dependencies |
^12.6.3 |
apps/site |
@tailwindcss/vite |
dependencies |
^4.1.14 |
apps/site |
astro |
dependencies |
^5.14.1 |
apps/site |
tailwindcss |
dependencies |
^4.1.14 |
apps/site |
@astrojs/check |
devDependencies |
^0.9.5 |
apps/site |
@emnapi/runtime |
devDependencies |
^1.11.3 |
apps/site |
typescript |
devDependencies |
^5.9.3 |
แพ็กเกจ runtime ใน root ให้ D1 adapter/client, Hono, guard, ตัวช่วยของ route และการแปลง OpenAPI เป็น YAML แพ็กเกจ development ให้ชนิดข้อมูล Worker/Node การแปลงโมเดล SQLite ในเครื่อง การสร้าง/migration Prisma การตรวจ TypeScript การบันเดิล esbuild และ Wrangler แพ็กเกจ SQLite ในเครื่องเป็น development dependency แม้เซิร์ฟเวอร์ในเครื่องใช้ขณะรัน Dependencies ของเว็บไซต์มี Astro, Cloudflare adapter, Tailwind และ Vite integration ส่วน development มีตัวตรวจ Astro และ TypeScript
Root ระบุ Node >=22 แต่ .nvmrc ที่สร้างให้เลือก 24.18.1 และ packageManager เลือก npm@11.16.0 ค่า .nvmrc และตัวจัดการแพ็กเกจเดิมถูกเก็บไว้ ตัวติดตั้งที่ตรวจสอบแล้วจึงยังตรวจว่า npm ที่เลือกตรงกับค่าประกาศ Prisma CLI และ client ต้องใช้ major 6 ที่รองรับ อย่าสรุปความเข้ากันได้จากช่วง Node ที่กว้างเพียงอย่างเดียว
node scripts/install-dependencies.mjsnode scripts/install-dependencies.mjs apps/siteตัวติดตั้งที่ตรวจสอบแล้วแตกแพ็กเกจโดยปิดสคริปต์ ตรวจ lifecycle รวมถึง native build และ rebuild เฉพาะแพ็กเกจที่อนุญาต การอนุญาต allowScripts ระบุเวอร์ชันแน่นอน ส่วนการปฏิเสธใช้ชื่อแพ็กเกจได้ สิทธิ์ใน root มาจาก Prisma engines/CLI, better-sqlite3, esbuild และคู่ Wrangler/workerd ที่รู้จักซึ่งถูกตรึงไว้ ไม่อนุญาตการสร้าง Prisma client อัตโนมัติและ fsevents เว็บไซต์มีรายการอนุญาตที่ตรวจแล้วของตัวเอง เวอร์ชัน lifecycle ที่ไม่รู้จักต้องตรวจใหม่ การเปลี่ยน dependency ไม่ได้ให้สิทธิ์รันสคริปต์ และไม่มีการติดตั้ง Git hook
ชนิดผลลัพธ์ของ D1
หัวข้อที่มีชื่อว่า “ชนิดผลลัพธ์ของ D1”Worker อ่านชนิดของผลลัพธ์ D1 ผ่าน src/d1-column-types.ts และไฟล์ของเว็บไซต์ src/d1-schema-columns.ts D1 adapter เดาชนิดของคอลัมน์จากค่าแรก ข้อความที่ดูเหมือนวันที่จึงทำให้ทั้งคอลัมน์กลายเป็นวันที่ได้ raw query ($queryRaw*) จะได้คอลัมน์แบบนี้เป็นข้อความเฉพาะเมื่อข้อความ SQL พิสูจน์ได้ว่าคอลัมน์เป็น String:
- แหล่งแถวทุกแหล่งเป็นตารางที่ schema ประกาศไว้ แหล่งแถวอ่านจากหลัง
FROM,JOINทุกชนิด,UPDATE,INTOและหลังจุลภาคแต่ละตัวในรายการFROMรวมถึงหลังONหรือUSINGในทุกระดับ ตารางอาจอยู่ในเครื่องหมายคำพูด มีmain.นำหน้า และมี alias ได้ subquery นับผ่านตารางที่อยู่ข้างใน - มีอย่างน้อยหนึ่งแหล่งที่ประกาศคอลัมน์นั้น และทุกแหล่งที่ประกาศคอลัมน์นั้นประกาศเป็น
String - ไม่มีรายการ select หรือ
RETURNINGใดตั้งชื่อนั้นให้สิ่งอื่นนอกจากคอลัมน์เดียวกัน (x,t.x,x AS x) - คำสั่งไม่มี
UNION,INTERSECTหรือEXCEPT
กรณีอื่นทั้งหมดคงชนิดที่ adapter เดาไว้: ตารางที่ schema ไม่ได้ประกาศ, CTE, table-valued function, schema อื่น, รายการ VALUES, alias, expression, compound select และคำสั่งที่ไม่มีตาราง การตรวจนี้อ่านชื่อตารางและคอลัมน์จากข้อความ SQL และไม่อนุมานชนิดของ SQL expression
ทรัพยากรและการตั้งค่า Cloudflare
หัวข้อที่มีชื่อว่า “ทรัพยากรและการตั้งค่า Cloudflare”| รายการ | ที่มาหรือหน้าที่ |
|---|---|
| API Worker | บิลด์ด้วย nodejs_compat และดีพลอยจาก commit ที่เลือก |
ฐานข้อมูล D1 และ binding DB |
ระบุตามตัวตนเว็บไซต์ สร้างเมื่อยังไม่มี Migration และการโหลด snapshot ใช้ฐานนี้ |
SITE_ID, ACCESS_CONFIG, GIT_SHA |
ตัวแปร Worker สำหรับตัวตนเว็บไซต์ digest/ขอบเขต read token และ commit ที่ดีพลอย ACCESS_CONFIG คือการรวมกันของ token ที่ CMS ออกให้ (access/read-tokens.json) กับ vars.ACCESS_CONFIG จาก wrangler.jsonc ของคุณ หรือรายการ token ว่างที่ถูกต้องเมื่อไม่มีเลย |
API_BEARER_TOKEN |
อย่างน้อย 32 ตัวอักษร เป็น secret ของรีโพซิทอรีที่ติดตั้งเป็น secret สำหรับเขียนของ API Worker ห้าม commit |
CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID |
Secrets ของ GitHub Actions สำหรับดีพลอย ไม่ใช่ข้อมูลรับรอง runtime ของ CMS |
PUBLIC_HOSTNAME |
ตัวแปรรีโพซิทอรี ระบุ hostname เปล่าสำหรับตรวจดีพลอย |
| Worker/assets ของ Astro | บิลด์จาก apps/site บันเดิลด้วย wrangler deploy --dry-run ก่อนที่การสร้างจะรับไซต์และก่อนเปลี่ยนทรัพยากรใด ๆ ของผู้ให้บริการเป็นครั้งแรก แล้วดีพลอยหลังตรวจ API ไม่ใช้ nodejs_compat: รูปภาพส่งผ่านโดยไม่แปลง (imageService: 'passthrough') จึงไม่มี sharp ใน Worker /_image ตอบ 404 (src/lib/image-endpoint.ts) เพราะไซต์ไม่มีบริการรูปภาพ เซสชันใช้ไดรเวอร์ null Worker จึงไม่ต้องมี KV binding SESSION public/.assetsignore กัน _worker.js และ _routes.json ออกจาก assets สาธารณะ |
| พื้นที่สื่อของเจ้าของ | ต้องมีนิยาม R2/พื้นที่เก็บและ transfer manifest เมื่อย้ายสื่อ MEDIA_PUBLIC_ORIGIN ระบุ origin ปลายทาง ไบต์สื่อไม่ใช่ไฟล์ซอร์ส |
| สิทธิ์ของ managed build | DEE_WAN_URL และ token ที่ผูกกับเว็บไซต์/เวอร์ชันอยู่ใน CI ที่ระบบจัดการ การดีพลอยจากรีโพซิทอรีอย่างเดียวไม่ดึงนิยาม CMS |
wrangler.jsonc เป็นการตั้งค่าในเครื่องแบบ shared ส่วน wrangler.build.jsonc สร้างสำหรับบันเดิล การดีพลอยสร้าง wrangler.deploy.jsonc จากข้อมูลเว็บไซต์/ฐานข้อมูล/สื่อที่ตรวจแล้ว Binding ที่เพิ่มในไฟล์ shared ไม่ได้ถูกจัดเตรียมหรือคัดลอกไปยังการตั้งค่าดีพลอยอัตโนมัติ ให้กำหนดขั้นตอนจัดเตรียม/ดีพลอยใน workflow เพิ่มเติมของคุณเอง ไฟล์ตัวอย่างไม่มีข้อมูลรับรองบัญชี ID ฐานข้อมูลจริง หรือ route ของ production
เนื้อหา ตาราง และการแปลงข้อมูล
หัวข้อที่มีชื่อว่า “เนื้อหา ตาราง และการแปลงข้อมูล”เวอร์ชันที่เผยแพร่กลายเป็นแถว ส่วนร่าง การเปลี่ยนแปลงที่ยังไม่เผยแพร่ ประวัติ ผู้ใช้ role session ข้อมูลรับรอง และรายการตรวจทาน/ตรวจสอบยังอยู่ใน Dee Wan Slug ของโมเดลสร้าง Prisma model แบบ PascalCase และตาราง/คอลัมน์ SQL ที่จับคู่ไว้ id รักษาตัวตนรายการเดิม
ฟิลด์ที่แปลได้อยู่ในตารางแปล เชื่อมกับแถวหลักและภาษา ความสัมพันธ์แบบหนึ่งเป้าหมาย (oneToOne, manyToOne) รักษา ID ของเป้าหมายในคอลัมน์ scalar <field>_id ความสัมพันธ์แบบรายการ (manyToMany, oneToMany) ใช้ตารางเชื่อมพร้อมตำแหน่งเรียง โดยโมเดลที่ประกาศฟิลด์เป็นเจ้าของ ตารางเชื่อมแบบ one-to-many ทำให้คอลัมน์เป้าหมายไม่ซ้ำ: แต่ละเป้าหมายมีเจ้าของเดียวผ่านฟิลด์นั้น โมเดลเป้าหมายไม่ได้คอลัมน์และไม่ได้การเขียนสำหรับฟิลด์นั้น ผลลัพธ์แบบโมเดลเดียวไม่สร้างโมเดลเป้าหมายหรือข้อจำกัด SQL foreign key ขึ้นเอง และปฏิเสธความสัมพันธ์แบบรายการ ลิงก์พาเรนต์แบบลำดับชั้นชี้ไปยังโมเดลของตัวเอง จึงได้ foreign key ในทั้งสองแบบ ข้อความ/rich text ตัวเลข boolean และวันเวลาเป็นคอลัมน์ scalar ที่ตรงกัน JSON, multi-select และ component ใช้ JSON ตัวเลือก select เป็นข้อจำกัดใน manifest ไม่ใช่ enum ของฐานข้อมูล ฟิลด์ที่อนุญาตหลายโมเดลมีหนึ่งตารางเชื่อมต่อโมเดลที่อนุญาต แต่ละตารางมี foreign key ไปยังโมเดลของตน และใช้ลำดับรายการของเจ้าของร่วมกันผ่าน position ฟิลด์หนึ่งเป้าหมายแบบผสมเก็บแบบเดียวกัน
ในผลลัพธ์ทั้งไซต์ ID ความสัมพันธ์ทุกตัวเป็น foreign key และการลบทำงานแบบเดียวกับ CMS:
| การอ้างอิง | เมื่อแถวเป้าหมายถูกลบ |
|---|---|
ความสัมพันธ์หนึ่งเป้าหมายที่ไม่บังคับ <field>_id |
คอลัมน์กลายเป็น null |
ความสัมพันธ์หนึ่งเป้าหมายที่บังคับ <field>_id |
การลบถูกปฏิเสธด้วย 409 relation_target_referenced พร้อมชื่อโมเดลและคอลัมน์ |
| แถวในตารางเชื่อม | แถวลิงก์ถูกลบ รายการอาจมีน้อยกว่าขั้นต่ำจนกว่าจะเขียนใหม่ |
| แถวแปล | ถูกลบพร้อมแถวหลัก |
ID ความสัมพันธ์ภายในค่า JSON ของ component ไม่ใช่ foreign key ตัวอ่านข้อมูลถือว่า ID ที่ไม่มีแถวเป้าหมายตรงกันเป็นค่าที่ไม่มีอยู่ แบบเดียวกับ CMS
สื่อรักษาคอลัมน์ตัวตนและเพิ่ม URL การย้ายรีโพซิทอรีไม่ได้ย้ายไบต์สื่อ การย้ายสื่อแก้ URL ให้ชี้ไปยังพื้นที่ของเจ้าของ การตรวจดีพลอยปฏิเสธ URL ที่ยังเป็นของ Dee Wan โมเดลหน้าสร้าง route Astro จากหัวข้อและเอกสารหน้า โมเดลข้อมูลทั่วไปได้ API โดยไม่สร้างหน้าเว็บไซต์ขึ้นเอง
managed renderer ที่ถูก export
หัวข้อที่มีชื่อว่า “managed renderer ที่ถูก export”managed-renderer/ มีอยู่เฉพาะเมื่อการสร้างทั้งไซต์รันกับไซต์ที่มี managed renderer release ที่ใช้งานอยู่ เป็น export format 2 ใน generated zone: การสร้างเขียนมัน เก็บ fingerprint และตรึงไว้ใน graduation.manifest.json ใต้ managedRenderer การ regenerate แบบ managed ไม่เขียนทับมันเลย exportDigest ของการตรึงคือ SHA-256 ของ release/release.json ซึ่งเป็น canonical JSON ตามด้วยขึ้นบรรทัดใหม่หนึ่งครั้ง การสร้างตรวจ export จาก byte ของมันก่อนรับชุดไฟล์มาใช้ และปฏิเสธ identity ที่คำนวณซ้ำแล้วไม่ตรง, release/managed-renderer.mjs ที่ไม่ตรงทุก byte กับซอร์สคำสั่งที่ผลิตภัณฑ์รุ่นนี้สร้าง (managed_renderer_export_cli_mismatch), การตรึงที่อ่านไม่ได้ (managed_renderer_export_pin_invalid) และไดเรกทอรี managed-renderer ที่สะกดด้วยตัวพิมพ์ต่างกัน ไม่มีทางรองรับรูปแบบ export แบบเก่า ดูเทมเพลตแบบ managed
การสร้างเพิ่ม script ที่ root สามตัว แต่ละตัวถูกเพิ่มเฉพาะเมื่อยังไม่มี และไม่ถูกเขียนทับเลย
| Script | ทำอะไร |
|---|---|
managed-renderer:verify |
ตรวจการตรึงใน manifest และ release record แบบปิด; ตรวจว่าทุกไฟล์ใต้ managed-renderer/ ยกเว้นผลลัพธ์ build ที่ root ของมัน มีความยาวและ digest ตรงตามที่บันทึกไว้ มีขนาดไม่เกินขีดจำกัดต่อไฟล์ อยู่ใน path ที่ปลอดภัย และไม่มี path ซ้ำแม้ไม่สนตัวพิมพ์เล็กใหญ่; chunk ที่ compile แล้ว; digest ของ input, source, contract และ release; รายงาน gate ที่ผูกกับ release โดยทุก gate ที่บังคับผ่านตามลำดับ; template.json, route-map.json, site-chrome.json และ wrangler.jsonc; และไม่มี custody key หรือ local path ใน metadata ไม่ parse template manifest, provenance ของมัน หรือไวยากรณ์ของ route map ซ้ำ ตัวตรวจของการสร้างทำส่วนนั้น |
managed-renderer:build |
ตรวจ แล้วรัน npm ci --ignore-scripts, การตรวจ type และการ build ภายใน managed-renderer/ บนเครื่องนี้และใช้เครือข่ายสำหรับ npm ci ปฏิเสธ lockfile ที่ถูกเปลี่ยนหรือ toolchain อื่น ไม่รัน gate ของ contract, accessibility หรือ viewport ซ้ำ หลักฐานของ gate เหล่านั้นอยู่ใน release/evidence/report.json |
managed-renderer:prepare |
build แล้วรัน wrangler deploy --dry-run ไปที่ managed-renderer/.wrangler/deploy ไม่ deploy อะไร |
รันจาก root ของรีโพซิทอรี managed-renderer/ และ managed-renderer/release/ ต้องเป็นไดเรกทอรีจริง build และ prepare ลบ node_modules, dist, .astro และ .wrangler ที่ระดับบนสุดของ managed-renderer/ ก่อน และ unlink ลิงก์ที่นั่นโดยไม่ตามลิงก์ คำสั่งตั้ง ASTRO_TELEMETRY_DISABLED=1 และ WRANGLER_SEND_METRICS=false ไม่มีคำสั่งใดติดต่อ CMS
การแก้ script เก็บ byte อื่นทั้งหมดของ package.json ไว้: การขึ้นบรรทัด การเยื้อง byte order mark และการขึ้นบรรทัดท้ายไฟล์ เมื่อ manifest ก่อนหน้าตรึง export ไว้และการสร้างครั้งถัดไปไม่เขียน export แล้ว จะลบเฉพาะ script ที่ค่ายังตรงกับค่า canonical ทุกตัวอักษร ดังนั้นคำสั่งของคุณเองที่ใช้ชื่อเหล่านี้จะยังอยู่ การเพิ่มจะถูกปฏิเสธด้วย managed_renderer_scripts_unwritable และการลบด้วย managed_renderer_scripts_unremovable เมื่อ package.json ไม่ใช่ UTF-8 หรือไม่ใช่ JSON แบบเคร่งครัด, root หรือ scripts ไม่ใช่ object หรือระบุ scripts หรือ script ใดในสามตัวนี้ซ้ำสองครั้ง การเพิ่มยังถูกปฏิเสธเมื่อไม่มี package.json การลบจาก package.json ที่ไม่เคยระบุ script เหล่านี้จะไม่เปลี่ยนอะไร
workflow ที่สร้างให้ คือ deploy-from-repository.yml และ dee-wan-build.yml ที่เรียกมัน deploy เฉพาะ API Worker และ apps/site ไม่เคย build หรือ deploy managed-renderer/ wrangler.jsonc ของมันไม่ระบุ route ผู้ที่ deploy ต้องให้บริการที่ https:// บวก host ของ binding ที่ใช้งานอยู่ของไซต์ เพราะ release ถูกตรึงกับ origin นั้น renderer อ่านเนื้อหาที่เผยแพร่จาก /v1 ของ origin นั้นทุก request ดังนั้นการเผยแพร่ไม่ต้อง build ใหม่ และตอบ HTML ด้วย Cache-Control: no-store มันไม่มี service binding: wrangler.jsonc ของมันตั้ง PUBLIC_API_TRANSPORT เป็น "public" และเปิด compatibility flag global_fetch_strictly_public การอ่านนั้นจึงออกทาง HTTPS สาธารณะและถึง public Worker ผ่าน route /v1/* ของมัน
แคชการตอบกลับ
หัวข้อที่มีชื่อว่า “แคชการตอบกลับ”Worker ที่สร้างใช้แพ็กเกจเผยแพร่ @dee-wan/cache@1.0.1 และแคชการอ่านทุกโมเดลเป็นค่าเริ่มต้น สวิตช์รวมอยู่ที่ การตั้งค่า → ซอร์สโค้ดและการเผยแพร่ → การยืนยันตัวตน แคช และการเปิดเผยของ standalone ส่วนค่าของแต่ละโมเดลอยู่ที่หน้าโมเดล → Standalone API และเก็บตาม id ของโมเดลเหมือนนโยบายสิทธิ์ การอ่านและบันทึกสวิตช์รวมต้องมี site:infra หน้าโมเดลเปิดได้ด้วยสิทธิ์อ่านโมเดลนั้น site:settings หรือ site:infra การบันทึกในหน้านั้นต้องมี site:infra สวิตช์รวมและค่าแต่ละโมเดลอยู่ในอินพุตการสร้าง manifest และตัวระบุซอร์ส การเปลี่ยนเฉพาะแคชทำให้ artifact ล้าสมัย ต้องสร้างและดีพลอยใหม่ ค่าที่บันทึกไว้ซึ่งอ่านไม่ได้จะหยุดการสร้างจนกว่าจะแก้และบันทึก
การปิดแคชของโมเดลจะไม่นำการอ่านโมเดล คำแปล ตารางความสัมพันธ์ที่เกี่ยวข้อง และคำสั่งที่แตะโมเดลที่ปิดเข้าแคช แต่การเขียนยังอัปเดตแนวกั้นเมื่อแคชเปิด CACHE_ENABLED=false ปิดทั้งแคชการอ่านและแนวกั้นการเขียน ค่าอื่นที่ไม่ใช่ true หรือ false จะปฏิเสธทุกคำขอด้วย cache_switch_invalid เซิร์ฟเวอร์ไฟล์ SQLite ในเครื่องไม่แคช
Worker ส่งออก CacheCoordinator โดย Wrangler ทั้งตัวอย่าง การบิลด์ และการดีพลอยประกาศ binding CACHE_COORDINATOR และ migration SQLite Durable Object แต่ละ D1 ของ artifact ต้องมีชื่อ coordinator เดียวสำหรับทุกตัวเขียนและทุกเวอร์ชัน ห้ามใช้ชื่อร่วมกันระหว่าง D1 ต่างกัน สคริปต์ดีพลอยตั้ง CACHE_COORDINATOR_NAME จากตัวระบุ artifact และ D1 ที่ระบุได้ พร้อมรักษา binding migration และตัวแปรของเจ้าของที่เข้ากันได้ หากดีพลอยเองให้คงชื่อเดิม และเปลี่ยนชื่อเมื่อคัดลอกไปยัง D1 อื่น coordinator สองชื่อบน D1 เดียวจะไม่เห็นการเขียนของกันและกัน
Prisma 6.19.3 ใช้ส่วนขยาย guard ก่อน cache โดย guard ทำงานแม้อ่านพบในแคช อาร์กิวเมนต์ที่แก้แล้วเป็นส่วนของคีย์ หลังอนุญาตสิทธิ์ client แยกขอบเขตตาม principal รูปแบบสิทธิ์ URL เมธอด และ header ที่มีผลต่อผลลัพธ์รวมถึงภาษาและ tenant โดยตัดรหัสคำขอชั่วคราวออก ส่งเพียง digest ของขอบเขตแทนข้อมูลลับดิบ การตรวจยืนยันตัวตนอ่านโดยไม่แคช ไม่เพิ่มสิทธิ์โมเดลหรือ operation และไม่เรียก Dee Wan ขณะทำงาน
ก่อนเขียน D1 คำสั่ง data:load ต้องมีโทเค็นเขียนของ artifact และ PUBLIC_HOSTNAME หลังตรวจสอบแล้วว่าการโหลดถูก commit สำเร็จ จะเรียก endpoint สำหรับ service เท่านั้นซึ่งตรวจ ledger ของ snapshot แล้วเรียก $cacheInvalidate({ all: true }) หากล้างแคชไม่สำเร็จ คำสั่งต้องล้มเหลวแม้ commit ไปแล้ว การเรียกซ้ำด้วย snapshot เดิมจะลองล้างแคชอีกครั้ง D1 ในเครื่องต้องมี loopback CACHE_INVALIDATION_ORIGIN ด้วย ส่วนไฟล์ SQLite ไม่ต้องใช้ coordinator การเขียน SQL โดยตรงด้วยเครื่องมืออื่นต้องใช้ $cacheRawWrite หรือการล้างแคชหลัง commit ระหว่าง commit กับการล้างแคชอาจอ่านค่าเก่าได้ จึงควรหยุดทราฟฟิกระหว่างโหลดข้อมูลจำนวนมาก
generation ผูกกับ manifest และ epoch CACHE_GENERATION ที่ผู้ดูแลตั้งเพิ่มได้ เวอร์ชันที่เปิดแคชและใช้ generation ต่างกันร่วมกับ coordinator เดียวยังคงให้ผลถูกต้อง แต่จะล้างแคชและเริ่มเติมใหม่ซ้ำ ๆ ห้ามเวอร์ชันเปิดและปิดให้บริการพร้อมกันเพราะการเขียนขณะปิดไม่มีแนวกั้น หยุดและรอคำขอเดิมจบ ดีพลอยทุกตัวเขียนพร้อมกัน และล้างแคชหรือเปลี่ยน CACHE_GENERATION ก่อนเปิดอีกครั้งหลังมีการเขียนที่ไม่ผ่านแคช ห้ามทยอย rollout เมื่อเปลี่ยนโหมดรวม
ค่าเริ่มต้นคือ TTL สดหนึ่งชั่วโมงและพื้นที่ 1 GiB การอัปเดตเบื้องหลังใช้ ctx.waitUntil ถ้าไม่มีบริบทคำขอจะไม่อัปเดตเบื้องหลัง การอ่านพบใช้ DO หนึ่งครั้ง การอ่านไม่พบเพิ่มการอ่าน D1 และการเติมแคช การเขียนปกติใช้ DO สองครั้ง coordinator เดียวมีขีดจำกัดอ่อนประมาณ 1,000 คำขอต่อวินาทีและตั้งอยู่ตำแหน่งเดียว จึงอาจช้ากว่า D1 เมื่ออยู่ไกล หากแคชอ่านผิดพลาดจะอ่าน D1 หากขอสิทธิ์ถือครองสำหรับการเขียน (write lease) ไม่สำเร็จจะปฏิเสธการเขียน หากแนวกั้นหลังเขียนสูญหาย ค่าเก่าอาจคงอยู่จนหมด TTL หลัง lease หมดอายุ เมื่อต้องรับมือกับระบบขัดข้อง ให้ตรวจข้อกำหนดของแพ็กเกจนี้ด้วย
migration ของพื้นที่ DO ไปข้างหน้าเท่านั้น โค้ดเก่าปฏิเสธข้อมูลที่เก็บในรูปแบบใหม่รวมถึงการเขียน Prisma ต้องแก้ด้วยการอัปเดตโค้ดให้รองรับรูปแบบใหม่ การย้อนโค้ดไม่กู้ฐานข้อมูล พื้นที่แคช หรือสื่อ ต้องเก็บประวัติ migration ที่เข้ากันและข้อมูลสำรองของเจ้าของ
ขั้นตอนถัดไป
หัวข้อที่มีชื่อว่า “ขั้นตอนถัดไป”กลับไปที่ แบ็กเอนด์อิสระ: ภาพรวม หรืออ่านต่อที่ คำศัพท์ผลิตภัณฑ์ และหน้าอ้างอิงอื่น ๆ
ยังไม่เปิดตัว (pre-MVP) และยังไม่มีเวอร์ชันเสถียร
คอมมิตซอร์สโค้ด: fe23db481c422b40e317b92fc98116b4c0c26a87 (มีการแก้ไขที่ยังไม่คอมมิต)
วันที่สร้างเอกสาร (UTC): 2026-10-18T09:22:34.630Z
คอมมิตสำหรับอัปเกรด: ระบุไม่ได้: มีการแก้ไขที่ยังไม่คอมมิต. บันทึกการเปลี่ยนแปลง