FastUI: Tạo web UI nhanh hơn và tốt hơn bằng Python

 (github.com/pydantic)
24 điểm bởi GN⁺ 2024-03-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • FastUI là một cách mới để xây dựng giao diện người dùng cho ứng dụng web bằng mã Python khai báo
  • Một tập hợp các mô hình Pydantic và interface TypeScript dùng để định nghĩa giao diện người dùng
  • Nếu là nhà phát triển Python, bạn có thể xây dựng web app phản hồi bằng React mà không cần dùng JavaScript hay npm
  • Nhà phát triển frontend có thể tập trung xây dựng các component có thể tái sử dụng mà không phải sao chép-dán lặp đi lặp lại
  • Với tất cả người dùng, có thể đạt được sự phân tách trách nhiệm thực sự: backend định nghĩa toàn bộ ứng dụng còn frontend chỉ triển khai giao diện người dùng
  • Cung cấp sẵn nhiều component: xác thực dựa trên token, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

Cách dùng thực tế

  • FastUI gồm bốn phần:
    • Gói PyPI fastui: cung cấp các mô hình Pydantic và utility cho UI component. Hoạt động rất tốt với FastAPI nhưng không phụ thuộc vào FastAPI, và cũng có thể dùng với các web framework Python khác.
    • Gói npm @pydantic/fastui: gói React TypeScript cho phép tái sử dụng cơ chế và kiểu của FastUI khi triển khai component riêng.
    • Gói npm @pydantic/fastui-bootstrap: triển khai/tùy biến toàn bộ component FastUI bằng Bootstrap.
    • Gói npm @pydantic/fastui-prebuilt: cung cấp phiên bản dựng sẵn của ứng dụng FastUI React mà không cần cài gói npm hay tự build bất kỳ thứ gì. Gói Python cung cấp một trang HTML đơn giản để phục vụ ứng dụng này.

Nguyên tắc (bản dài)

  • FastUI là một triển khai của các nguyên tắc RESTful, nhưng không theo cách thường được hiểu, mà theo các nguyên tắc được định nghĩa trong luận án tiến sĩ của Roy Fielding.
  • Theo các nguyên tắc RESTful, frontend không cần biết về ứng dụng đang được xây dựng, mà chỉ cần cung cấp mọi component cần thiết để cấu thành giao diện.
  • Xây dựng ứng dụng theo cách này mang lại nhiều lợi ích quan trọng:
    • Chỉ cần viết mã ở một nơi để xây dựng tính năng mới.
    • Có thể tách biệt hoàn toàn việc triển khai frontend và backend.
    • Có thể tái sử dụng bộ component mã nguồn mở, vì các component không cần biết ngữ cảnh mà chúng sẽ được dùng.
    • Có thể dùng Pydantic, TypeScript và JSON schema để đảm bảo hai phía đang giao tiếp bằng một schema đã được thống nhất.

Vượt ra ngoài Python và React

  • Nguyên tắc này không chỉ giới hạn ở ứng dụng Python và React; miễn là giao tiếp bằng cùng schema và cách mã hóa đã thống nhất, nó có thể được dùng bởi bất kỳ frontend và backend nào triển khai schema đó.

Ý kiến của GN⁺

  • FastUI có tiềm năng đơn giản hóa quy trình phát triển bằng cách cung cấp cho nhà phát triển backend một phương thức hiệu quả để mở rộng ứng dụng mà không cần phát triển frontend.
  • Công nghệ này làm rõ sự phân chia vai trò giữa frontend và backend, qua đó tạo ra môi trường giúp tận dụng tối đa chuyên môn của từng bên.
  • Hiện tại FastUI vẫn là một dự án đang trong quá trình phát triển, vì vậy cần xem xét kỹ về độ ổn định và tính năng trước khi sử dụng trong môi trường production thực tế.
  • Khi áp dụng FastUI, cần cân nhắc khả năng tương thích với quy trình phát triển frontend hiện có, khả năng tái sử dụng và mở rộng của component, cũng như khía cạnh bảo trì dài hạn của dự án.
  • Lợi ích khi chọn công nghệ này là rút ngắn thời gian phát triển và thúc đẩy quy trình phát triển lấy backend làm trung tâm, nhưng đổi lại độ linh hoạt của frontend có thể bị hạn chế, đồng thời sự hỗ trợ từ cộng đồng và tài liệu có thể còn tương đối thiếu.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-03
