สัญญาการแยกตัว

แบ็กเอนด์อิสระ คือ repository ที่ Dee Wan สร้างจาก model และเนื้อหาที่เผยแพร่แล้วของไซต์ หน้านี้บอกว่าคุณวางใจอะไรได้เมื่อมีมันแล้ว และจะเกิดอะไรขึ้นหากคุณหยุดใช้ Dee Wan

สถานะ: ข้อรับประกันทั้งหมดด้านล่างมีการทดสอบอัตโนมัติบนเครื่องนักพัฒนาครอบคลุมแล้ว แต่ยังไม่มีข้อใดได้รับการตรวจยืนยันบนการดีพลอยจริงของ Cloudflare และยังไม่มีตัวเลขประสิทธิภาพ

ลำดับงานของผู้ดูแล การแยกข้อมูลยืนยันตัวตน และคำสั่งตรวจรับอยู่ในคู่มือการแยกระบบ ซึ่งรวม verify:deployment กับ verify:media โดยไม่ถือว่าการตรวจในเครื่องคือการตรวจรับบนคลาวด์จริง

สิ่งที่คุณได้รับ

การรับประกัน	ความหมายสำหรับคุณ
คุณเป็นเจ้าของ repository	โปรเจกต์ถูกเขียนลงในไดเรกทอรีและ GitHub repository ที่คุณระบุ
คุณเป็นเจ้าของฐานข้อมูล	ฐานข้อมูล D1 ถูกสร้างในบัญชี Cloudflare ของคุณ การสร้างเขียนลงเฉพาะฐานข้อมูลนั้น
คุณเป็นเจ้าของ deployment และ credential ของมัน	โปรเจกต์มีการตั้งค่า Wrangler และสคริปต์ deploy ของตัวเอง API ของมันรับ bearer สำหรับเขียน API_BEARER_TOKEN read token ที่อยู่ใน ACCESS_CONFIG และเมื่อเปิดการยืนยันตัวตนแบบ standalone ก็รับ session จาก Better Auth ของมันเอง
ตารางจริง	content model แต่ละตัวกลายเป็นตารางที่มีคอลัมน์แบบมี type พร้อม index สำหรับฟิลด์ที่ใช้เรียง สถานะการเผยแพร่ และความสัมพันธ์
migration ที่ตรวจทานได้และเพิ่มต่อท้ายอย่างเดียว	การเปลี่ยน schema เพิ่ม migration ใหม่ต่อจากที่ apply ไปแล้ว migration ที่ apply แล้วจะไม่ถูกเขียนใหม่
route ที่คุ้นเคย	route สร้างด้วย prisma-generator-express และทำตาม semantics ของ model และ query แบบ Prisma
API ไม่เรียก Dee Wan	Worker ของ API อ่านเฉพาะฐานข้อมูล D1 ของตัวเอง ไม่เรียก Dee Wan เลย และไม่ขึ้นกับบัญชี uptime หรือโครงสร้างพื้นฐานของมัน แต่ route บางตัวของเว็บไซต์ยังเรียก Dee Wan: ดู สิ่งที่ยังขึ้นกับ Dee Wan
โค้ดของคุณคงอยู่หลังสร้างใหม่	ไฟล์ใต้ src/owned/ ถูกเขียนครั้งเดียวและไม่ถูกแตะอีก
ข้อมูลของคุณคงอยู่หลังสร้างใหม่	แถวที่คุณเขียนลงตารางของคุณเองถูกเก็บไว้เมื่อ schema เปลี่ยน
คุณเลิกใช้ได้	deploy-from-repository.yml deploy commit ได้โดยไม่ต้องใช้ Dee Wan การ regenerate ต้องใช้ definitions.json ที่คุณเก็บไว้ ดู การหยุดใช้

ไฟล์ในแบ็กเอนด์อิสระ แบ่งเป็นสาม โซนความเป็นเจ้าของ: generated (ถูกเขียนใหม่ทุกครั้ง ที่ regenerate), owned (src/owned/ ไม่ถูกเขียนทับ) และ shared (เขียนครั้งเดียว แล้วเป็นของคุณ) กฎฉบับเต็มอยู่ใน การขยายแบ็กเอนด์ของคุณ

