ระบบการจัดการนิทรรศการและการมีส่วนร่วม

Overview

Type

Senior Project — B.Eng. Computer Engineering

Institution

KMITL, Chumphon Campus

Duration

Jul 2025 – Apr 2026

Team

2 developers

My Role

Full-stack Developer & Team Lead

Advisor

Athasart Narkthewan

Tech Stack

ReactTypeScriptFastifyNode.jsMySQLLINE Messaging APIDocker

ปัญหาและผลกระทบ

การจัดนิทรรศการและกิจกรรมในปัจจุบันยังพึ่งพากระบวนการแบบกระจัดกระจาย ผู้เข้าร่วมลงชื่อบนกระดาษหน้างาน ทำแบบประเมินผ่านลิงก์อีกช่องทาง แล้วรอรับเกียรติบัตรทางอีเมลอีกหลายวันให้หลัง ขณะที่ผู้จัดงานต้องนำข้อมูลจากทุกช่องทางมารวมด้วยมือ เพื่อตรวจสอบว่าใครเข้าร่วมครบตามเกณฑ์บ้าง

ฝั่งผู้จัดงาน	ฝั่งผู้เข้าร่วม
ต้องรวมข้อมูลจากหลายระบบด้วยมือ เสี่ยงตกหล่นและซ้ำซ้อน	ไม่รู้ว่าตัวเองเข้าร่วมครบตามเกณฑ์แล้วหรือยัง
ไม่เห็นยอดผู้เข้าร่วมระหว่างงาน ปรับแผนหน้างานไม่ได้	ต้องเดินไปถามทีมงาน หรือรอให้ประกาศผล
ออกเกียรติบัตรทีละใบ ใช้เวลานานและพิมพ์ชื่อผิดบ่อย	ได้รับเกียรติบัตรช้า บางครั้งชื่อสะกดผิดต้องขอแก้
ใช้กระดาษจำนวนมากทั้งใบเซ็นชื่อและเกียรติบัตร	ทำเอกสารหายแล้วขอใหม่ไม่ได้

ทางเลือกที่มีอยู่ไม่ตอบโจทย์

ระบบจัดการงานอีเวนต์ที่มีในตลาดมักอยู่ในรูปแบบแอปพลิเคชันที่ต้องติดตั้งและสมัครสมาชิกใหม่ ซึ่งเป็นอุปสรรคสำคัญกับงานที่มีผู้เข้าร่วมหลากหลายกลุ่มและใช้งานเพียงครั้งเดียว ผู้เข้าร่วมจำนวนมากไม่ยอมโหลดแอปเพื่อร่วมงานเพียงวันเดียว ทำให้ระบบถูกใช้งานไม่เต็มประสิทธิภาพ

ทางเลือก	ลงทะเบียน	เช็กอิน	ประเมิน	เกียรติบัตร	ไม่ต้องโหลดแอป
Google Form	✓	✗	✓	✗	✓
Excel + กระดาษ	✓	✓	✗	✗	✓
ระบบของเรา	✓	✓	✓	✓	✓

ช่องว่างที่ไม่มีทางเลือกไหนเติมครบ คือ เช็กอิน + ประเมิน + เกียรติบัตร อยู่ในที่เดียว โดยที่ผู้เข้าร่วมไม่ต้องโหลดแอปเพิ่ม — ซึ่งเป็นจุดที่ระบบนี้เข้ามาตอบโจทย์

คำตอบที่เราเลือกคือการใช้ LINE Official Account ร่วมกับ Webhook เป็นช่องทางหลักสำหรับผู้เข้าร่วม เพราะเป็นแอปที่คนไทยใช้อยู่แล้วทุกวัน ทำให้ระบบไปอยู่ในที่ที่ผู้ใช้อยู่ แทนที่จะพาผู้ใช้มาหาระบบ

ข้อสังเกตจากงานจริง

จากงานนิทรรศการและกิจกรรมในคณะที่ผ่านมา การลงทะเบียนยังพึ่งใบเซ็นชื่อกระดาษหน้างาน แบบประเมินถูกแยกไปเป็นอีกหนึ่งลิงก์ และเกียรติบัตรต้องรอประมวลผลเป็นสัปดาห์กว่าจะถึงมือผู้เข้าร่วม ทำให้ข้อมูลกระจัดกระจาย ตรวจสอบย้อนหลังยาก และผู้จัดงานต้องมานั่งรวมข้อมูลด้วยมือ

