Slide 1

Slide 1 text

Phoenix LiveViewを プロダクション利用してみた所感 2022/05/18 @ElixirImp#20 株式会社スマートアルゴリズム 齋藤 和也

Slide 2

Slide 2 text

自己紹介 名前:齋藤 和也 HN:mokichi 年齢:34歳 居住:東京都 出身:福岡県 🍜 Twitter:@mokichi_s12m 株式会社スマートアルゴリズム 代表取締役 複数社で技術顧問を務める クラウドインフラを含むサーバサイド開発やDevOps が得意 Elixirを触り始めて4年ぐらい?

Slide 3

Slide 3 text

2022/02 WEB+DB PRESSデビューしました 🎉 WEB+DB PRESS Vol.127 特集2「作って学ぶPhoenix」 Elixirコミュニティのメンバーと共著 担当:第5章 LiveViewによるフロントエンドの開発

Slide 4

Slide 4 text

LiveViewの簡単な紹介

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

正式なお仕事として使ってみた所感 といってもレビューがメインでした...

Slide 9

Slide 9 text

どんなシステムを開発したのか ● 企業の人がとある業務で使うためのSaaS(BtoB) ● ユーザ向け画面と管理画面がある ● 基本的なCRUDの画面がほとんど ● 一部複雑なUIの画面がある

Slide 10

Slide 10 text

LiveViewの良かったところ ● JSをほとんど書かず、ElixirだけでSPAを開発 ○ APIを大量に作る必要がなかった ○ フロントエンド/バックエンドを分業していなかったが、 LiveViewだけ触ればいいため コンテキストスイッチは少なかった(ように思う) ○ 業務で利用するサービスで、 JSゴリゴリみたいな要件がなかったというのもある ● ReactやVue.jsといった人気ライブラリと似た開発体験 ○ 宣言的な記述、コンポーネント分割 ○ CSSに関する仕組みはないが、 Tailwind CSSを導入することでスタイリングの収拾が つかなくなるようなことはなかった ○ CSSフレームワークを使わないのであれば、ほぼ Tailwind CSS一択な予感

Slide 11

Slide 11 text

LiveViewのハマりどころ ● JSのライブラリと違ってサーバサイドで状態を持つため、ステートフルなシ ステムになって扱いが難しくなる ○ データを更新しようとしたらすでに DBから削除されていた、みたいなことが起こる ○ LiveViewが保持しているデータをそのままビジネスロジックに渡すのではなく、 APIを叩くときのよ うにDBから再取得するようにしたほうが安心できる ● ファイルアップロード周りのエコシステムが充実しておらず、自前実装が多 くなる(LiveViewだけの問題ではない) ○ バリデーションやDB・外部ストレージとの連携など、他言語だと当たり前にライブラリがあるような ものの開発があまり盛り上がっていない ○ 自前で実装すると、どうしてもバグや考慮漏れが発生しやすくなる

Slide 12

Slide 12 text

どんなときにLiveViewを選ぶのが良いか ● 地図やグラフ、3DCGといった、JSのライブラリを使わないと実現が難しい ような機能が少ない場合 ○ Hooksという機能を使えばJSとLiveViewを連携できるようになるが、そればかりになるなら JSで SPA作ったほうがいい(APIやWebSocketサーバはPhoenixで作れるよ!) ○ ツール系のサービスや管理画面の開発とかだとすごく向いてそう ● Webアプリのみ提供する場合 ○ スマホアプリを提供するなら APIを作って共通利用したほうがいい ● 利用者の通信環境がそこそこ良いことが保証される場合 ○ WebSocketでつなぎっぱなしになるため、通信環境が貧弱だとまともに利用できなくなる

Slide 13

Slide 13 text

LiveViewがこの先生きのこるには

Slide 14

Slide 14 text

適材適所とエコシステムの充実 ● 何にでも言えるが、LiveViewにも向き不向きがあるため、 技術やチーム、サービスの特性を考慮して技術選定しよう ○ 当然ながら銀の弾丸ではないが、使える範囲は思っている以上に広いと思う ○ 採用実績を地道に作っていけば、次第に使われるようになっていくはず ... ● QiitaやZenn等への投稿やライブラリの開発でエコシステムを充実 させ、Elixir界隈を盛り上げよう ○ 特に、ファイルアップロード系のライブラリは個人的に作ってみたい ● そもそもLiveViewはまだバージョン1にも達していない(伸びしろ!)

Slide 15

Slide 15 text

もっとElixirでお仕事したいよぉ〜〜