Zero Sheets ที่ใช้ Google Sheets เป็นแบ็กเอนด์/API ของแอป

 (zerosheets.com)
3 คะแนน โดย GN⁺ 2024-04-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Zero Sheets เป็นบริการที่แปลง Google Sheets ให้เป็น RESTful JSON API เพื่อให้จัดการข้อมูลในต้นแบบ เว็บไซต์ และแอปได้โดยไม่ต้องมีแบ็กเอนด์แยก
  • สามารถส่ง HTTP request ไปยังเอนด์พอยต์ที่สร้างขึ้นเพื่ออ่านและจัดการข้อมูลได้ พร้อมตั้งค่าวิธีการยืนยันตัวตนและชีตที่จะใช้งาน
  • ขั้นตอนเริ่มต้นมี 3 ขั้นตอนคือ วาง URL ของชีต, ตั้งค่า API และส่งคำขอไปยังเอนด์พอยต์ ช่วยลดภาระในการเชื่อมต่อช่วงเริ่มต้น
  • มุ่งเน้นการใช้สเปรดชีตในลักษณะ CMS สำหรับฝั่งไคลเอนต์ เพื่อทดสอบไอเดียด้วยข้อมูลจริง
  • แพ็กเกจมีตั้งแต่ฟรี 1 API และ 200 คำขอต่อเดือน ไปจนถึง Scout เดือนละ $4.99 และ Craft เดือนละ $19.99 โดยแพ็กเกจสาธารณะรองรับการอ่าน เขียน แก้ไข และลบ

แปลง Google Sheets เป็น RESTful API

  • แปลงสเปรดชีต Google Sheets ให้เป็น RESTful API เพื่อให้สามารถอ่านและจัดการข้อมูลได้ด้วย HTTP request แบบง่าย ๆ
  • วางตำแหน่งเป็นเครื่องมือสำหรับนักพัฒนาที่ต้องการสร้างต้นแบบ เว็บไซต์ และแอปได้อย่างรวดเร็ว
  • ในขั้นตอนตั้งค่า API สามารถกำหนดวิธีการยืนยันตัวตน ชีตที่จะใช้ และการตั้งค่าอื่น ๆ ได้
  • ลำดับการใช้งานสรุปเป็น 3 ขั้นตอน
    • คัดลอก URL ของ Google Spreadsheet ไปวางในแดชบอร์ด
    • ตั้งค่าวิธีการยืนยันตัวตนและชีตที่จะใช้ของ API ใหม่
    • หลังได้รับเอนด์พอยต์แล้วจึงส่ง HTTP request

รูปแบบการใช้งานแบบ CMS และแพ็กเกจราคา

  • สามารถใช้สเปรดชีตเป็นเหมือนที่เก็บข้อมูลจริงเพื่อทดสอบไอเดีย และให้ทำหน้าที่เป็น CMS ที่ฝั่งไคลเอนต์ใช้งานได้
  • ชูจุดเด่นว่าสามารถทำไอเดียให้เกิดขึ้นจริงได้ถูกกว่าและเร็วกว่าการสร้างแผงควบคุมแบ็กเอนด์เอง
  • แพ็กเกจสาธารณะมีดังนี้
    • Free: $0/เดือน, 1 API, แท็บชีตไม่จำกัด, อ่าน/เขียน/แก้ไข/ลบ, 200 คำขอต่อเดือน
    • Scout: $4.99/เดือน, API ไม่จำกัด, แท็บชีตไม่จำกัด, อ่าน/เขียน/แก้ไข/ลบ, 400 คำขอต่อเดือน, รองรับ 24/7
    • Craft: $19.99/เดือน, API ไม่จำกัด, แท็บชีตไม่จำกัด, อ่าน/เขียน/แก้ไข/ลบ, 2000 คำขอต่อเดือน, รองรับ 24/7
  • แพ็กเกจแบบกำหนดเองมีให้โดยติดต่อสอบถามแยกต่างหาก

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