ข้อสังเกตที่พบ	สิ่งที่ตัดสินใจทำ
ผู้เข้าร่วมไม่ยอมโหลดแอปเพื่องานวันเดียว	ใช้ LINE OA + LIFF แทนการทำแอปแยก
ผู้ใช้มี 3 บทบาทที่ต้องการคนละอย่าง	แยก Organizer / Unit / Visitor ตั้งแต่ระดับฐานข้อมูล
ผู้จัดงานต้องปรับแผนหน้างานได้	Dashboard สถิติเรียลไทม์บนเว็บ
เกียรติบัตรพิมพ์ผิด/ออกช้า	ระบบออก PDF อัตโนมัติตามเกณฑ์ที่ตั้งไว้

เลือกเครื่องมือที่ใช้

• Fastify แทน Express — overhead ต่ำกว่าและมี JSON Schema Validation ในตัว เหมาะกับ Webhook ที่ถี่จัดช่วงคนเข้างานพร้อมกัน
• MySQL แทน NoSQL — เล่มออกแบบฐานข้อมูลเป็น 3 โดเมน (Exhibition / Unit / Survey) ที่เชื่อมโยงกันโดยมีตาราง exhibition เป็นศูนย์กลาง ข้อมูลจึงสัมพันธ์กันหลายชั้นและต้องรักษาความถูกต้องด้วย Transaction
• TypeScript — กำหนด type ร่วมกันระหว่าง client และ backend ลดบั๊กจากรูปร่างข้อมูลที่เปลี่ยนไปมา
• Docker — ล็อกสภาพแวดล้อมให้เหมือนกันทั้งเครื่อง dev และตอน deploy ลดปัญหา “เครื่องผมรันได้”

ผล benchmark ที่ทำให้เลือก Fastify: throughput สูงกว่า Express ราว 1.8 เท่า และอยู่ในกลุ่มหัวตารางเมื่อเทียบกับเฟรมเวิร์ก Node.js ตัวอื่น

• Requests per second (req/s) — higher is better

  • Fastify50,373
  • Hono45,102
  • H339,767
  • Koa38,917
  • Restify32,424
  • Hapi31,978
  • Express27,474

• Latency (ms) — lower is better

  • Express35.89
  • Hapi30.79
  • Restify30.34
  • Koa25.20
  • H324.67
  • Hono21.67
  • Fastify19.33

• Throughput (MB/s) — higher is better

  • Fastify9.03
  • Hono7.40
  • H36.98
  • Koa6.94
  • Restify5.84
  • Hapi5.70
  • Express4.90

ข้อมูลเมื่อ 1 Oct 2026·ที่มา:fastify.dev/benchmarks·higher is better

เป้าหมายและขอบเขต

เป้าหมายของโครงงาน

1. รวมการจัดการนิทรรศการทั้งหมด — ข้อมูลงาน บูธกิจกรรม ข่าวสาร แบบประเมิน และเกียรติบัตร — ไว้ในระบบเดียว
2. ให้ผู้เข้าร่วมลงทะเบียนและตรวจสอบสถานะการเข้าร่วมได้เองผ่าน LINE OA โดยไม่ต้องติดตั้งแอปเพิ่ม
3. ให้ผู้ดูแลระบบและผู้จัดนิทรรศการจัดการข้อมูล (เพิ่ม/แก้ไข/ลบ) ได้จากหน้าเดียว
4. สร้างแบบประเมินความพึงพอใจ พร้อมประมวลผลและสรุปคะแนนอัตโนมัติ
5. ออกใบประกาศนียบัตรอิเล็กทรอนิกส์ให้ผู้ที่เข้าร่วมครบตามเกณฑ์โดยอัตโนมัติ

ขอบเขตงาน

• ลงทะเบียน/เช็กอินผ่าน QR Code
• ใช้งานผ่าน LINE Application (LIFF + Messaging API)
• CRUD ข้อมูลนิทรรศการและบูธกิจกรรม
• เผยแพร่ข่าวสารและแจ้งเตือนผ่าน LINE
• สร้างแบบประเมิน + ประมวลผลสรุปคะแนน
• ตรวจสอบสถานะการเข้าร่วมกิจกรรม
• ออก E-Certificate เป็น PDF อัตโนมัติ

