API ตรวจสอบยอดเข้าชม Velog (เบตา)

 (github.com/day1swhan)
5 คะแนน โดย day1swhan 2025-10-17 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

ที่มาของการพัฒนาและแนวคิดในการทำงาน

  • อยากรู้ยอดเข้าชมของโพสต์ที่เขียนไว้ใน Velog แต่ต้องล็อกอินเข้าไปเช็กทุกครั้งมันน่ารำคาญ
  • จะ reverse-engineer API ยอดเข้าชมภายในของ Velog ก็ได้ แต่ดูจะยุ่งยากและขยายต่อได้ไม่ดีนัก (เช่น การแจ้งเตือนผู้เข้าชม)
  • นึกถึงฟีเจอร์ยืนยันการเปิดอ่านที่บริการอีเมลในเกาหลีสมัยก่อนเคยให้ผ่านการใช้ภาพพิกเซล
  • Velog รองรับการเขียนโพสต์ด้วยไวยากรณ์ Markdown
  • เบราว์เซอร์จะไม่บล็อกการเรียกใช้รูปภาพธรรมดาแม้จะเป็นโดเมน cross-site
  • ถ้าแทรกรูปโปร่งใสขนาด 1x1 พิกเซลไว้ในโพสต์ ทุกครั้งที่มีการเปิดดูโพสต์ ฝั่งเซิร์ฟเวอร์ก็จะสามารถบันทึกประวัติการเรียกใช้งานได้
  • โพสต์ของผู้ใช้ Velog ส่วนใหญ่ไม่ได้มีผู้เข้าชมเกิน 1,000 คนต่อวัน สำหรับทราฟฟิกระดับนี้ใช้ Workers KV ก็เพียงพอ
  • ไม่ได้จำกัดแค่ Velog เท่านั้น แพลตฟอร์มใดก็ตามที่รองรับการแทรกรูปด้วยไวยากรณ์ Markdown (และสามารถให้บริการรูปจากโดเมนของผู้ใช้ได้) ก็ใช้งานได้ทั้งหมด

วิธีการทำงาน

  • กำหนด ค่าระบุตัวตน (slug) ให้กับรูปภาพ จากนั้นให้ตอบสนองผ่าน Workers ที่โปรแกรมได้แทน CDN และใช้ค่าระบุตัวตนเป็น Key prefix ของ KV เพื่อเก็บบันทึกการเรียกใช้งาน ก็จะคำนวณ page view ได้อย่างง่ายดาย
  • หากนำ วันที่, ip, userAgent, ค่าระบุตัวตนของรูปภาพ มาสร้างเป็น key ด้วยฟังก์ชัน Hash ก็จะจัดการการเข้าชมซ้ำได้ในระดับพื้นฐาน
    • HASH: แฮช 128 บิตบนพื้นฐาน SHA-256 เข้ารหัสเป็น base64url (22 ตัวอักษร)
    • KEY: view:${slug}:${hash}
    • VALUE: UserAgent, Date...
  • Workers KV แผนฟรีรองรับ PUT และ LIST อย่างละ 1,000 ครั้งต่อวัน
    • PUT: สามารถ บันทึก ข้อมูลการนับผู้เข้าชมได้ 1,000 รายการ ต่อวัน
    • LIST: สามารถ ให้บริการ ข้อมูล page view ได้ มากกว่า 1,000 รายการ ต่อวัน
  • คำขอสำหรับดู page view ใช้คำสั่ง LIST โดยดึงข้อมูลด้วยการใช้ค่าระบุตัวตน (slug) เป็น prefix แล้วนับจำนวนแบบตรงไปตรงมา
    • การดู page view ไม่ได้ต้องการความเป็นเรียลไทม์มากนัก ดังนั้นถ้า แคชค่าตอบกลับให้เหมาะสม ก็จะรองรับคำขอได้เกิน 1,000 ครั้งต่อวัน

ข้อจำกัด

เนื่องจากใช้ KV ซึ่งเป็นสตอเรจแบบเรียบง่ายเพื่อให้พัฒนาได้รวดเร็ว จึงมีข้อจำกัดดังนี้

  • Eventual consistency: คำขอ PUT ของ Workers KV ไม่ได้เป็นแบบเรียลไทม์ หากต้องการความเป็นเรียลไทม์จริง ๆ ต้องใช้ Durable Objects(DO)
  • พึ่งพา LIST: วิธีนับที่ใช้คำสั่ง LIST จะยิ่งช้าลงเมื่อเวลาผ่านไป เพราะจำนวน KEY ที่ต้องดึงมาจะเพิ่มขึ้นเรื่อย ๆ (ภายใต้สมมติฐานว่ามี page view เข้ามาอย่างต่อเนื่อง) ควรพิจารณาอัปเดตโครงสร้างการจัดเก็บด้วยงาน Cron อย่างสม่ำเสมอ หรือใช้ DO หรือ Analytics Engine

สิ่งที่จะรองรับในอนาคต

ตั้งใจจะเพิ่มฟีเจอร์ต่าง ๆ ต่อไปนี้ให้เร็วที่สุด

  • เรียงตามวันที่: หากใช้ Unix Time ซึ่งเป็นวิธีที่ใช้ในการเรียงความคิดเห็นล่าสุดใน ลองสร้าง Serverless Blog Comment API ใน 30 นาที ก็จะสามารถให้รายการที่เรียงตามเซสชันล่าสุดได้
  • ความปลอดภัยของ API: มีแผนรองรับผ่านการเพิ่ม middleware โดยจะใช้ HTTP Authorization header
  • Rate Limit: ถ้าเป็นผู้ใช้ Velog ที่ดัง ก็อาจมีคนที่ทั้งอิจฉาและอยากก่อกวนส่งคำขอที่เป็นอันตรายมาได้ จึงจำเป็นต้องมีมาตรการป้องกัน คงจะเพิ่มเป็นลำดับสุดท้ายเพราะตัวผู้เขียนเองคงยังไม่เข้าข่าย...
  • การค้นหา: จะรองรับเพิ่มผ่าน API
    • วันที่: ค้นหาตามวันที่หรือช่วงเวลา จำเป็นต้องเปลี่ยนโครงสร้าง KEY
    • เซสชัน: ค้นหาข้อมูลกิจกรรมของเซสชันเฉพาะ ปัจจุบันข้อมูลเซสชันมีผลกับแต่ละโพสต์เป็นเวลา 1 วัน ต้องพิจารณานโยบายคุ้มครองข้อมูลส่วนบุคคล
    • เบราว์เซอร์/OS: มีแผนจะให้ข้อมูลจากการ parse UserAgent แม้อาจไม่ละเอียดมาก แต่พอใช้ดูภาพรวมได้
  • Service API: จะให้บริการ API ในรูปแบบเซอร์วิส เพื่อให้ทุกคนใช้งานได้ง่ายผ่าน การยืนยันอีเมล + การออกคีย์ส่วนตัว
    • Webhook: ส่งคำขอ POST เมื่อเกิดเหตุการณ์ page view ทำให้สามารถแจ้งเตือนผ่าน Slack ที่นักพัฒนาชื่นชอบได้
    • อีเมล: ฟีเจอร์แจ้งเตือนแบบคลาสสิกแต่สะดวก สำหรับผู้ใช้ที่ไม่อยากจัดการ webhook
    • Custom campaign: ให้ค่าระบุตัวตนของรูปภาพ (slug) ที่รวมเหตุการณ์ตามที่ตั้งค่าไว้ (เช่น ยอดเข้าชมถึงจำนวนที่กำหนด)

เพิ่มเติม

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น