1 ความคิดเห็น

 
GN⁺ 2024-04-13
ความคิดเห็นบน Hacker News

  • ต้องระวัง กับดักมือใหม่ Excel ในยุคปัจจุบัน ช่วงยุค 80–90 ธนาคารเพื่อการลงทุนจำนวนมากตกหลุมนี้ เพราะสเปรดชีตเป็นเฟรมเวิร์กคำนวณอเนกประสงค์ที่ยอดเยี่ยม จนสุดท้ายเอาตั้งแต่การบริหารความเสี่ยง การกำหนดราคา ไปจนถึงฟังก์ชันด้านปฏิบัติการไปวางทับอยู่บนกองไฟล์ Excel ขนาดมหึมา
    ถ้าติดปลั๊กอินและส่วนขยายเข้าไปก็ทำอะไรได้มากมายจริง ๆ แต่ท้ายที่สุดสเปรดชีตก็กลายเป็นฝันร้ายที่บำรุงรักษาไม่ได้และทำความเข้าใจภายในได้ยาก อีกทั้ง ลอจิกธุรกิจ หลักยังถูกขังอยู่ในชีตส่วนตัวของหลายคน การเปลี่ยนแปลงในวงกว้างจะยากหรือเป็นไปไม่ได้ และแม้แต่การเปลี่ยนแปลงที่ถ้าใช้เฟรมเวิร์กซอฟต์แวร์ทั่วไปแล้วทำได้ง่าย ก็ต้องไปแก้ชีตจำนวนมาก ทำให้ความเสี่ยงและต้นทุนการตรวจสอบสูงขึ้น

    • ใน visual scripting ของการพัฒนาเกมก็เกิดสถานการณ์ที่คล้ายกันมาก เดิมทีเป็นเครื่องมือให้ดีไซเนอร์หรือศิลปินทำงานเล็ก ๆ เช่น เหยียบแผ่นกดแล้วประตูเปิด โดยไม่ต้องเรียกโปรแกรมเมอร์ แต่ผลลัพธ์มักโตจนควบคุมไม่อยู่ได้ง่าย
      มีแม้กระทั่งเว็บที่รวบรวมเฉพาะกรณีของ Unreal Engine: https://blueprintsfromhell.tumblr.com/ ส่วนตัวคิดว่าทางแก้คือการสนับสนุนการรีแฟกเตอร์ที่ดี ควรจัดระเบียบได้ด้วยวิธีอย่าง “extract method” โดยไม่ต้องให้โปรแกรมเมอร์เข้าไปเขียนใหม่ทั้งหมด
    • มันไม่ใช่เรื่องของการเลือกเสมอไป ที่ทำงานของผม แค่จะได้สภาพแวดล้อมที่รัน Python hello world แบบเป็นไปตามนโยบาย ก็ต้องผ่านขั้นตอนต่าง ๆ ใช้เวลาประมาณ 4 ชั่วโมง
      ไม่ต้องพูดถึง IDE เต็มรูปแบบหรือโมดูล pip เลย แค่ hello world ธรรมดา ๆ เท่านั้น และนี่ยังถือว่าดีกว่าที่ผ่านมาแล้วด้วย บางบริษัทการเงินไม่ให้ตัวเลือกอื่นตั้งแต่แรก เป็นรูปแบบที่เจอบ่อยคือให้พนักงานออฟฟิศใช้แค่ Excel แล้วก็แปลกใจว่าทำไมคนถึงสร้างสัตว์ประหลาดขึ้นมาด้วย Excel
    • เห็นด้วยอย่างยิ่ง บริษัทที่ผมทำงานอยู่ไม่ได้รีแฟกเตอร์โครงสร้างยุ่งเหยิงของสเปรดชีตกับ pipeline ส่งออกคิวรีฐานข้อมูลมานานกว่า 10 ปี และตอนนี้มันขยายต่อไม่ได้จนเงินรั่วไหลออกไปเรื่อย ๆ
      ปัญหาแบบนี้มักไม่ค่อยโผล่ให้เห็นจนกว่าทุกอย่างจะพัง การทำงานพร้อมกันบนสเปรดชีตแทบจะเป็นหนึ่งในสิ่งที่อันตรายที่สุด จึงเกิดคอขวดในทุกกระบวนการหลัก การผสานข้อมูลมีความเสี่ยงและใช้เวลานาน และยังรับประกันความสอดคล้องระหว่างสเปรดชีตได้ยาก สุดท้ายต้องคอยอุดด้วยโค้ดที่ไม่จำเป็นเลยถ้าย้ายไปใช้เครื่องมือที่เหมาะสมตั้งแต่เนิ่น ๆ
    • นอกจาก “การเปลี่ยนแปลงในวงกว้างยากหรือเป็นไปไม่ได้” แล้ว ยังไม่มี version control ด้วย
      อาจเก็บสเปรดชีตไว้ใน RCS ได้ก็จริง แต่ดู diff เพื่อตรวจสอบได้ไหมว่าการเปลี่ยนแปลงที่กำลังจะ push เป็นไปตามที่ตั้งใจ? ตรวจประวัติ diff ได้ไหมว่าระบบเปลี่ยนไปอย่างไรเมื่อเวลาผ่านไป? ถ้าหลายคนแก้ไขพร้อมกัน merge ได้ไหม? มี working copy สำหรับทดลองแยกต่างหากหรือเปล่า หรือแก้ไขสำเนา production โดยตรงแบบไม่มี safety net?
    • ถ้าใช้ชีตเป็นแค่ storage ก็อาจโอเคอยู่ แต่อยากรู้ว่าขีดจำกัดด้านขนาดอยู่ประมาณไหน

  • เป็นเรื่องที่น่าสนใจ ก่อนที่สตาร์ทอัพจะ pivot ไปเป็น Loom เคยเป็นบริษัททดสอบผู้ใช้ชื่อ Opentest และแทนที่ผู้ร่วมก่อตั้งจะสร้างฐานข้อมูลกับแดชบอร์ดเพื่อให้ดูผู้ร้องขอการทดสอบผู้ใช้รายใดรายหนึ่งได้ พวกเขาก็เอาทุกอย่างใส่ลงใน Google Sheets ไปเลย
    มันดีมาก ไม่มี downtime การเข้าถึงเปิดกว้าง และมีคนดู/แก้ไขแค่ 3 คนจึงไม่มีการชนกัน ไม่ต้องจัดการอัปเกรดหรือบำรุงรักษาฐานข้อมูลด้วย ผมนึกถึงการตัดสินใจนี้บ่อย ๆ และรู้สึกว่า “แนวปฏิบัติด้านวิศวกรรมที่ดี” จำนวนมากที่ผมเรียนมา ดูด้อยลงไปเมื่อเทียบกับข้อเท็จจริงที่ว่า การเคลื่อนที่ให้เร็วและใช้งานได้จริงอาจเป็นจุดทะลุทะลวงอัจฉริยะในทุกระยะได้

    • เห็นด้วย Google Sheets เป็นทางเลือกที่ดีสำหรับสตาร์ทอัพหรือบริษัทเล็ก ๆ ที่ต้องการประคองตัวอย่างรวดเร็ว
      เคยใช้กับข้อมูลของหลายระบบที่มีคนแก้ไขเพียงหยิบมือ หากมีโค้ดที่รอบคอบสักหน่อยและ caching ก็ใช้เป็นฟรอนต์เอนด์ CRUD สำหรับข้อมูลระบบสำคัญได้ง่าย เช่น ตรวจสอบแล้วซิงก์ไป S3 นอกจากนี้ยังดีสำหรับแดชบอร์ดชั่วคราว และถ้าเชื่อมกับ API หรือใส่โค้ด Google Scripts แบบกำหนดเอง ก็จัดการ private API ได้ด้วย เคยทำรายงานขนาดค่อนข้างใหญ่ที่มีหลาย view, pivot table, query และ lookup ให้รีเฟรชอัตโนมัติตามกำหนดเวลา ของที่พัฒนาเองควรต้องดีกว่า Google Sheets มากก็จริง แต่ไม่มีทางสร้างได้เร็วกว่า พอถึงเวลาที่ต้องการอะไรที่ใหญ่และดีกว่านี้ ความต้องการก็มักชัดขึ้น และคุณก็น่าจะอยู่ในสถานะที่รับภาระทรัพยากรพัฒนาได้แล้ว
    • ผมเป็นวิศวกรซอฟต์แวร์ในบริษัทใหญ่ แต่หลายโปรเจกต์ที่ผมทำงานอยู่มี Google Sheets เป็นฐาน บางที่ใช้เป็นฟรอนต์เอนด์ บางที่ใช้เป็นแบ็กเอนด์
      ส่วนหนึ่งก็เพราะแม้แต่การใช้เครื่องมือวิศวกรรมง่าย ๆ อย่าง React หรือ Postgres ก็มีขั้นตอนยุ่งยากเกินไป
    • Google Sheets อาจมองได้ว่าเป็น ฐานข้อมูล NoSQL แบบ managed ที่มี UI สำหรับจัดการในตัว
    • ถ้าทำได้แค่ dump ข้อมูลทางเดียวก็ดูเป็นไอเดียที่ดี ปัญหาเริ่มเมื่อชีตทั้งเจ็ดต้องควบคุมกระบวนการอื่น ๆ ในฐานะแหล่งข้อมูลที่ authoritative
      คนที่เขียนลงสเปรดชีตโดยพื้นฐานแล้วทำการแปลงใด ๆ ก็ได้ จึงพังได้ง่ายมาก
    • ดูใช้ได้ แต่ก่อนเอาข้อมูลบริษัทใส่ Google Sheets ควรขออนุญาตก่อน

  • ไม่จำเป็นต้องมี wrapper หรูหราอะไรเลย แค่เปิด https://script.google.com/ ก็เข้าถึง API หลายตัวของ Google ได้อยู่แล้ว และสามารถผสานชีตเข้ากับการส่งอีเมลผ่าน Gmail, เปลี่ยนปฏิทิน, สร้างหน้าเว็บ, ประมวลผลอินพุตจากฟอร์ม ฯลฯ ได้
    ปัญหาคือไม่มี การทำงานแบบ transaction เหมือนฐานข้อมูลจริง เช่น เมื่อต้องการล็อกทรัพยากรบางอย่าง อาจล้มเหลวได้

    • ในเว็บนี้ ทุกครั้งที่มีใครสร้างวิธีแก้ปัญหาแบบเรียบง่ายสำหรับปัญหาบางอย่าง ก็จะมีอีกคนมาบอกว่ามีตัวเลือกที่ซับซ้อนกว่ามากอยู่แล้ว

  • แปลกใจที่ยังไม่มีใครพูดถึง Spread API: https://spreadapi.roombelt.com/
    เป็น Google Sheets / Apps Script ฟรี แค่คัดลอกไปวางในชีตก็แปลงให้เป็น CRUD แบบครบถ้วนได้เลย แม้จะมีการจำกัดความเร็วอยู่บ้าง แต่ก็ฟรีทั้งหมด เมื่อก่อนเคยคิดจะทำบริษัทที่ใช้ Sheets เป็นฐาน แต่พอถึงขั้นที่ผู้ใช้ “เต็มใจจะจ่ายเงิน” ก็มักเป็นจุดที่เริ่มเกินขอบเขตของ Sheets แล้วด้วย ข้อจำกัดทำให้รู้สึกอยากย้ายไป Turso, Cloudflare D1, Pocketbase มากกว่าจะอยู่กับ Sheets หรือ SpreadAPI ต่อ

    • ดีใจจริง ๆ ที่โปรเจกต์เล็ก ๆ ของผมมีประโยชน์
      ถ้ามีไอเดียปรับปรุงหรือ PR ส่งมาได้เสมอที่นี่: https://github.com/ziolko/spreadapi
    • ดูดีนะ แต่เหมือนว่าแม้แต่การแทรกหลายแถวในคำขอเดียวก็ยังทำไม่ได้ เลยดูค่อนข้างจำกัด
    • อยากรู้ว่า การจำกัดความเร็วของ Spread API เป็นอย่างไร หาในเว็บไซต์ไม่เจอ

  • ถ้าใช้ในลักษณะคล้ายกัน ผมอยากแนะนำ PocketBase
    สัปดาห์ที่แล้วกำลังมองหา data store แบบกำหนดเองที่เข้าถึงผ่าน API ได้ และคิดว่าจะทำแบ็กเอนด์บน Google Sheets แต่ PocketBase ใช้ง่าย และไม่มีข้อจำกัด 60 ครั้งต่อนาที การ deploy ด้วย CapRover บน VPS ราคาถูกก็ง่ายมาก
    https://pocketbase.io/
    https://developers.google.com/sheets/api/limits

    • โหวตให้ PocketBase อีกเสียง สำหรับการเก็บข้อมูลทั่วไปใช้ PocketBase แล้วส่งออก CSV ผ่าน API ไปยัง Google Sheet เพื่อดูและแก้ไข
      ใช้ง่ายมากสำหรับการทำ prototype และงานจริง การใช้ Google Sheet เป็นแบ็กเอนด์ก็ดี แต่ยังต้องมีอย่างการยืนยันตัวตน
    • ลองดู PocketBase แล้ว แต่ยังไม่ค่อยเข้าใจว่าควรใช้ยังไง รู้จัก SQLite และใช้ SQL ได้ดี แต่ยังนึกภาพการใช้งานจริงไม่ออก
    • อินฟราของผมโฟกัสเรื่อง scalability 100% น่าจะทำงานร่วมกันได้ แค่แบ่งค่าใช้จ่ายกันก็พอ
      ช่วยส่งข้อความมาที่นี่เพื่อให้ผมได้ข้อมูลติดต่อ: https://www.zerosheets.com/contact

  • เมื่อไม่นานมานี้ผมสร้างเว็บแอปเต็มรูปแบบโดยใช้แค่ AppsScript กับ Google Sheets เป็นฐานข้อมูล และเขียนไว้ที่นี่ https://thetechenabler.substack.com/i/142898781/making-a-sim... รวมถึงเปิดซอร์สไว้ที่นี่ https://github.com/eeue56/simple-link-aggregator
    เป็นประสบการณ์ใหม่ และไอเดียที่มี ที่เก็บข้อมูล ที่คนไม่ใช่นักพัฒนาจัดการได้ง่าย แล้วเอาเว็บแอปที่ไม่ต้องตั้งค่าเซิร์ฟเวอร์มาวางไว้ข้างหน้า ก็น่าสนใจมาก แต่ AppsScript ช้าเกินไปสำหรับการใช้แบบนี้ จึงยากที่จะเป็นประสบการณ์ที่ดี Zerosheets ดูดี และถ้ากลับมาดูไอเดียนี้อีกก็คงจะสำรวจเพิ่มเติม

    • “การเอาเว็บแอปไปต่อกับที่เก็บข้อมูลที่คนไม่ใช่นักพัฒนาจัดการได้ง่าย โดยไม่ต้องตั้งค่าเซิร์ฟเวอร์” นี่ไม่ใช่หนึ่งใน use case ของ Airtable เหรอ?

  • ไอเดียโปรเจกต์ userscript ถัดไปของผมต้องใช้สิ่งแบบนี้ เป็นงานใช้ส่วนตัว แต่ต้องกรอกใบรายงานผลการเรียนผ่านเว็บ UI ที่ทรมานสุด ๆ
    การกรอกข้อมูลลงสเปรดชีตง่ายกว่ามาก เมื่อก่อนก็เคยทำแบบนั้นจริง ๆ แต่โรงเรียนเอาสิ่งที่เหมือนล้อเลียนเว็บแอป CRUD แบบพื้นฐานสุด ๆ ที่แย่มากเข้ามา โดยบอกว่าจะทำให้ “ง่ายขึ้น” เลยอยากทำ userscript ที่อ่านจากสเปรดชีตแล้วไปกรอกเว็บฟอร์มที่อ่านเขียนลำบากนั้น ยังไม่ได้เริ่มเพราะเขียนบล็อกโพสต์เรื่องประสบการณ์ userscript ครั้งก่อนยังไม่เสร็จ และกลัวฝันร้ายเรื่องการยืนยันตัวตน ในบริบทของ userscript อาจง่ายกว่าหรือยากกว่าก็ได้ เพราะมันอยู่ในหน้าเว็บ บางทีอาจทำ flow แบบ OAuth ทั่วไปจากตรงนั้นได้

    • ไม่ทราบว่าได้ลองดู Apps Script แล้วหรือยัง
    • ถ้าใช้ Google Sheets ก็คงต้องทำ OAuth flow แบบทั่วไป อีกทางหนึ่งคือใช้ Excel แล้ว automate ด้วยแมโครง่าย ๆ
      โดยส่วนตัวคิดว่าวิธีที่ง่ายที่สุดคือข้ามส่วนที่ซับซ้อนของสคริปต์อย่างการยืนยันตัวตนไปเลย แล้วคัดลอกค่าจากคลิปบอร์ดมาวาง จากนั้นค่อยประมวลผลข้อมูล

  • ไม่กี่วันก่อนตอนกำลังดูทางเลือกของ template และ CMS ผมเจอเครื่องมือภายในของ NPR สำหรับเผยแพร่บทความที่มีข้อมูล แผนภูมิ และ visualization: https://github.com/nprapps/dailygraphics-next
    ในนั้นมี วิธีใช้ Google Sheets เป็น CMS ด้วย เลยน่าสนใจ

  • ผมทำสิ่งที่คล้ายกันมากไว้ที่ https://github.com/kellpossible/avalanche-report/ เริ่มจาก Google Sheets เพราะทำให้วนปรับปรุง flow การป้อนข้อมูลได้เร็ว
    เมื่อใช้ร่วมกับเซิร์ฟเวอร์ ก็สามารถสร้างแผนภูมิและไดอะแกรมแบบกำหนดเองได้ด้วยการใส่ URL query ที่ประกอบไว้ลงในฟังก์ชัน IMAGE ส่วนการอ่านจะ cache ไว้ในฐานข้อมูล SQLite local ตอนนี้กำลังย้ายออกจาก Google Sheets เพราะการตั้งค่าค่อนข้างยุ่งยาก และใน use case ของเรา ไม่สามารถป้องกันไม่ให้ผู้ใช้แก้ไขฟิลด์ผิดได้อย่างสมบูรณ์ ถึงอย่างนั้นจนถึงตอนนี้มันก็รองรับงานได้ดีมาก และเป็นจุดเริ่มต้นที่แนะนำได้อย่างยิ่งสำหรับทุกคน

  • เมื่อก่อนผมขับเคลื่อนหน้าเมนูของเว็บไซต์ร้านอาหารด้วย Google Sheet ใช้ได้สมบูรณ์แบบ
    ทุกครั้งที่ร้านอาหารมีอะไรเปลี่ยน ก็อัปเดตสเปรดชีตแล้วแสดงบนเว็บทันที ถ้าเผลอแก้อะไรผิดก็ย้อนกลับได้

    • ไม่กี่สัปดาห์ก่อนผมตั้งค่าสิ่งเดียวกันเป๊ะให้ร้านอาหารแห่งหนึ่ง เรียบง่ายและฟรี
      ทำให้ Apps Script build เว็บไซต์เมื่อมีการอัปเดต ดังนั้นเมื่อแก้ไขเมื่อไรก็จะ trigger การ rebuild และ deploy ใหม่เป็น static site