Ý kiến trên Hacker News

  • Ý kiến về việc ghép chặt tầng trình bày với mã nguồn

    • Ghép chặt tầng trình bày với mã nguồn: Tầng trình bày không nên gắn quá chặt với mã nguồn. Một ngôn ngữ mẫu thay vì Python sẽ phù hợp hơn, và sẽ tốt hơn nếu có thể render template bằng nhiều ngôn ngữ khác nhau.

  • Kinh nghiệm phát triển ứng dụng với FastUI và Streamlit

    • Sử dụng FastUI và Streamlit: Đã dùng Streamlit để làm prototype nhưng đôi khi thấy bất tiện. FastUI vẫn còn một số điểm chưa hoàn thiện, nhưng khi dùng cho các ứng dụng nhẹ thì cho cảm giác phản hồi nhanh hơn Streamlit.

  • Ý kiến về Django và HTMX

    • Django và HTMX: Sự kết hợp giữa Django và HTMX rất đẹp và chạy nhanh. Chỉ cần gửi phần mã được render cho frontend, và vẫn có thể quản lý DB khi quy mô tăng lên.

  • Tính thực dụng của ứng dụng nội bộ trong việc xử lý sự kiện phía máy chủ

    • Xử lý sự kiện phía máy chủ: Khái niệm này không mới, và đã có các ví dụ khác như Solara dựa trên React hay NiceGUI dựa trên Vue. Nó rất thực dụng cho ứng dụng nội bộ, nhưng phải chấp nhận một chút độ trễ khi mọi control đều xử lý sự kiện ở phía máy chủ.

  • Sự gia tăng của các framework frontend cần backend server

    • Độ phức tạp của framework frontend: Nhiều framework frontend phải chạy backend server chỉ để render HTML cơ bản. Có thể đặt câu hỏi liệu những tính năng mà các framework này cung cấp có thực sự đủ để biện minh cho mức độ phức tạp đó hay không.

  • So sánh trải nghiệm giữa FastUI và NiceGUI

    • FastUI và NiceGUI: NiceGUI mang lại trải nghiệm rất dễ dùng ngay khi bắt đầu. FastUI chủ yếu trông giống một form adapter cho các model Pydantic.

  • Ảnh hưởng của sự phát triển AI tới use case của dự án

    • AI và phát triển frontend: Ý tưởng để backend developer nhanh chóng tạo UI bằng chính ngôn ngữ của họ vẫn có giá trị, nhưng nhu cầu cho các dự án kiểu này có thể suy yếu vì chỉ cần dùng AI vài giờ là đã có thể tạo ra một UI cơ bản.

  • Kinh nghiệm phát triển side project bằng Dart/Flutter

    • Sử dụng Dart/Flutter: Việc viết side project bằng Dart/Flutter giúp giảm ma sát và bớt phiền toái hơn. Nếu phải viết web app và Flutter không phù hợp, thì sẽ dùng HTMX.

  • So sánh với Java Server Faces và giới hạn của trừu tượng hóa phía máy chủ

    • Kinh nghiệm với Java Server Faces: Cảm giác khá giống Java Server Faces. Những nỗ lực chuyển các sắc thái tinh vi của phát triển frontend sang dạng trừu tượng phía máy chủ có lẽ chỉ hiệu quả với một tập ứng dụng hạn chế, chẳng hạn như UI quản trị.

  • Câu hỏi liệu round trip tới server có phù hợp để xây dựng giao diện người dùng hay không

    • Round trip tới server: Đặt câu hỏi liệu việc phải qua lại với server cho mỗi tương tác phía client có phải lúc nào cũng là ý tưởng tốt để xây dựng giao diện người dùng hay không.