JSON to Mongoose Converter: แปลง sample document เป็น typed schema ได้ในการ paste เดียว

ทุก Mongoose model เริ่มต้นเหมือนกันหมด นั่งมอง sample document แล้วพิมพ์ schema ด้วยมือ เปิด models/Product.js แล้วจดจาก JSON ที่ API return หรือ document ที่เพิ่ง export มาจาก collection ทีละ field — name: String, price: Number, ObjectId พร้อม ref ตรงนั้น enum ของค่าที่อนุญาตตรงนี้ มันช้า มันน่าเบื่อ และเป็นงานที่พิมพ์ type ผิดหรือลืม nested object แล้วกลายเป็นบั๊กเงียบ ๆ ของสัปดาห์หน้าได้ง่ายมาก JSON to Mongoose Converter พิมพ์ให้คุณในการ paste เดียว: วาง document ตัวอย่างที่ใช้แทนของจริงได้ แล้วรับ block new mongoose.Schema(...) กลับออกมา พร้อม type ที่ infer แล้ว ref ที่ detect ได้ และ option strict mode กับ timestamps ที่ toggle ได้ทันที

หลักคิดข้างหลังเครื่องมือนี้ง่ายมาก: sample document มีความจริงของ schema อยู่ในตัวแล้ว ทุก key บอกชื่อ field ทุก value บอก type, string แบบ hex 24 ตัวอักษรมักบอกว่าเป็น reference และ string ที่วนซ้ำกันไม่กี่ค่ามักบอกว่าเป็น enum การอ่านสัญญาณพวกนี้ด้วยมือเป็นงานกลไกล้วน ๆ แต่ให้ parser อ่านแทนนั้นเร็วและ consistent กว่าเสมอ คุณยังอยู่ใน loop สำหรับจุดที่ต้องใช้ดุลพินิจ — field ไหน required, ref ไหนชี้ไป model ไหน — ส่วนงานถอดรหัสให้เครื่องมือทำ

ในคู่มือนี้เราจะพาดูว่า converter detect อะไรได้บ้าง วิธีใช้ทีละขั้น การ map type ทำงานจริงแบบไหนใต้ฝา และแนวปฏิบัติที่เปลี่ยน schema ที่ generate มา ให้เป็น schema ที่พร้อม ship

ทำไมต้องใช้ JSON to Mongoose Converter?

• บอกลา boilerplate: ตัว wrapper, object ปิดท้าย options, การเดิน comma — เครื่องมือ emit new mongoose.Schema({...}) ที่สมบูรณ์ออกมาเลย งานของคุณเหลือแค่แก้ schema ไม่ใช่พิมพ์มัน
• Infer type จาก sample data: string กลายเป็น String, number กลายเป็น Number, boolean กลายเป็น Boolean และ array กลายเป็น typed array อย่าง [String] ตามที่ค่าใน sample เป็นจริง
• Detect ref และ enum ให้เอง: value ที่มีรูปร่างแบบ ObjectId ถูก map เป็น Schema.Types.ObjectId และ string ที่ค่าซ้ำกันไม่กี่ค่าถูกเสนอเป็น candidate ของ enum แทนที่จะปล่อยเป็น string ธรรมดาเงียบ ๆ
• Nested object กลายเป็น subdocument: object ที่ซ้อนอยู่ใน JSON ถูก generate เป็น nested schema definition โครงสร้างอย่าง address หรือ supplier จึงออกมาเป็นโครงสร้าง ไม่ใช่ถูกบีบเป็น Mixed
• Strict mode และ timestamps มีให้พร้อม: สอง option ที่ทุก model จริงต้องมี อยู่ห่างแค่การ toggle เดียว โค้ดที่ได้จึงมีรูปร่าง production ตั้งแต่ paste แรก
• เป็นส่วนตัวและทันที: ทุกอย่างทำงานในเบราว์เซอร์ 100% — ไม่ต้องสมัคร ไม่มีการ upload และไม่ต้องรอ แม้ document จะใหญ่แค่ไหน

คุณสมบัติหลัก

มีรายละเอียดน่าสนใจอยู่บ้าง ผลลัพธ์ที่ได้เป็น JavaScript พร้อม copy ที่เดินตาม convention ที่นิยมของ Mongoose จึงอ่านเหมือนโค้ดที่ทีมคุณจะเขียนเอง และเพราะการ infer เป็นแบบ deterministic การ paste document เดิมสองรอบจะได้ schema เดิม — มีประโยชน์ตอน regenerate หลัง model มีการเติบโต

