FastUI: Pythonでより速く、より優れたWeb UIを作る

 (github.com/pydantic)
24 ポイント 投稿者 GN⁺ 2024-03-03 | 1件のコメント | WhatsAppで共有
  • FastUIは、宣言的なPythonコードでWebアプリケーションのユーザーインターフェースを構築する新しい方法
  • ユーザーインターフェースを定義するPydanticモデルとTypeScriptインターフェースの集合
  • Python開発者であれば、JavaScriptやnpmを使わずにReactでレスポンシブなWebアプリを構築可能
  • フロントエンド開発者は、毎回コピー＆ペーストをすることなく再利用可能なコンポーネントの構築に集中できる
  • すべての利用者にとって、バックエンドがアプリケーション全体を定義し、フロントエンドはユーザーインターフェースだけを実装するという、真の関心の分離が可能
  • 多様なコンポーネントを標準提供: トークンベース認証、GitHub OAuth、Markdown、Text、Paragraph、Heading、Code、Button、Link、Navbar、Modal、ServerLoad、Image、Iframe、Video、Table、Pagination、ModelForm

実際の使い方

  • FastUIは4つで構成される:
    • fastui PyPIパッケージ: UIコンポーネント向けのPydanticモデルとユーティリティを提供。FastAPIとうまく連携するが、FastAPIには依存しておらず、他のPython Webフレームワークでも利用可能。
    • @pydantic/fastui npmパッケージ: 独自コンポーネントを実装しながら、FastUIの仕組みと型を再利用できるReact TypeScriptパッケージ。
    • @pydantic/fastui-bootstrap npmパッケージ: Bootstrapを使ってすべてのFastUIコンポーネントを実装・カスタマイズする。
    • @pydantic/fastui-prebuilt npmパッケージ: npmパッケージをインストールしたり何かを自分でビルドしたりする必要なく、FastUI Reactアプリのビルド済みバージョンを提供する。Pythonパッケージは、このアプリを配信するシンプルなHTMLページを提供する。

原則（長いバージョン）

  • FastUIはRESTful原則の実装だが、一般的に理解されている方式ではなく、Roy Fieldingの博士論文で定義された原則に従っている。
  • RESTful原則によれば、フロントエンドは構築するアプリケーションについて知る必要はなく、インターフェースを構成するために必要なすべてのコンポーネントを提供すればよい。
  • この方式でアプリケーションを構築すると、いくつかの重要な利点がある:
    • 新機能を構築するためのコードを1か所にだけ書けばよい。
    • フロントエンドとバックエンドのデプロイを完全に分離できる。
    • オープンソースのコンポーネントセットを再利用できる。これは、コンポーネントが使われる文脈を知る必要がないため。
    • Pydantic、TypeScript、JSONスキーマを使って、双方が合意済みのスキーマで通信していることを保証できる。
    広告

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の組み合わせは美しく、素早く動作する。フロントエンドにはレンダリング済みのコードだけを送り、規模が大きくなったときにはDB管理もできる。

  • サーバー側イベント処理に関する内部アプリの実用性

    • サーバー側イベント処理: この概念は新しいものではなく、ReactベースのSolaraやVueベースのNiceGUIのような他の例もある。内部アプリには非常に実用的だが、すべてのコントロールでサーバー側でイベントを処理する際の多少の遅延は受け入れる必要がある。

  • バックエンドサーバーを必要とするフロントエンドフレームワークの増加

    • フロントエンドフレームワークの複雑さ: 多くのフロントエンドフレームワークは、基本的なHTMLをレンダリングするためにバックエンドサーバーを動かす必要がある。こうしたフレームワークが提供する機能が、その複雑さを正当化するのか疑問だ。

  • FastUIとNiceGUIの経験比較

    • FastUIとNiceGUI: NiceGUIは、箱から出してすぐ使えるような体験を提供する。FastUIは主にPydanticモデル向けのフォームアダプターのように見える。

  • AIの進歩がプロジェクトのユースケースに与える影響

    • AIとフロントエンド開発: バックエンド開発者が自分の言語で素早くUIを生成できるという発想は有効だが、AIを数時間使えば基本的なUIを生成できるため、この種のプロジェクトの必要性は弱まるかもしれない。

  • Dart/Flutterを使ったサイドプロジェクト開発経験

    • Dart/Flutterの使用: Dart/Flutterでサイドプロジェクトを書くことで、摩擦を最小限に抑え、煩わしさも少なくなる。Webアプリを書く必要があり、Flutterが適していないなら、HTMXを使うだろう。

  • Java Server Facesとの比較とサーバー側抽象化の限界

    • Java Server Facesの経験: Java Server Facesに似ていると感じる。フロントエンド開発の微妙な部分をサーバー側の抽象化に移そうとする試みは、管理UIのような限られたアプリケーション群でしか機能しないだろう。

  • サーバーとのラウンドトリップがユーザーインターフェース構築に適しているかという疑問

    • サーバーとのラウンドトリップ: クライアントの操作ごとにサーバーと往復することが、ユーザーインターフェースを構築するうえで常によいアイデアなのかという疑問が提起されている。