เกณฑ์วัดความสำเร็จ

ตั้งเกณฑ์ไว้ 5 ด้าน และวัดผลจริงทุกข้อ

• ความถูกต้องของ API — ทดสอบทุก endpoint ด้วย Postman ตรวจ HTTP Status Code
• ความสมบูรณ์ของข้อมูล — ตรวจโครงสร้าง JSON Response ว่าตรงตามที่ออกแบบ
• ความครอบคลุมของ API — ทดสอบทั้ง 6 ระบบย่อย โดยระบบนิทรรศการ / บูธกิจกรรม / ข่าวสาร ต้องรองรับ CRUD ครบทั้ง 4 รูปแบบ
• ส่วนติดต่อผู้ใช้ — UI Testing ทุกหน้าจอ ทำงานตามที่ออกแบบ
• การใช้งานจริง — นำระบบไปใช้กับงานจริง บันทึกและประมวลผลข้อมูลได้ถูกต้อง

แผนงานและข้อจำกัด

แผนงาน ภาคเรียนที่ 1 (ก.ค.–พ.ย. 2568) ออกแบบ + พัฒนาระบบจัดการหลัก / ภาคเรืยนที่ 2 (ธ.ค. 2568–เม.ย. 2569) เชื่อม LINE, QR, แบบประเมิน, เกียรติบัตร

เฟส	ช่วงเวลา	สิ่งที่ทำ
Research & Analysis	ก.ค.–ส.ค. 2568	ศึกษาข้อมูล วิเคราะห์ความต้องการ
Design	ก.ย.–ต.ค. 2568	ออกแบบ UI (Figma), ER Diagram, System Architecture
Development	พ.ย. 2568–ก.พ. 2569	พัฒนา Frontend/Backend, เชื่อม LINE OA
Testing & Deploy	มี.ค.–เม.ย. 2569	UI Testing, Postman API Testing, นำเสนอผลงาน

• ข้อจำกัดแพลตฟอร์ม: LINE OA บัญชีฟรีมีโควต้า push message จำกัด
• ข้อสมมติ: ผู้เข้าร่วมมี LINE บนสมาร์ตโฟนและเชื่อมต่ออินเทอร์เน็ตได้หน้างาน
• สถานะ: เสร็จสมบูรณ์ ผ่านการสอบปริญญานิพนธ์ เม.ย. 2569

บทบาทและหน้าที่

ทีม 2 คน แบ่งขอบเขตงานกันชัดเจน — เล่มไม่ได้แยกบทบาทไว้ จึงสรุปไว้ดังนี้

ยงศักดิ์ (ผม) — Backend & Infrastructure

• ออกแบบและพัฒนา REST API ด้วย Fastify ครอบคลุม 6 โมดูล (นิทรรศการ / บูธกิจกรรม / แบบประเมิน / เกียรติบัตร / ข่าวสาร / ตรวจสอบการเข้าร่วม)
• เชื่อมต่อ LINE Messaging API และ LIFF สำหรับลงทะเบียน เช็กอิน และแจ้งเตือน
• ตั้งค่า Docker และ Cloudflare Tunnel สำหรับ dev/test

ณัฐวัฒน์ (เพื่อนร่วมทีม) — UI Design & Frontend

• ออกแบบ UI ทั้งระบบด้วย Figma
• พัฒนา Frontend ด้วย React + TypeScript ครอบคลุมหน้าจอผู้จัดงานทั้ง 6 โมดูล
• พัฒนาหน้า LIFF ให้ผู้เข้าร่วมใช้งานผ่าน LINE บนมือถือ (ลงทะเบียน / เช็กอิน / แบบประเมิน / รับเกียรติบัตร)
• เชื่อมต่อ REST API จาก Backend เข้ากับ UI จัดการ state และฟอร์มของแต่ละหน้า

ร่วมกัน — Database Design

• ออกแบบ ER Diagram และโครงสร้างฐานข้อมูล MySQL 14 ตาราง

ขอให้เครดิต ณัฐวัฒน์ เพื่อนร่วมทีมที่ช่วยรับผิดชอบงานส่วนอื่นของโครงงานร่วมกันจนส่งมอบได้สำเร็จ

