Instant 1.0 – แพลตฟอร์มแบ็กเอนด์สำหรับแอปที่เขียนด้วย AI

 (instantdb.com)
14 คะแนน โดย GN⁺ 19 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • แบ็กเอนด์โอเพนซอร์สที่เพิ่ม การซิงก์แบบเรียลไทม์, โหมดออฟไลน์, การยืนยันตัวตน, ที่เก็บไฟล์ ให้กับแอปที่สร้างด้วย vibe coding ได้ในครั้งเดียว
  • การสร้างแบ็กเอนด์ไม่ใช่การบูต VM แต่เป็นการ เพิ่มแถวใน DB จึงสร้างแบ็กเอนด์ได้ภายในไม่กี่มิลลิวินาที และถ้าไม่ใช้งานก็ไม่มีค่าใช้จ่าย
  • จากฝั่งฟรอนต์เอนด์ ใช้เพียง db.useQuery และ db.transact ก็จัดการ คิวรีเชิงสัมพันธ์และการเปลี่ยนแปลงข้อมูล ได้ทันที — ไม่จำเป็นต้องตั้ง API server แยก
  • มี optimistic update เป็นค่าเริ่มต้น ทำให้ UI ตอบสนองทันทีแม้เครือข่ายช้า และหากล้มเหลวก็ rollback อัตโนมัติ
  • การอัปโหลดไฟล์ก็จัดการเป็นแถวใน DB เช่นกัน ดังนั้นเมื่อลบโพสต์ ไฟล์แนบก็ถูกลบแบบ CASCADE ด้วย — ไม่ต้องเขียนโค้ดซิงก์กับ S3
  • สามารถเลือกใช้วิธียืนยันตัวตนอย่าง Magic Code, OAuth, Guest Auth ได้ และใช้ Presence เพื่อทำฟีเจอร์ "มีใครออนไลน์อยู่บ้าง" ได้ทันที
  • AI agent สามารถ สร้างแอป, เปลี่ยน schema, ตั้งค่าสิทธิ์การเข้าถึง ได้โดยตรงผ่าน API/CLI ทำให้เชื่อมไปจนถึงการดีพลอยแอปแบบฟูลสแตกได้ด้วยพรอมป์ต์เพียงอย่างเดียว
  • แค่บรรทัดเดียว npx create-instant-app ก็สร้างโปรเจกต์ได้ทันทีในสภาพแวดล้อมที่ต้องการ เช่น NextJS, Bun, Vite
  • ภาษา query อย่าง InstaQL ใช้ไวยากรณ์แบบ JavaScript object ได้ตรง ๆ จึงทำ dynamic query แบบ GraphQL ได้โดยไม่ต้องมีขั้น build หรือ codegen
  • โครงสร้างแบบ multi-tenant บน Postgres ที่พัฒนามา 4 ปี รองรับการรันหลายพันแอปบนอินสแตนซ์เดียว และเปิดโอเพนซอร์สทั้งหมดบน GitHub

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

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

 
GN⁺ 19 일 전
ความคิดเห็นบน Hacker News

  • ถามตรงๆ เลยนะ ไม่เข้าใจว่าทำไมแอปที่ vibe codedถึงต้องมีเฟรมเวิร์ก
    แค่สั่ง coding agent ให้เขียนฟรอนต์เอนด์ด้วย HTML5/Vanilla JS/CSS และแบ็กเอนด์ด้วยภาษาที่ต้องการก็พอ
    ไม่ต้องมี dependency เป็นร้อยตัว และให้เอเจนต์จัดการ deploy ต่อก็จบ

    • ผมลองทำแบบนั้นจริงๆ แล้ว และตอนนี้ LLM ทำงานได้มีประสิทธิภาพกว่ามากเมื่ออยู่บนเฟรมเวิร์ก
      พอโค้ดเยอะขึ้น ไม่ใช่แค่ต้นทุนที่เพิ่ม แต่ประสิทธิภาพก็ตกลงด้วย และบั๊กกับ abstraction ที่ไม่จำเป็นก็เพิ่มขึ้น
      สุดท้ายก็เสียเวลาไปกับการพยายามให้มันสร้างเฟรมเวิร์กที่ดีขึ้นมาเอง
      ผมเลยคิดว่าใช้เฟรมเวิร์กที่มีอยู่แล้วในข้อมูลฝึกจะดีกว่า
      สำหรับโมเดลตอนนี้ ผมไม่แนะนำกับงานที่ใหญ่เกินหน้า landing page
    • ฟังดูเหมือนมุก แต่เหตุผลเดียวกันนี้ก็อธิบายได้ว่าทำไมเราไม่เขียนโค้ดด้วย assembly language
      abstraction ที่ดีช่วยเรื่องความอ่านง่ายและการดูแลรักษา และ HTML/CSS/JS แบบล้วนๆ ก็ไม่ใช่กระแสหลักแล้ว
      มนุษย์ต้องสามารถเข้าใจและตรวจสอบได้ และไม่ควรเปลือง token กับเวลาไปกับการประดิษฐ์ล้อใหม่
      LLM ก็เหมือนมนุษย์ตรงที่สามารถจมอยู่ใน spaghetti code ที่ซับซ้อนได้
    • มีอยู่หลายเหตุผล
      1. โปรเจ็กต์ไม่จำกัด: แบ็กเอนด์แบบ VM เดิมๆ มีค่าใช้จ่ายสูง แต่ Instant สร้างได้ไม่จำกัด
      2. ประสบการณ์ผู้ใช้: ทำฟีเจอร์อย่าง multiplayer, offline mode, optimistic update ได้ง่าย
      3. ฟีเจอร์ครบ: มีทั้งการเก็บไฟล์ การแชร์เคอร์เซอร์ การสตรีมโทเคน ฯลฯ มาให้ในตัว
        ตัวอย่างเช่น สามารถสร้างแบ็กเอนด์ได้ด้วยการคลิกปุ่ม และทำแอป todo แบบเรียลไทม์เสร็จด้วยโค้ด 25 บรรทัด
    • ถ้าใช้เฟรมเวิร์ก ก็เหมือนได้ scaffolding code ชุดแรกเกิน 10,000 บรรทัดมาแบบเสียค่า token เป็นศูนย์
      ทำให้ข้ามไปทำ business logic ได้ทันที และทำงานอยู่ภายในแพตเทิร์นกับเครื่องมือที่ผ่านการพิสูจน์แล้ว
      ซอฟต์แวร์องค์กรยังไงก็ยังต้องมี codebase ขนาดใหญ่ ดังนั้นเฟรมเวิร์กจึงมีคุณค่ามาก
      เพราะมันมอบ solution ที่ผ่านสนามรบมาแล้ว สำหรับ edge case มากมายที่ถูกแก้ไว้ก่อนแล้ว
    • ง่ายมาก คือการลดขอบเขตที่ต้องดูแลเอง แล้วโยนความรับผิดชอบนั้นให้เฟรมเวิร์ก
      ถ้าเลือกเฟรมเวิร์กดีๆ ก็ลดการตัดสินใจนับพันอย่างและภาระในการดูแลรักษาได้
      สุดท้ายแล้วเฟรมเวิร์กมีอยู่ก็เพราะเรื่อง ความสามารถในการขยายตัว

  • สงสัยจริงๆ ว่าคนต้องการอะไรแบบนี้กันไหม
    จะมีสักกี่คนที่สร้างแอป multiplayerแบบ Figma หรือ Linear?
    ส่วนใหญ่น่าจะเป็นแอป CRUD มากกว่า แล้วจะมีเหตุผลอะไรให้ต้องผูกกับเทคโนโลยีปิดล่ะ

    • ประเด็นที่น่าสนใจคือ ถ้าการสร้างแอป multiplayer ง่ายขึ้น ก็จะมีแอปประเภทนี้มากขึ้น
      อย่างเช่น Linear ก็เป็น multiplayer แล้วทำไมแอป CRUD อื่นๆ จะไม่เป็นล่ะ
      ถ้า abstraction ดีพอ แอปที่ขับเคลื่อนด้วย sync engine กลับจะสร้างได้ง่ายกว่าเสียอีก
      ทีม Linear ก็พูดไว้แบบนั้นในทวีตนี้
    • เผื่อไว้เป็นข้อมูล Instant เป็นโอเพ่นซอร์ส 100%
      GitHub repository
    • เห็นด้วย เดี๋ยวนี้โค้ดส่วนใหญ่เขียนโดย LLM อยู่แล้ว จึงไม่ต้องใช้เทคโนโลยีซับซ้อนอะไรมาก
      แอป CRUD นั้นเรียบง่ายและทำซ้ำได้ จึงเหมาะกับ AI มาก
      แบ็กเอนด์เป็น Go binary ฟรอนต์เอนด์เป็น React ก็ครอบคลุมได้ 99.9% ของกรณีใช้งาน
      โหนดราคา 5 ดอลลาร์ต่อเดือนก็รองรับ 100,000 MAU ได้สบายๆ

  • ดูเหมือนเป็นเครื่องมือที่เหมาะกับโปรเจ็กต์ส่วนตัวมาก
    แต่อยากให้ส่วนของ “agent” ผสานรวมได้ลื่นไหล กว่านี้อีกหน่อย
    มีทางไหมที่จะรู้ได้ว่า coding agent ของผมควรจัดการสิ่งนี้อย่างไร?
    ถ้าเพิ่มลิงก์ไปยัง skill ที่เกี่ยวข้องในบล็อกก็น่าจะดี

    • คิดว่าเป็นข้อเสนอที่ดี เลยอัปเดตบทความทันทีแล้ว
      ลิงก์ PR
    • มี skill อยู่แล้ว
      เพิ่มได้ด้วยคำสั่ง npx skills add instantdb/skills
      และแนะนำให้ scaffold โปรเจ็กต์ด้วย bunx/pnpx/npx create-instant-app

  • ยินดีกับการเปิดตัว! InstantDB เป็นหนึ่งในเครื่องมือที่สนุกที่สุดเท่าที่เคยใช้มา
    แม้จะลองแค่โปรเจ็กต์เล่นเล็กๆ แต่มันเรียบง่ายและตรงไปตรงมาที่สุดในสายนี้
    เพียงแต่ตัวผลิตภัณฑ์หลักดีมากอยู่แล้ว เลยรู้สึกว่าการเน้น AIดูแปลกๆ นิดหน่อย
    ช่วงนี้ถ้าจะระดมทุนคงต้องวางตำแหน่งแบบนั้นหรือเปล่า

    • ขอบคุณมาก!
      เราไม่ได้อัปเดตเว็บไซต์เลยนับตั้งแต่โอเพ่นซอร์สในเดือนสิงหาคม 2024
      หลังจากโพสต์ตอนนั้น ผู้ใช้ที่สร้างแอปด้วย AI เพิ่มขึ้นอย่างมาก
      เราเลยปรับ messaging ใหม่ และลงทุนเพื่อทำให้ประสบการณ์ของ agent สนุกขึ้น
    • ขอบคุณครับ การเน้น AI ไม่ใช่การตลาด แต่สะท้อนพฤติกรรมผู้ใช้จริง
      ผู้ใช้ส่วนใหญ่ของเราเขียนโค้ดด้วย AI อยู่แล้ว เราเลย optimize ให้เข้ากับสิ่งนั้น

  • อาจจะเข้าใจผิดก็ได้ แต่สงสัยว่าทำไมถึงเป็นคำว่า ‘AI-coded’
    ในฐานะคนที่มองหาแบ็กเอนด์เรียบง่าย มันดูเป็นทางเลือกที่ยอดเยี่ยม
    แต่ยังไม่ค่อยเห็นว่ามันต่างจากแบ็กเอนด์อื่นๆ ตรงไหนในแง่ความเป็น AI-first
    แล้วก็ดูเหมือนจะเน้น TS เป็นหลัก เลยสงสัยว่ามีแผนทำ mobile native binding ไหม

  • เดโมดีมากจริงๆ แนวคิดเรื่อง การเชื่อมกับ AI ยอดเยี่ยม แต่คำอธิบายยังน้อยไปหน่อย
    ผมดูบทช่วยสอนแล้ว แต่มันเน้นการสร้างบัญชี SaaS
    แพตเทิร์นแอปเชิง reactive อย่าง Triples, Datalog, Clojure ถูกหลอมรวมอยู่ใน Instant ได้ดีมาก
    ส่วนตัวผมว่า Clojure ยาก และ Datalog ก็ไม่คุ้นเคย แต่ abstraction ของ Instant น่ายินดีมาก
    ถ้ามีตัวแปลง InstantQL-Datalog แยกออกมาเป็นคอมโพเนนต์ต่างหากก็น่าจะมีประโยชน์มาก
    เมื่อแบ็กเอนด์อิง Clojure ก็เข้าใจได้ที่เลือก Postgres แต่สำหรับการ deploy แบบ local, SQLite อาจเรียบง่ายกว่า

  • ประทับใจที่ทำ “query เชิงสัมพันธ์ + realtime” ได้จริง
    แต่ UI ของคอนโซลยังให้ความรู้สึกว่าใส่ใจน้อยกว่าส่วน infra หรือเว็บไซต์
    ยินดีกับการออกเวอร์ชัน 1.0 และจากนี้ก็จะสร้างต่อบน Instant

    • ขอบคุณครับ!
      เราปรับปรุงเดโมบนหน้าแรก บทความ และเอกสารไปเยอะมาก
      ตัวแดชบอร์ดมีแผน redesign ภายในไม่กี่สัปดาห์
      สิ่งที่น่าสนใจคือ ถึง AI agent จะสร้างแอปและแก้สคีมาได้
      ผู้ใช้ก็ยังชอบสำรวจข้อมูลด้วย Explorer component โดยตรงมากกว่า

  • หาเรื่อง rate limiting ในเอกสารไม่เจอเลย ไม่แน่ใจว่ามีหรือเปล่า

  • ผมเคยใช้ Pocketbase และ Instant ก็ดูเหมาะกับการใช้งานคล้ายกัน
    แต่จุดแข็งของ Pocketbase คือ ความสามารถในการขยายฝั่งเซิร์ฟเวอร์
    เขียน hook ด้วย JS หรือ Go เพื่อเพิ่มฟีเจอร์อย่าง push notification ได้
    เลยสงสัยว่า InstantDB ทำอะไรแบบนี้ได้ไหม หรือจำเป็นต้องทำ worker แยก
    แล้วก็อยากรู้ว่ามีแผนทำ Dart SDK ไหม

    • ฝั่งเซิร์ฟเวอร์สามารถใช้ db.subscribeQuery เพื่อตอบสนองต่อการเปลี่ยนแปลงได้
      เร็วๆ นี้จะเพิ่มฟีเจอร์ webhook และมีแผนรองรับ SDK สำหรับภาษาอื่นๆ ในระยะยาวด้วย

  • เห็นด้วยกับมุมมองที่ว่า “แพตเทิร์นที่กำหนดไว้ล่วงหน้าช่วยลดต้นทุน token”
    ตอนเราสร้าง empla.io ก็เจอประสบการณ์คล้ายกัน
    ถ้าปล่อยให้ agent ตัดสินใจเรื่องแบ็กเอนด์เอง การใช้ token จะเพิ่มขึ้น 3-4 เท่า
    ภาษาคิวรีเชิงประกาศให้ประสิทธิภาพกับ AI มากกว่ากับมนุษย์เสียอีก
    มีสองเรื่องที่สงสัย

    1. ถ้า agent เพิ่ม relation ใหม่กลางเซสชัน จะจัดการ schema evolution อย่างไร
    2. มีฟีเจอร์จัดการ งบประมาณค่าใช้จ่าย ต่อเซสชันมาให้ในตัวไหม หรือผู้ใช้ต้องทำเอง
 
picopress 18 일 전

แม้แต่ของที่โค้ดแบบไวบ์ก็ยังเอามาโปรโมตกันด้วยเหรอ