สิ่งที่ยังขึ้นกับ Dee Wan

API กับเว็บไซต์เป็นคนละส่วนกัน หน้าที่ build แบบ static มาจาก pages.json ที่ commit ไว้ และไม่ต้องใช้อะไรจาก Dee Wan ส่วน route ของเว็บไซต์ต่อไปนี้ติดต่อ Dee Wan ทุกครั้งที่มีคำขอ:

route หรือฟีเจอร์	สิ่งที่อ่านหรือส่ง	ผู้ตอบ
route ของ Blog และ RSS feed ของ Blog	โพสต์ที่เผยแพร่แล้วจาก /v1 บนโฮสต์ของไซต์เอง	public Worker ของ Dee Wan
ส่วนของ sitemap สำหรับ Blog	/v1/_sitemap	public Worker ของ Dee Wan
หน้าค้นหา และหน้าที่มีส่วน «รายการล่าสุด» หรือ «ค้นหาในเว็บไซต์»	/v1 และ /v1/_search	public Worker ของ Dee Wan
หน้าของ model ที่รับความคิดเห็นจากผู้เยี่ยมชม	ความคิดเห็นจาก /v1/_comments ความคิดเห็นใหม่และ reaction ถูกส่งไปที่ /v1/interactions/*	public Worker และ intake Worker ของ Dee Wan
ส่วนฟอร์ม	การส่งฟอร์มไปที่ /v1/interactions/form.submit	intake Worker ของ Dee Wan โดย admin Worker เป็นผู้ส่งต่อ
/preview	draft จาก previewApiOrigin	public API ของ Dee Wan เฉพาะขณะที่ตั้งค่าไว้
managed renderer ที่ export ออกมา หากคุณ deploy มัน	/v1 ทุกครั้งที่มีคำขอ	public Worker ของ Dee Wan

บน route เหล่านี้ rich text ที่มี embed หรือบล็อกของปลั๊กอินจะอ่าน /v1/_embeds หรือ /v1/_rich-blocks ด้วย เนื้อหาของส่วน «รายการล่าสุด» ภายในส่วนที่ใช้ร่วมกันซึ่งแสดงในพื้นที่ของหน้าเว็บจะถูกตรึงไว้ตอนสร้าง และส่วนนี้จะไม่อ่านข้อมูลระหว่างประมวลผลคำขอ

การเผยแพร่หรือยกเลิกการเผยแพร่ใน CMS ไปถึง route เหล่านี้ทันที แต่ไม่เปลี่ยน API แบบ standalone หรือหน้าที่ build แบบ static จนกว่าคุณจะ regenerate และ deploy

การปลดระวางการติดตั้ง Dee Wan ทำให้ทุก route ในตารางหยุดทำงาน ตรวจ รายการก่อนปลดระวาง CMS ก่อน

สองเรื่องที่ต้องรู้

snapshot ที่เปลี่ยนไปจะแทนที่ตารางเนื้อหาที่สร้างขึ้น ทุก deployment รัน data:load เมื่อ snapshot ที่ commit ไว้ต่างจาก snapshot ที่โหลดเข้าฐานข้อมูลนั้นครั้งล่าสุด การโหลดจะลบ ทุกแถวของแต่ละตารางที่ snapshot เป็นเจ้าของ แล้วเขียนแถวของ snapshot ลงไป แถวที่ไม่มีใน snapshot จะหายไป ไม่ว่าใครเป็นผู้เขียน และจะไม่มีการปฏิเสธ สิ่งนี้เกิดหลังการ regenerate และหลัง rollback ไปยัง commit ที่มีเนื้อหาอื่น การโหลด snapshot เดิมซ้ำไม่เปลี่ยนอะไร ตารางที่ generator ไม่ได้สร้างไม่อยู่ใน snapshot และไม่ถูกแตะเลย เก็บข้อมูลของคุณเองไว้ในตารางของคุณเอง ด้วย migration ของคุณเอง

การทำให้ฟิลด์ที่มีอยู่แล้วเป็นฟิลด์บังคับต้อง backfill ก่อน การสร้างตารางขึ้นใหม่จะล้มเหลวหากมีแถวที่ค่าเป็น NULL และการรันจะปฏิเสธแทนที่จะทำข้อมูลหาย เติมค่าที่ว่างก่อน แล้วจึงทำให้ฟิลด์นั้น เป็นฟิลด์บังคับ

การอัปเดตไปถึงมันอย่างไร

มีสองสิ่งที่แยกกันเกี่ยวข้อง:

• build webhook ตั้งค่าใน Dee Wan ที่ การตั้งค่า → ซอร์สโค้ดและการเผยแพร่ → ตัวเลือกสำหรับนักพัฒนา คือ URL ที่ Dee Wan เรียกเพื่อเริ่ม CI ของ repository ของคุณ
• ปุ่ม Deploy บนการ์ด แบ็กเอนด์ Standalone ในที่เดียวกัน จะเรียก webhook นั้น จากนั้น CI ของคุณจะสร้างไฟล์ที่ระบบดูแลขึ้นใหม่ ใช้ migration และดีพลอย

ไม่มีอะไร regenerate หรือ deploy เอง การเผยแพร่ครั้งถัดไปใน CMS จะไปถึง API แบบ standalone และ หน้าที่ build แบบ static ได้ผ่าน regeneration และ deployment ครั้งใหม่เท่านั้น มันคือ release ไม่ใช่ live feed ส่วน public API ของ CMS และ route ใน สิ่งที่ยังขึ้นกับ Dee Wan ต่างออกไป: การเผยแพร่จะไปถึงทันที

การหยุดใช้

การแยกตัวเป็นผลลัพธ์ที่รองรับ ไม่ใช่ทางออกฉุกเฉิน หากต้องการแยกตัว ให้ลบ build webhook ใน Dee Wan เลิกกด Deploy และเก็บ repository ไว้

สิ่งที่ยังทำงานต่อไป:

• Worker ที่ deploy แล้วและฐานข้อมูลของมัน.
• ทุก route ที่สร้างไว้แล้ว.
• migration ที่ apply ไปแล้ว.
• โค้ดของคุณใต้ src/owned/ และตารางของคุณเอง.
• deploy-from-repository.yml และ CI ของคุณ deployment apply migrations/ ด้วย wrangler d1 migrations apply แล้วรัน wrangler deploy ในเครื่อง npm run db:init apply migration ชุดเดียวกัน
• route ใน สิ่งที่ยังขึ้นกับ Dee Wan เฉพาะขณะที่การติดตั้ง Dee Wan ยังให้บริการ

สิ่งที่หยุด:

• นิยาม model ใหม่จาก CMS.
• เนื้อหา CMS ที่เพิ่งเผยแพร่ ใน API แบบ standalone และหน้าที่ build แบบ static
• การเพิกถอน read token ที่ CMS ออกให้ digest ของมันยังอยู่ใน access/read-tokens.json จนกว่าคุณจะลบออก ดู หยุดการเชื่อมต่อกับ CMS

นับจากนั้น ให้เปลี่ยน schema ด้วย SQL migration ของคุณเอง: เพิ่มไฟล์ต่อจากไฟล์สุดท้ายใน migrations/ ไฟล์ migration ไม่เปลี่ยน prisma/schema.prisma หรือ client ที่สร้างขึ้น เปลี่ยน schema เองแล้วรัน npm run prisma:generate เมื่อไม่มีใคร regenerate อีกแล้ว คุณแก้ไฟล์ในโซน generated ได้อย่างอิสระ กฎของโซนมีผลเฉพาะขณะที่ Dee Wan ยังเขียนไฟล์ลงในชุดไฟล์นั้น

---

ยังไม่เปิดตัว (pre-MVP) และยังไม่มีเวอร์ชันเสถียร
คอมมิตซอร์สโค้ด: e207e63239a627fbd2ae9c414ef7c6eb19fcfe5a (มีการแก้ไขที่ยังไม่คอมมิต)
วันที่สร้างเอกสาร (UTC): 2026-10-21T09:28:24.214Z
คอมมิตสำหรับอัปเกรด: ระบุไม่ได้: มีการแก้ไขที่ยังไม่คอมมิต. บันทึกการเปลี่ยนแปลง