FastUI: สร้างเว็บ UI ที่เร็วและดีกว่าด้วย Python

 (github.com/pydantic)
24 คะแนน โดย GN⁺ 2024-03-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • FastUI เป็นแนวทางใหม่ในการสร้างส่วนติดต่อผู้ใช้ของเว็บแอปพลิเคชันด้วยโค้ด Python แบบประกาศ
  • เป็นชุดของโมเดล Pydantic และอินเทอร์เฟซ TypeScript สำหรับนิยามส่วนติดต่อผู้ใช้
  • หากเป็นนักพัฒนา Python ก็สามารถสร้างเว็บแอปแบบโต้ตอบด้วย React ได้โดยไม่ต้องใช้ JavaScript หรือ npm
  • นักพัฒนาฝั่งฟรอนต์เอนด์สามารถโฟกัสกับการสร้างคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้ โดยไม่ต้องคอยคัดลอกและวางซ้ำ ๆ
  • ทำให้แยกความรับผิดชอบได้อย่างแท้จริง โดยแบ็กเอนด์กำหนดทั้งแอปพลิเคชัน และฟรอนต์เอนด์ทำหน้าที่เพียงแสดงส่วนติดต่อผู้ใช้
  • มีคอมโพเนนต์พื้นฐานให้หลากหลาย: การยืนยันตัวตนแบบโทเค็น, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

วิธีใช้งานจริง

  • FastUI ประกอบด้วย 4 ส่วน:
    • แพ็กเกจ PyPI fastui: ให้โมเดล Pydantic และยูทิลิตีสำหรับคอมโพเนนต์ UI ทำงานร่วมกับ FastAPI ได้ดี แต่ไม่ได้พึ่งพา FastAPI จึงใช้กับเฟรมเวิร์กเว็บ Python อื่น ๆ ได้ด้วย
    • แพ็กเกจ npm @pydantic/fastui: เป็นแพ็กเกจ React TypeScript ที่ช่วยให้นำกลไกและชนิดข้อมูลของ FastUI ไปใช้ซ้ำได้ ขณะสร้างคอมโพเนนต์ของตัวเอง
    • แพ็กเกจ npm @pydantic/fastui-bootstrap: ใช้ Bootstrap ในการติดตั้งใช้งาน/ปรับแต่งคอมโพเนนต์ทั้งหมดของ FastUI
    • แพ็กเกจ npm @pydantic/fastui-prebuilt: มี FastUI React app เวอร์ชันที่ build ไว้ล่วงหน้าให้ใช้ โดยไม่ต้องติดตั้งแพ็กเกจ npm หรือ build อะไรเอง และแพ็กเกจ Python จะมีหน้า HTML แบบเรียบง่ายสำหรับให้บริการแอปนี้

หลักการ (เวอร์ชันยาว)

  • FastUI เป็นการนำหลักการ RESTful มาปรับใช้ แต่ไม่ใช่ในความหมายที่เข้าใจกันทั่วไป หากยึดตามหลักการที่ Roy Fielding นิยามไว้ในวิทยานิพนธ์ปริญญาเอกของเขา
  • ตามหลักการ RESTful ฟรอนต์เอนด์ไม่จำเป็นต้องรู้รายละเอียดเกี่ยวกับแอปพลิเคชันที่กำลังสร้าง เพียงต้องมีคอมโพเนนต์ทั้งหมดที่จำเป็นต่อการประกอบเป็นส่วนติดต่อผู้ใช้
  • การสร้างแอปพลิเคชันด้วยแนวทางนี้มีข้อดีสำคัญหลายประการ:
    • เมื่อต้องสร้างฟีเจอร์ใหม่ จะต้องเขียนโค้ดเพียงที่เดียว
    • สามารถแยกการดีพลอยฟรอนต์เอนด์และแบ็กเอนด์ออกจากกันได้อย่างสมบูรณ์
    • สามารถนำชุดคอมโพเนนต์โอเพนซอร์สกลับมาใช้ซ้ำได้ เพราะคอมโพเนนต์ไม่จำเป็นต้องรู้บริบทที่จะถูกนำไปใช้
    • สามารถใช้ Pydantic, TypeScript และ JSON schema เพื่อรับประกันว่าทั้งสองฝั่งสื่อสารกันด้วยสคีมาที่ตกลงร่วมกัน

นอกเหนือจาก Python และ React

  • หลักการนี้ไม่ได้จำกัดอยู่แค่แอปพลิเคชัน Python และ React เท่านั้น หากสื่อสารด้วยสคีมาและการเข้ารหัสที่ตกลงร่วมกันแบบเดียวกัน ก็สามารถใช้ได้กับฟรอนต์เอนด์และแบ็กเอนด์ใด ๆ ที่รองรับสคีมานั้น