วิธีใช้งาน

1. Paste sample JSON document หยิบ document ที่สมบูรณ์ที่สุดของคุณ — จาก collection export, response ของ API หรือ design doc — แล้ววางลง input panel
2. อ่าน schema ที่ generate ออกมา panel ด้านขวาจะเต็มด้วย block new mongoose.Schema(...): หนึ่งบรรทัดต่อหนึ่ง field, nested object ถูกขยาย, type ถูก infer จากค่าของคุณ
3. ปรับ type และ ref แก้จุดที่ sample ไม่ได้บอกครบ — ชี้ ref ไปที่ชื่อ model ที่ถูกต้อง ขยาย type หรือแยก string ที่ควรเป็น nested object ออกมา
4. เลือก strict mode และ timestamps ปล่อย strict ไว้เปิดเว้นแต่จะมีเหตุผลเฉพาะ และเปิด timestamps สำหรับ collection ที่ต้องการ createdAt กับ updatedAt
5. Copy กลับเข้า models folder วางผลลัพธ์ลง models/YourModel.js เติม mongoose.model(...) สำหรับ export แล้วคุณก็มี model ที่ใช้งานได้

วงจรทั้งหมดใช้เวลาไม่ถึงนาทีสำหรับ document ทั่วไป และคุณ paste sample ที่จัดเต็มกว่ากลับเข้าไปใหม่เมื่อไหร่ก็ได้เพื่อ regenerate

จาก Document สู่ Schema

หัวใจของ converter คือการ map type JSON มีรูปร่าง value อยู่ไม่กี่แบบ และแต่ละแบบ map เข้ากับ Mongoose type ได้ตรง ๆ:

"hello"            -> String
42, 3.14           -> Number
true, false        -> Boolean
["a", "b"]         -> [String]
null               -> edge case: ไม่มีสัญญาณ type ได้ default ที่สมเหตุสมผล ควรกลับมา review
{ "city": "..." }  -> nested object, emit เป็น subdocument schema
"64b7f2e9a1c3..."  -> รูปร่าง ObjectId, emit เป็น Schema.Types.ObjectId

การ detect ObjectId และ convention ของ ref MongoDB เก็บ reference เป็น string hex 24 ตัวอักษร converter จึงถือว่า string ที่ตรงรูปแบบนี้เป็น candidate ของ ObjectId แต่การรู้แค่นั้นยังไม่พอจะใช้งานได้จริง — field supplier ที่ชี้ไปที่ 64b7f2e9a1c3 จะมีประโยชน์เมื่อ Mongoose รู้ว่าต้อง populate จาก collection ไหน เครื่องมือจึงจับคู่ ObjectId ที่ detect ได้กับ ref ที่ derive จากชื่อ field (supplier กลายเป็น ref: 'Supplier') ตาม convention ที่แทบทุก codebase ใช้อยู่แล้ว คุณเหลือหน้าที่ยืนยันหรือเปลี่ยนชื่อ ref ส่วนระบบประปาทั้งหมดพร้อมอยู่แล้ว

การ infer enum จากค่าที่วนซ้ำ ถ้า string field มีค่าจากชุดเล็ก ๆ — "status": "active", "draft", "archived" — type String เปล่า ๆ จะปล่อยให้อะไรก็ผ่านได้ เมื่อเครื่องมือเห็น string field ที่ค่าวนซ้ำจากคำศัพท์จำกัด มันจะเสนอ array enum เพื่อให้ schema บันทึกค่าที่ถูกกฎหมายเอาไว้ และ Mongoose validate ตอน save ได้ด้วย

ทำไม strict mode ถึงสำคัญ โดย default Mongoose ทำงานใน strict mode: field ที่ไม่ได้ประกาศใน schema จะถูกตัดออกจาก document เงียบ ๆ ตอน save นั่นเป็นข้อดี — มันกัน property หลุด ๆ พรล่องไม่ให้เข้าไปเปื้อน collection — แต่จะดีจริงก็ต่อเมื่อ schema ของคุณประกาศ field ที่ต้องการครบทุกตัว schema ที่ generate จาก sample ที่สมบูรณ์เริ่มต้นแบบ strict และถูกต้อง ส่วน schema ที่พิมพ์มือจากความจำมักลืม field แล้วทำ data หายเงียบ ๆ toggle นี้มีไว้เพื่อให้คุณปิดแบบตั้งใจ (สำหรับ document ที่ dynamic จริง ๆ) ไม่ใช่ปิดไปโดยบังเอิญ

