Chapter 01

はじめに

alivelimb
alivelimb
2022.05.26に更新

こんな悩みはないでしょうか?

  • Web アプリ作ってみたいけど、何から手をつけていいから分からない
  • Flask や FastAPI を使ってみたけど、HTML/JS/CSS がよく分からず、挫折してしまった
  • 作成した Web アプリのインターネット公開や社内でのデモ共有を素早く行いたい

本書ではStreamlitを活用してHTML, JS, CSS を一切使わずWeb アプリケーションを作成します。単なる Streamlit の使い方紹介に留まらず、Web アプリケーションの仕組みや TypeHint を活用したバグの発生しにくいコーディングを紹介します。

なぜ本書を書いたのか

本書は主に以下のような方を対象にしています。

  • Web アプリケーションの構築経験がない新米エンジニア
  • Python はかけるが、HTML/JS/CSS が苦手な Pythonista
  • 細かい UI の設定はせず、検証・デモ用の Web アプリを短期間で作りたい開発チーム

ここに挙げているのは上から「過去の私」「執筆時点の私」「過去の私の開発チーム」となっています。つまり私が「あったらいいな」と思っているものを実装・執筆した形です。同じ悩みを抱えている方がいれば一読頂ければと思います。

どうやって作ったか

対象読者の悩みを解決するために、次の 3 つの要素が必要と考えました。

  1. Web アプリケーションの基礎知識
  2. 参考にしてもらえる品質のコード
  3. HTML/JS/CSS を一切書かず、Python だけで実装する

Web アプリケーションの基礎知識

想定読者の新米エンジニアの場合、Web アプリケーションの仕組みがよく分かっていないということもあるでしょう。(私も学生の頃、Django で勉強してみようと思い立ったものの、セッションの仕組みや論理モデルのリレーションやにつまづいた経験があります。)

本書では Web アプリケーションの基本的な仕組みについても補足、参考情報を示すなどして、実装だけでなく基礎知識についても理解を深めやすくしています。コードを書くのは楽しいですが、コードを書くのが目的にならないように、実装するものを明確に示していきます。

Web アプリケーションの構成要素はフロントエンドとバックエンドの 2 つや、プレゼンテーション層(ブラウザ)、アプリケーション層(AP サーバ)、データ層(DB)の 3 層に分解されますが、本書はフロントエンドを対象範囲としています。しかしバックエンドからのレスポンス考慮して設計・実装するため、バックエンドの知識についても一部対象としています。

参考にしてもらえる品質のコード

本書では Web アプリケーションを実装しますが、参考にして頂くからにはコードの品質も担保したいと考えています。静的解析や自動補完の恩恵を得られるように TypeHint を活用したり、オブジェクトやメソッドを適切な粒度に分けることを意識しています。

ここで注意しておきたいのは「アプリケーションの品質」ではなく「コードの品質」であるということです。本書ではテストコードについては対象外としています。そのためアプリケーションの品質が担保できているとは言えません。テストコードの実装については FutureWork として、今後取り組みたいと思っています。

静的解析や自動補完を有効にした VSCode での Python 環境構築については記事にしているので、適宜参照してください。

HTML/JS/CSS を一切書かず、Python だけで実装する

Flask などのフレームワークを用いて Web アプリケーションを作成する場合、テンプレートエンジンJinjaを活用して HTML を動的に生成したり、Bootstrapを導入して事前定義された UI コンポーネントを活用することもあるでしょう。

また最近ではPyScriptという HTML 内で Python が実行できるフレームワークも登場してきました。私自身 PyScript で今後どういったことが出来るようになっているか非常に楽しみです。しかし、これらの方法はどうしても HTML/JS/CSS を書く必要があります。

「フロントエンジニア以外は HTML/JS/CSS は勉強しなくて良い」とは全く思いません。一方で、学習の挫折やデモアプリ開発の遅れの原因になるなど避けたいケースもあるでしょう。想定読者がまさにあてはまるケースだと思います。

そこで本書ではStreamlitを活用することでHTML/JS/CSS を一切書かず、Python だけで実装するWeb アプリケーションを紹介します。UI の選択肢が限られる分、Web アプリケーションの仕組みに集中できます。逆に細かいカスタマイズが出来ず本番運用には向かない面もあるため、あくまで学習・検証・デモ用のアプリケーションと考えて頂きたいと思います。

何を作ったか

本書で作成する Web アプリケーションは「八百屋さん EC サイト」(以下、YaEC)です。ログイン、商品閲覧、注文といった一般的な EC サイトに備わっている機能を盛り込んでいます。なお、あくまで学習用のデモアプリなので、実際に金銭の取引を行ったり、野菜の購入は出来ません。

作成したアプリはStreamlit Shareを用いて以下で公開しています。

画面一覧

本書で作成している画面は以下の 6 つです。

ログイン
ログイン画面キャプチャ

商品一覧
商品一覧キャプチャ

商品詳細
商品詳細キャプチャ

カート画面
カート画面キャプチャ

注文一覧画面
注文一覧画面キャプチャ

注文詳細画面
注文詳細画面キャプチャ

権限一覧

YaEC ではログイン状態に応じてページの閲覧権限を設定してます。また、ユーザ種別として「会員」「管理者」を用意していますが、現段階では「会員」と「管理者」で閲覧権限に違いはありません。

ユーザ種別 ログイン 商品一覧 商品詳細 カート画面 注文一覧 注文詳細
管理者 O O O O O O
会員 O O O O O O
非会員 O O △(※) X X X

※ 商品情報は閲覧可能、カート追加フォーム は閲覧不可

使っている技術

YaEC のシステム全体像は以下の通りです。

YaECシステム全体像

今回はフロントエンド編ということで API アクセス部分はモック化し、ローカル DB にアクセスする構成としています。ローカル DB にはdataset, TinyDBを利用しました。また、野菜のダミーデータはMimesisを利用して作成しています。

YaECシステム全体像(モック)

「なんでフロントとバックエンドを分けたの?」と思う方もいるかと思います。確かに YaEC ぐらいの規模のアプリをつくるだけであれば、分けない方が開発速度も早まると思います。分けた理由は以下の 2 点です。

  • 想定読者である新米エンジニアに Web アプリケーションの基礎を示すため
  • AWS/GCP などのクラウドサービス上にデプロイする際に、ベストプラクティスに基づくため

本書では教育的な観点とスケール性の観点から分けることを選択しましたが、実際に Streamlit でちょっとしたデモアプリを作る場合は、開発速度を優先した方がよいケースもあると思います。その場合はフロント、バックで分けずにモノレポで開発してもよいでしょう。

筆者からのお願い

私は 主に Python, AWS を用いたデータ分析の業務経験は数年ありますが、フロントエンド開発・Web アプリケーション開発に関しては趣味レベルの経験しかありません。冒頭でもお伝えした通り、想定読者には私自身も含まれています。

読者の方で「この設計はこう変えた方が良いのでは?」「このように書いた方がコードの品質が上がるのではないか?」といった意見があれば是非読者コミュニティでご意見頂ければと思います。私自身も本書もアップデートしていきたいと思っています。

YaEC のソースコードは GitHub で公開していますので、適宜参照してください。