ทำงานภายใต้การดูแลของ อ.อรรถศาสตร์ นาคเทวัญ

ภาพร่างการออกแบบ (Design Wireframe)

ภาพร่างหน้าจอ (wireframe/mockup) ที่ออกแบบไว้ตั้งแต่เฟส Design — ครอบคลุมทั้งฝั่งผู้ดูแลระบบ (เว็บ) และฝั่งผู้เข้าร่วมงาน (LINE/mobile) เลื่อนดูด้วยปุ่มลูกศรหรือจุดด้านล่าง

การแก้ไขปัญหา

ระบบออกแบบให้ผู้ใช้ 3 กลุ่มเห็นข้อมูลคนละมุม — ผู้จัดงาน จัดการข้อมูลและดูสถิติทั้งงาน, เจ้าหน้าที่ประจำบูธ เช็กอินผู้เข้าร่วมเฉพาะบูธตัวเอง, และ ผู้เข้าร่วมงาน ลงทะเบียน ทำแบบประเมิน และรับเกียรติบัตรผ่าน LINE

ทั้ง 6 ฟีเจอร์หลักออกแบบมาแก้ปัญหาหนึ่งข้อที่พบจากงานจริง โดยมี API แยกโมดูลรองรับครบทุกตัว

ฟีเจอร์	ปัญหาที่แก้	สิ่งที่ระบบทำ
จัดการข้อมูลนิทรรศการ	ผู้จัดงานต้องแก้รายละเอียดงานหลายรอบ ข้อมูลกระจายหลายไฟล์	สร้าง/แก้ไข/ลบงาน กำหนดช่วงเวลา สถานที่ และหน่วยงานที่ร่วมจัด
ลงทะเบียนและเช็กอินด้วย QR Code	ลงชื่อบนกระดาษหน้างานตกหล่นง่าย ตรวจสอบย้อนหลังยาก	ผู้เข้าร่วมแสดง QR Code ประจำตัว เจ้าหน้าที่ประจำบูธสแกนเพื่อบันทึกเช็กอิน
จัดการบูธกิจกรรม (Unit)	แต่ละบูธมีเจ้าหน้าที่คนละชุด ต้องเก็บเช็กอินแยกรายบูธ	แยกเจ้าหน้าที่ประจำบูธ กำหนดสิทธิ์ และเก็บ check-in รายบูธ
แบบสอบถามออนไลน์	แบบประเมินถูกแยกไปอยู่อีกช่องทาง รวบรวมผลยาก	สร้างชุดคำถาม เก็บคำตอบผ่าน LINE และสรุปคะแนนในระบบเดียว
E-Certificate อัตโนมัติ	ออกเกียรติบัตรทีละใบ ใช้เวลานาน พิมพ์ชื่อผิดบ่อย	ออก PDF ตาม template ให้ผู้ที่เข้าร่วมครบเกณฑ์โดยอัตโนมัติ
ประชาสัมพันธ์ข่าวสาร	ผู้เข้าร่วมไม่รู้ความเคลื่อนไหวระหว่างงาน	ส่งข่าวสารและแจ้งเตือนถึงผู้ใช้ผ่าน LINE OA โดยตรง

ภาพรวมสถาปัตยกรรม

ระบบเป็น Client-Server ที่ผู้ใช้ไม่ต้องติดตั้งอะไรเพิ่ม — ผู้เข้าร่วมคุยผ่าน LINE ทั้งหมดแล้วให้ Webhook วิ่งเข้าหา backend

ผู้ใช้

แชท / สแกน QR / เปิด LIFF▼

LINE OA

HTTPS POST /webhook (events[])▼

Backend · Fastify

SQL query▼

MySQL

เทคโนโลยีที่ใช้

ส่วน	เทคโนโลยี
Frontend	React + TypeScript
Backend	Node.js + Fastify
Database	MySQL
LINE Integration	LINE Messaging API + LIFF
DevOps / Deployment	Docker, Cloudflare Tunnel
เครื่องมือพัฒนา	Git + GitHub, Figma, Postman

โครงสร้างฐานข้อมูล

ตาราง 14 ตารางถูกแบ่งเป็น 3 โดเมนหลักเพื่อให้เห็นขอบเขตชัดเจน

