Elixir以外の言語もよく使うエンジニアが考える、 Phoenix LiveViewの使いどころ 2024/05/17 @daimon.ex 株式会社スマートアルゴリズム　齋藤 和也

名前：齋藤 和也 (36)　HN：mokichi 居住：東京都　出身：福岡県 🍜 X (旧Twitter)：@mokichi_s12m　GitHub：mokichi 株式会社スマートアルゴリズム 代表取締役 兼 エンジニア 複数社で技術顧問を務める クラウドインフラを含むバックエンド開発や DevOpsが得意 今までに使ったプログラミング言語： C, C++, Java, Ruby, PHP, JavaScript, Python, Objective-C, Elixir, TypeScript, Rust, Go, etc. 自己紹介

書籍『Elixir実践入門』を出版しました 🎉 2024年2月、技術評論社様より出版 (ISBN 9784297140144) WEB+DB PRESS Vol.127 (2022年2月) Phoenix特集の書籍化 Elixirコミュニティのメンバーと共著 全19章のうち、以下の4章分を担当 第7章：Phoenixの概要 第9章：phx.gen.authによる認証 第10章：LiveViewによるフロントエンドの開発 第11章：実践的な Webアプリケーションの開発

Phoenix LiveViewの概要

● (ほぼ) JavaScriptを書かずにElixirだけでSPAを開発できる ● 宣言的な記述ができたり、機能やUIをコンポーネントに分割できたりと、現在 主流になっているSPA開発の開発体験とかなり近い ● 加えて、データの更新を各クライアントにリアルタイムに反映するといった、一 般的に面倒なことがとても簡単に できる ● 「Twitterクローンを15分で作る」という動画が話題に https://www.youtube.com/watch?v=MZvmYaFkNJI Phoenix LiveViewとは

● フロントエンドとバックエンドの両方を高いクオリティで対応できる エンジニアは稀で、分業化が進みがち ● ある機能を実装する際に、バックエンド側を対応しないとフロントエンド側が進 められず、ボトルネックが発生する (逆のパターンもあり) ● OGPの設定が必要な場合のSSRや、JSのバンドルサイズが大きくなることに よるCore Web Vitalsの各指標の悪化に頭を悩ませがち 現在主流になっているSPA開発の問題点

● (ほぼ) JavaScriptを書かずにElixirだけでSPAを開発できる ○ フロントエンドとバックエンドがデータをやりとりするための APIを 何本も作らなくていい (つまりAPIドキュメントも作らなくていい) ● すべてのクライアントとWebSocketでつながっている ○ 状態をサーバに保持し、状態の更新をクライアントに反映させている ○ ブラウザのCookieやLocalStorageのことを気にしなくていい ○ サーバの負荷は当然増えるが、昨今はリソース調達が容易なため さほど大きな問題ではない (そもそもElixirはリソース効率が良い) Phoenix LiveViewの特徴

● Ruby ○ Ruby on Rails ― Hotwire ※Rails以外でも使える ● PHP ○ Laravel ― LiveWire ● C# ○ .NET ― Blazor など、非常に注目されている技術 他の言語にも同じような仕組みのものがある

Phoenix LiveViewの使いどころ

技術選定における大前提 ● 銀の弾などない ○ これを選べば万事OK...なんてものはない ● 技術的優位性よりも環境を重視する ○ Web開発においては、何を選んでもそこまで大きな差はない ○ 「札束で殴る」という選択肢を常に持っておく

● 組織を見る ○ フロントエンドとバックエンドを分業しているか ○ 開発チームが複数あるか ○ 人の入れ替わりが激しいか ○ 組織内での採用実績が豊富にあるか → 目的の達成を最優先する ● 技術を見る ○ 技術的優位性があるか ○ ユーザの動作環境に適しているか ○ 使い続ける覚悟があるか → 流行り廃りに惑わされない 普段、何を見て選んでいるか

● 組織を見る ○ フロントエンドとバックエンドを明確に分業していない ○ 開発メンバーが多くない ○ 身近に経験者がいる (実務かどうかは問わない) ○ しばらくは自分の手を離れることがない ● 技術を見る ○ ユーザのネットワーク環境が良いことを前提にできる ○ システム構成をシンプルに保ち、金銭的・人的コストを抑えたい ○ Elixirが好き！→ 長く運用するうえで無視はできない どんなときにPhoenix LiveViewを選ぶか

自社プロダクトでの採用事例

ユーザーがアップロードした画像を事前に変換しておくのではなく、参照される際に必 要なサイズ・フォーマットに変換して返すサービス https://www.docswell.com/s/s12m/ZXY7XP-imagepix 動的画像変換サービス「imagepix」

imagepix のアーキテクチャ概要 画像変換処理は TypeScriptで開発し、 AWS Lambdaで動かしている 管理コンソールは Phoenix LiveViewで開発し、 Fly.ioで動かしている

● 画像変換処理 ― どちらかというと技術重視 ○ リクエスト数の変動に耐えられるようにしたい！ ○ インフラの面倒をできるだけ見たくない → AWS Lambda ○ Lambdaに載せるのが楽で、画像変換がやりやすい → TypeScript ● 管理コンソール ― どちらかというと環境重視 ○ 手間をかけず、早く確実に作りたい！ ○ 開発環境が整っていて採用実績もある (＆Elixirが好き！) → LiveView ○ インフラに手間とコストをかけたくない → Fly.io なぜ技術を使い分けているか

Phoenix LiveViewにチャレンジしよう！ 興味があれば、後ほど imagepix の管理コンソールをチラ見せします󰱢