Timestamps collection ส่วนใหญ่อยากมี audit trail เปิด option timestamps แล้ว { timestamps: true } จะถูกเติมเข้าไปใน schema จากนั้น Mongoose จะดูแล createdAt และ updatedAt ให้ทุก document โดยอัตโนมัติ — ไม่ต้องเขียน middleware ไม่ต้องใส่ field วันที่เองใน sample

ตัวอย่างจริง วาง product document นี้ ซึ่งมีทั้ง supplier reference ที่ซ้อนอยู่และ tags array:

{
  "name": "Trail Backpack",
  "price": 89.5,
  "supplier": "64b7f2e9a1c3d4e5f6a7b8c9",
  "status": "active",
  "tags": ["outdoor", "hiking"],
  "inStock": true
}

Converter emit ออกมาเป็น:

const productSchema = new mongoose.Schema(
  {
    name: String,
    price: Number,
    supplier: { type: mongoose.Schema.Types.ObjectId, ref: 'Supplier' },
    status: { type: String, enum: ['active'] },
    tags: [String],
    inStock: Boolean,
  },
  { timestamps: true }
);

จากจุดนี้คุณจะเติม enum ให้ครบด้วยค่าที่รู้ว่ามีอยู่ ทำเครื่องหมาย name และ price เป็น required และเพิ่ม unique หรือ index ตรงที่ query ต้องการ — ซึ่งพามาถึง caveat ที่ต้องพูดตรง ๆ: schema เป็นจุดเริ่มต้น ไม่ใช่เส้นชัย sample document พิสูจน์ได้แค่ว่าอะไรมีอยู่ แต่พิสูจน์ไม่ได้ว่าอะไรต้องมีเสมอ เติม required, unique และ index อย่างตั้งใจ ทีละการตัดสินใจ หลังจากที่โครงอยู่ในมือแล้ว

กรณีการใช้งานจริง

Bootstrapping model ใหม่

เริ่ม feature ใหม่ด้วย mock หรือ payload จาก design doc? วางเข้าไปแล้ว scaffolding ของ schema พร้อมก่อน git commit แรก เวลาที่ประหยัดได้เอาไปใช้กับ validation rule และ index — ส่วนที่ต้องการมนุษย์จริง ๆ

Reverse-engineering collection ที่มีอยู่

รับมรดก MongoDB database ที่ไม่มี model และไม่มีเอกสาร? Export document ตัวแทนจากแต่ละ collection, convert ทีละตัว แล้วคุณจะได้แผนที่ database ทั้งหมดแบบมี type อ่านได้ ภายในบ่ายเดียวแทนที่จะเป็นหนึ่ง sprint

Migrate app ที่ใช้ MongoDB ดิบมาเป็น Mongoose

หลายทีมเริ่มด้วย driver mongodb ก่อนแล้วค่อยมาใช้ Mongoose ทีหลัง converter เปลี่ยนรูปร่าง query ที่มีอยู่ของคุณให้กลายเป็น schema definition การ migrate จึงเริ่มจากข้อมูลจริงที่หน้าตาเป็นแบบนั้น ไม่ใช่จากความจำของใครบางคน

สอน Mongoose schema

ถ้าคุณกำลังเรียน Mongoose — หรือกำลังสอน — การ convert document แล้วเทียบกับ JSON เป็นวิธีเร็วที่จะเห็นว่า type, ref, enum และ subdocument สัมพันธ์กับข้อมูลธรรมดาอย่างไร การ map จะชัดขึ้นทันทีเพราะ input กับ output อยู่เคียงกัน

แนวปฏิบัติที่ดี