• Exhibition — exhibition, registrations, exhibition_announcements, certificate_templates, normal_users
• Unit — unit, unit_staffs, units_checkins
• Survey — question_sets, questions_template, set_question_mapping, survey_submissions, survey_answers, survey_tracking

ตัวอย่างโค้ด: Webhook Handler

จุดที่รับ Webhook ไม่ใช่แค่ dispatch เหตุการณ์ แต่โฟกัสที่ ยืนยันลายเซ็น ก่อน (ป้องกันใครปลอม requests หลอกระบบ) แล้วค่อยกระจาย event ไปยัง handler

// จุดรับ Webhook จาก LINE
app.post(
  "/webhook",
  { config: { rawBody: true } }, // ต้องอ่าน raw body เพื่อเอาไปคำนวณ HMAC
  async (req: RawBodyRequest, reply: FastifyReply) => {
    const signature = req.headers["x-line-signature"];
    if (typeof signature !== "string") {
      return reply.code(400).send({ message: "missing LINE signature header" });
    }

    // ยืนยันว่า payload มาจาก LINE จริง ๆ (HMAC-SHA256 ด้วย Channel Secret)
    if (!verifyLineSignature(signature, req.rawBody, getLineConfig())) {
      return reply.code(401).send({ message: "invalid LINE signature" });
    }

    const events = (req.body as LineWebhookPayload)?.events ?? [];
    if (!events.length) {
      return reply.send({ ok: true });
    }

    // dispatch ทั้งหมดพร้อมกัน — event หนึ่งผิดพลาดไม่ฉุด event อื่น
    await Promise.all(
      events.map((event) =>
        dispatchLineEvent(event, getLineConfig(), app.log).catch((err) => {
          app.log.error({ err, event }, "failed to process LINE event");
        }),
      ),
    );

    reply.send({ ok: true });
  },
);

ตัวกระจายเหตุการณ์จะตัดสินใจตามชนิด event แล้วเรียก handler ที่รับผิดชอบ

export async function dispatchLineEvent(event, config, log) {
  const userId = event.source?.userId;

  if (event.type === "unfollow" && userId) {
    await markLineUserUnfollowed(userId); // ลบ soft-delete เลิกติดตาม
    return;
  }

  // ดึงโปรไฟล์ LINE มาซิงก์เข้า normal_users ทุกครั้งที่ใช้งาน
  const profile = await fetchLineProfile(userId, config);
  await upsertLineUserProfile({
    line_user_id: profile.userId,
    display_name: profile.displayName,
    picture_url: profile.pictureUrl ?? null,
  });

  if (event.type === "follow" && event.replyToken) {
    return handleFollowEvent(event.replyToken, config, log);
  }
  if (event.type === "postback" && event.postback?.data) {
    return handlePostbackEvent(
      event.replyToken,
      userId,
      event.postback.data,
      config,
      log,
    );
  }
  if (event.type === "message" && event.message?.type === "text") {
    return handleMessageCommand(
      event.replyToken,
      userId,
      event.message.text,
      config,
      log,
    );
  }
}

ความท้าทายและการแก้ไขปัญหา

1. ทดสอบ Webhook และ LIFF บน localhost

สถานการณ์ — LINE Messaging API และ LIFF ต้องเรียกผ่าน HTTPS endpoint ที่เข้าถึงจากอินเทอร์เน็ตได้ แต่ backend รันอยู่บน localhost ของเครื่อง dev ซึ่งไม่มี public URL

สิ่งที่ต้องทำ — ต้องทดสอบ flow จริงทั้งหมด (ลงทะเบียน → เช็กอิน → แบบประเมิน → E-Certificate) โดยไม่ต้อง deploy ขึ้น production ทุกครั้งที่แก้โค้ด

ทางแก้ไข — ใช้ Cloudflare Tunnel เปิด public HTTPS endpoint ที่ชี้กลับมาที่เครื่อง dev โดยไม่ต้องตั้งค่า firewall หรือซื้อโดเมน และรัน tunnel ควบคู่กับ dev server ทุกครั้งที่ทดสอบ

ผลลัพธ์ — ทดสอบ flow จริงได้ครบทั้งหมดบนเครื่อง dev ลดรอบเวลาแก้บั๊กจากที่ต้อง deploy ก่อนตรวจสอบ เหลือแก้แล้วเห็นผลทันที และทีมทั้งสองคนแชร์ tunnel ให้กันทดสอบได้