ความเห็นของ GN⁺

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

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

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

 
GN⁺ 2024-03-03
ความเห็นจาก Hacker News

  • ความเห็นเกี่ยวกับการเชื่อมโยงกันระหว่างชั้นการนำเสนอและโค้ด

    • การเชื่อมโยงกันระหว่างชั้นการนำเสนอและโค้ด: ชั้นการนำเสนอไม่ควรเชื่อมติดกับโค้ดมากเกินไป ควรใช้ภาษาเทมเพลตแทน Python และจะดีกว่าหากสามารถเรนเดอร์เทมเพลตได้จากหลายภาษา

  • ประสบการณ์พัฒนาแอปด้วย FastUI และ Streamlit

    • การใช้ FastUI และ Streamlit: เคยทำต้นแบบด้วย Streamlit แต่บางครั้งก็รู้สึกว่าใช้งานไม่สะดวกนัก FastUI ยังมีส่วนที่ไม่สมบูรณ์อยู่ แต่เมื่อนำมาใช้กับแอปขนาดเบาก็พบว่าตอบสนองได้เร็วกว่า Streamlit

  • ความเห็นเกี่ยวกับ Django และ HTMX

    • Django และ HTMX: การจับคู่กันของ Django และ HTMX ดูสวยงามและทำงานได้รวดเร็ว ส่งเฉพาะโค้ดที่เรนเดอร์เป็นฟรอนต์เอนด์ออกไป และยังสามารถจัดการฐานข้อมูลได้เมื่อระบบขยายขนาดขึ้น

  • ความเหมาะสมเชิงปฏิบัติของแอปภายในสำหรับการจัดการอีเวนต์ฝั่งเซิร์ฟเวอร์

    • การจัดการอีเวนต์ฝั่งเซิร์ฟเวอร์: แนวคิดนี้ไม่ใช่เรื่องใหม่ และมีตัวอย่างอื่นอย่าง Solara ที่อิง React หรือ NiceGUI ที่อิง Vue ใช้งานได้จริงมากสำหรับแอปภายใน แต่ต้องยอมรับว่าจะมีความหน่วงเล็กน้อยเมื่อจัดการอีเวนต์ของทุกคอนโทรลจากฝั่งเซิร์ฟเวอร์

  • การเพิ่มขึ้นของเฟรมเวิร์กฟรอนต์เอนด์ที่ต้องใช้แบ็กเอนด์เซิร์ฟเวอร์

    • ความซับซ้อนของเฟรมเวิร์กฟรอนต์เอนด์: เฟรมเวิร์กฟรอนต์เอนด์จำนวนมากต้องรันแบ็กเอนด์เซิร์ฟเวอร์เพื่อเรนเดอร์ HTML พื้นฐาน จึงน่าตั้งคำถามว่าความสามารถที่เฟรมเวิร์กเหล่านี้มอบให้นั้นคุ้มค่ากับความซับซ้อนหรือไม่

  • เปรียบเทียบประสบการณ์การใช้งาน FastUI และ NiceGUI

    • FastUI และ NiceGUI: NiceGUI มอบประสบการณ์ที่พร้อมใช้งานได้ดีทันทีตั้งแต่แกะกล่อง ส่วน FastUI ดูเหมือนจะเป็นตัวปรับฟอร์มสำหรับโมเดล Pydantic เป็นหลัก

  • ผลกระทบของความก้าวหน้าด้าน AI ต่อกรณีการใช้งานของโปรเจกต์

    • AI และการพัฒนาฟรอนต์เอนด์: แนวคิดที่ให้นักพัฒนาแบ็กเอนด์สร้าง UI ได้อย่างรวดเร็วด้วยภาษาที่ตนถนัดยังคงใช้ได้ แต่ตอนนี้สามารถใช้ AI ไม่กี่ชั่วโมงเพื่อสร้าง UI พื้นฐานได้ จึงอาจทำให้ความจำเป็นของโปรเจกต์ลักษณะนี้ลดลง

  • ประสบการณ์พัฒนาโปรเจกต์ส่วนตัวด้วย Dart/Flutter

    • การใช้ Dart/Flutter: การเขียนโปรเจกต์ส่วนตัวด้วย Dart/Flutter ช่วยลดแรงเสียดทานและความยุ่งยากได้มาก หากจำเป็นต้องเขียนเว็บแอปและ Flutter ไม่เหมาะ ก็คงจะเลือกใช้ HTMX

  • การเปรียบเทียบกับ Java Server Faces และข้อจำกัดของการทำ abstraction ฝั่งเซิร์ฟเวอร์

    • ประสบการณ์กับ Java Server Faces: ให้ความรู้สึกคล้าย Java Server Faces ความพยายามที่จะย้ายความละเอียดอ่อนของการพัฒนาฟรอนต์เอนด์ไปไว้ใน abstraction ฝั่งเซิร์ฟเวอร์ น่าจะใช้ได้เฉพาะกับชุดแอปพลิเคชันที่มีขอบเขตจำกัด เช่น UI สำหรับการจัดการ

  • คำถามว่าการทำ roundtrip กับเซิร์ฟเวอร์เหมาะกับการสร้างส่วนติดต่อผู้ใช้หรือไม่

    • การทำ roundtrip กับเซิร์ฟเวอร์: มีการตั้งคำถามว่าการต้องไปกลับกับเซิร์ฟเวอร์ทุกครั้งที่มีการโต้ตอบจากฝั่งไคลเอนต์ เป็นแนวคิดที่ดีเสมอไปหรือไม่สำหรับการสร้างส่วนติดต่อผู้ใช้