• ใช้ sample document ที่สมบูรณ์ที่สุดที่หาได้ การ infer เห็นแค่สิ่งที่คุณ paste document ที่มีทุก field ถูกกรอกจะให้ schema ที่ประกาศครบทุก field
• Review type ที่ infer มาทุกตัว ราคาที่เก็บเป็น "19.99" จะกลายเป็น String และรหัสไปรษณีย์แบบตัวเลขจะกลายเป็น Number เครื่องมือให้ร่างแรกที่แข็งแรง แต่คุณต้องยืนยันความหมายเอง
• เติม validation ก่อน ship schema ที่ generate บอกรูปร่าง ไม่ได้บอกกติกา ต้องเคลือบ required, min/max และ custom validator เพิ่มก่อนที่ model จะแตะข้อมูล production
• ป้อนหลาย document เมื่อ model ค่อนข้างปั่นป่วน field แบบ optional ไม่เหมือนกันระหว่าง document การ paste sample ที่สองที่ต่างออกไปจะช่วยจับ field ที่ sample แรกไม่มี
• อย่าปล่อยให้ enum หลอกตัวเอง ยอมรับ enum ที่ infer มาเมื่อ sample ครอบคลุม value space จริงเท่านั้น และขยาย array ด้วยค่าที่รู้ว่ามีแต่ไม่ได้โผล่มา
• ถือว่า strict mode คือ default ไม่ใช่ข้อยกเว้น ปิดเฉพาะ collection ที่ dynamic กันจริง และเขียนเหตุผลไว้ที่ schema definition เสมอ

พร้อมข้ามงานพิมพ์แล้วหรือยัง? เปิด JSON to Mongoose Converter วาง document ที่สมบูรณ์ที่สุดของคุณ แล้วดูมันกลายเป็น typed schema พร้อม ref, enum และ timestamps — ในการ paste เดียว ทำงานในเบราว์เซอร์ล้วน ๆ

เครื่องมืออื่น ๆ ที่น่าสนใจ:

• JSON Schema Generator — เปลี่ยน sample JSON ชุดเดิมเป็น JSON Schema มาตรฐานสำหรับ validation นอก Mongoose
• JSON Flattener — แผ document ที่ซ้อนกันให้แบนเป็น key แบบ dot-notation เพื่อวิเคราะห์และ export เป็นไฟล์แบน
• JSON Formatter — เกลาและตรวจ JSON ที่รก ๆ ให้เรียบร้อยก่อนเอาไป paste ที่ไหนก็แล้วแต่

ขอให้ทุก schema ที่ generate มาเหลือแต่จุดที่มนุษย์ต้องลงมือเท่านั้น — Online Tools Forge Team

คำถามที่พบบ่อย

ถ: เครื่องมือใช้ฟรีจริงไหม แล้ว JSON ของฉันถูก upload ไปที่ไหนหรือเปล่า?

ตอบ: ฟรีทั้งหมด ไม่ต้องสมัคร และไม่มีการ upload ใด ๆ การ parse และสร้าง schema เกิดขึ้นใน JavaScript ของเบราว์เซอร์คุณล้วน ๆ sample document จึงไม่เคยออกจากเครื่อง

ถ: เครื่องมือตัดสินใจอย่างไรว่า string ไหนเป็น ObjectId?

ตอบ: มันเช็ก pattern hex 24 ตัวอักษรมาตรฐานที่ MongoDB ใช้กับ ObjectId ค่าที่ตรงจะถูก emit เป็น Schema.Types.ObjectId พร้อม ref ที่ derive จากชื่อ field ซึ่งคุณควรปรับให้ตรงกับชื่อ model จริงของคุณ

ถ: ค่า null หรือ array เปล่าจะถูกจัดการอย่างไร?

ตอบ: null ไม่ให้สัญญาณ type เลย field จะได้ default ที่สมเหตุสมผลซึ่งควรกลับมา review และ array เปล่าบอก type ของสมาชิกไม่ได้ — ทั้งสองกรณีถือเป็นจุดที่ต้องยืนยันด้วยมือใน schema ที่ได้

ถ: paste document ที่มี object ซ้อนลึกหลายชั้นได้ไหม?

ตอบ: ได้ครับ nested object จะถูก emit เป็น nested subdocument schema ทุกระดับความลึก โครงสร้างอย่าง address.city หรือ settings ที่ซ้อนหลายชั้นจึงออกมาเป็นโครงสร้าง ไม่ใช่ Mixed รวบ ๆ

ถ: schema ที่ได้ใช้ขึ้น production ได้เลยไหม?

ตอบ: ถือเป็นจุดเริ่มต้นคุณภาพสูงครับ type, ref และ option ที่ได้เป็นรากฐานที่แข็งแรง แต่ schema สำหรับ production ยังต้องมี field แบบ required, เงื่อนไข unique และ index — การตัดสินใจที่ขึ้นกับ business rule ของคุณ ไม่ใช่ข้อมูล sample