LINE Platform

HTTPS▼

Cloudflare Edge

Tunnel▼

localhost:3000 · Fastify

2. ความซับซ้อนของโมดูลและบทบาทผู้ใช้

สถานการณ์ — ระบบมี 6 โมดูล และผู้ใช้ 3 บทบาท (Organizer / Unit / Visitor) ที่มองข้อมูลคนละมุม

สิ่งที่ต้องทำ — ต้องกำหนดโครงสร้างข้อมูลและขอบเขตงานให้ชัดก่อนลงโค้ด เพื่อไม่ให้แก้ schema ระหว่างพัฒนา

ทางแก้ไข — ออกแบบ ER Diagram และแบ่งโดเมนตารางให้ชัดก่อนเขียนโค้ด (Exhibition / Unit / Survey) พร้อมแบ่งหน้าที่ในทีมตั้งแต่ต้น

ผลลัพธ์ — ลดงานแก้ schema ย้อนหลัง และทั้งสองคนทำงานคู่ขนานได้โดยไม่ชนกัน

3. เครื่องมือใหม่ที่ทีมยังไม่คุ้น

สถานการณ์ — เครื่องมือหลักที่เลือกใช้เป็นของใหม่สำหรับทีม ต่างจากที่เรียนมา

สิ่งที่ต้องทำ — ลดความเสี่ยงที่จะ integrate ไม่ผ่านเมื่อถึงเวลาประกอบระบบ

ทางแก้ไข — ทำ prototype เล็กแยกก่อนต่อเข้าระบบจริง ทดลอง Webhook handler, LIFF login และ Docker compose ทีละส่วน

ผลลัพธ์ — เข้าใจข้อจำกัดของแต่ละเครื่องมือก่อน integrate จริง ลดปัญหาที่ต้องรื้อโค้ดทีหลัง

ผลลัพธ์

ผลการทดสอบ

ผลทดสอบ 32 กรณีของส่วนติดต่อผู้ใช้ผ่านทั้งหมด และทดสอบส่วนประมวลผลหลังบ้าน (Backend API) ด้วย Postman ครบทั้ง 6 ระบบย่อย

ระบบย่อย	กรณีทดสอบ	ผลลัพธ์
ระบบการจัดการนิทรรศการ	CRUD ครบ 4 รูปแบบ (GET / POST / PUT / DELETE)	ผ่าน
ระบบการจัดการบูธกิจกรรม	CRUD + สร้าง QR และเช็กอินรายบูธ	ผ่าน
ระบบการจัดการแบบประเมิน	จัดการชุดคำถาม + ตอบแบบประเมินผ่าน LIFF	ผ่าน
ระบบการจัดการใบประกาศนียบัตร	จัดการ template + ดู/ดาวน์โหลดผ่าน LIFF	ผ่าน
ระบบการแจ้งข้อมูลข่าวสาร	CRUD ครบ 4 รูปแบบ	ผ่าน
ระบบตรวจสอบการเข้าร่วมกิจกรรม	สร้าง QR + เจ้าหน้าที่สแกนบันทึกการเช็กอิน	ผ่าน

ผลกระทบเชิงกระบวนการ: จากลงชื่อกระดาษ + แบบประเมินคนละลิงก์ + เกียรติบัตรพิมพ์เอง → เหลือช่องทางเดียวใน LINE

ภาพหน้าจอฟีเจอร์

ภาพหน้าจอการใช้งานจริงจากเล่มปริญญานิพนธ์ — เลื่อนดูภาพด้วยปุ่มลูกศรหรือจุดด้านล่าง

บทเรียนและก้าวต่อไป

สิ่งที่อยากทำต่อ

• รองรับ Broadcast Message เต็มรูปแบบเพื่อแจ้งข่าวแบบเรียลไทม์
• ปรับปรุง response time ของระบบ
• พัฒนา UI ให้ใช้ง่ายและดึงดูดขึ้น

บทเรียนที่ได้

• การออกแบบฐานข้อมูลก่อนเขียนโค้ดช่วยลดงานแก้ทีหลัง
• ข้อจำกัดของแพลตฟอร์มภายนอก (LINE) ต้องรู้ตั้งแต่ต้น
• การแบ่งงานในทีม 2 คนต้องกำหนดขอบเขตชัด