Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Phoenix LiveViewをプロダクション利用してみた所感
Search
mokichi
May 18, 2022
Programming
3
870
Phoenix LiveViewをプロダクション利用してみた所感
mokichi
May 18, 2022
Tweet
Share
More Decks by mokichi
See All by mokichi
Elixir以外の言語もよく使うエンジニアが考える、Phoenix LiveViewの使いどころ
mokichi
1
250
Rubyistから見たElixir
mokichi
1
370
動的画像変換サービス「imagepix」のご紹介
mokichi
1
240
Phoenix1.6で標準搭載されたLiveViewに入門してみよう
mokichi
0
190
Ractorが出たからRubyの並列処理をおさらいする
mokichi
0
670
WebエンジニアのためのKubernetesサクッと入門
mokichi
1
110
未来予知できない凡人の生存戦略
mokichi
0
54
Other Decks in Programming
See All in Programming
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
150
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
1k
ATDDで素早く安定した デリバリを実現しよう!
tonnsama
1
1.5k
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
150
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.3k
Beyond ORM
77web
11
1.5k
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
380
ESLintプラグインを使用してCDKのセオリーを適用する
yamanashi_ren01
2
150
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
920
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
seike460
PRO
0
230
shadcn/uiを使ってReactでの開発を加速させよう!
lef237
0
280
技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発
yuichiro_serita
0
290
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
170
14k
A Philosophy of Restraint
colly
203
16k
Done Done
chrislema
182
16k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Automating Front-end Workflow
addyosmani
1366
200k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2.1k
Become a Pro
speakerdeck
PRO
26
5.1k
Six Lessons from altMBA
skipperchong
27
3.5k
Transcript
Phoenix LiveViewを プロダクション利用してみた所感 2022/05/18 @ElixirImp#20 株式会社スマートアルゴリズム 齋藤 和也
自己紹介 名前:齋藤 和也 HN:mokichi 年齢:34歳 居住:東京都 出身:福岡県 🍜 Twitter:@mokichi_s12m 株式会社スマートアルゴリズム 代表取締役 複数社で技術顧問を務める
クラウドインフラを含むサーバサイド開発やDevOps が得意 Elixirを触り始めて4年ぐらい?
2022/02 WEB+DB PRESSデビューしました 🎉 WEB+DB PRESS Vol.127 特集2「作って学ぶPhoenix」 Elixirコミュニティのメンバーと共著 担当:第5章
LiveViewによるフロントエンドの開発
LiveViewの簡単な紹介
LiveViewとは • (ほぼ)JSを書かずにElixirだけでSPAを開発できる • 宣言的な記述ができたり、機能やUIをコンポーネントに分割できたりと、 現在主流になっているSPA開発の開発体験とかなり近い • 加えて、データの更新を各クライアントにリアルタイムに反映するといった、一般的 に面倒なことがとても簡単にできる •
「Twitterクローンを15分で作る」という動画が話題に https://www.youtube.com/watch?v=MZvmYaFkNJI (Phoenixの公式サイトに載ってます)
現在主流になっているSPA開発の問題点 • フロントエンドとバックエンドの両方を高いクオリティで対応できるエンジニアは稀 で、分業化が進みがち • ある機能を実装する際に、バックエンド側を対応しないとフロントエンド側が進めら れず、ボトルネックが発生する(逆のパターンもあり) 教えてくれ、PM。俺たちはあと何本APIを作ればいい? • OGPの設定が必要な場合のSSRや、JSのバンドルサイズが大きくなることによる
Core Web Vitalsの各指標の悪化に頭を悩ませがち
LiveViewの特徴 • (ほぼ)JSを書かずにElixirだけでSPAを開発できる ◦ フロントエンドとバックエンドがデータをやりとりするための APIを何本も作らなくていい (つまりAPIドキュメントも作らなくていい) • すべてのクライアントとWebSocketでつながっている ◦
状態をサーバに保持し、状態の更新をクライアントに反映させている ◦ ブラウザのCookieやLocalStorageのことを気にしなくていい ◦ サーバの負荷は当然増えるが、昨今はリソース調達が容易なためさほど大きな問題ではない
正式なお仕事として使ってみた所感 といってもレビューがメインでした...
どんなシステムを開発したのか • 企業の人がとある業務で使うためのSaaS(BtoB) • ユーザ向け画面と管理画面がある • 基本的なCRUDの画面がほとんど • 一部複雑なUIの画面がある
LiveViewの良かったところ • JSをほとんど書かず、ElixirだけでSPAを開発 ◦ APIを大量に作る必要がなかった ◦ フロントエンド/バックエンドを分業していなかったが、 LiveViewだけ触ればいいため コンテキストスイッチは少なかった(ように思う) ◦
業務で利用するサービスで、 JSゴリゴリみたいな要件がなかったというのもある • ReactやVue.jsといった人気ライブラリと似た開発体験 ◦ 宣言的な記述、コンポーネント分割 ◦ CSSに関する仕組みはないが、 Tailwind CSSを導入することでスタイリングの収拾が つかなくなるようなことはなかった ◦ CSSフレームワークを使わないのであれば、ほぼ Tailwind CSS一択な予感
LiveViewのハマりどころ • JSのライブラリと違ってサーバサイドで状態を持つため、ステートフルなシ ステムになって扱いが難しくなる ◦ データを更新しようとしたらすでに DBから削除されていた、みたいなことが起こる ◦ LiveViewが保持しているデータをそのままビジネスロジックに渡すのではなく、 APIを叩くときのよ
うにDBから再取得するようにしたほうが安心できる • ファイルアップロード周りのエコシステムが充実しておらず、自前実装が多 くなる(LiveViewだけの問題ではない) ◦ バリデーションやDB・外部ストレージとの連携など、他言語だと当たり前にライブラリがあるような ものの開発があまり盛り上がっていない ◦ 自前で実装すると、どうしてもバグや考慮漏れが発生しやすくなる
どんなときにLiveViewを選ぶのが良いか • 地図やグラフ、3DCGといった、JSのライブラリを使わないと実現が難しい ような機能が少ない場合 ◦ Hooksという機能を使えばJSとLiveViewを連携できるようになるが、そればかりになるなら JSで SPA作ったほうがいい(APIやWebSocketサーバはPhoenixで作れるよ!) ◦ ツール系のサービスや管理画面の開発とかだとすごく向いてそう
• Webアプリのみ提供する場合 ◦ スマホアプリを提供するなら APIを作って共通利用したほうがいい • 利用者の通信環境がそこそこ良いことが保証される場合 ◦ WebSocketでつなぎっぱなしになるため、通信環境が貧弱だとまともに利用できなくなる
LiveViewがこの先生きのこるには
適材適所とエコシステムの充実 • 何にでも言えるが、LiveViewにも向き不向きがあるため、 技術やチーム、サービスの特性を考慮して技術選定しよう ◦ 当然ながら銀の弾丸ではないが、使える範囲は思っている以上に広いと思う ◦ 採用実績を地道に作っていけば、次第に使われるようになっていくはず ... •
QiitaやZenn等への投稿やライブラリの開発でエコシステムを充実 させ、Elixir界隈を盛り上げよう ◦ 特に、ファイルアップロード系のライブラリは個人的に作ってみたい • そもそもLiveViewはまだバージョン1にも達していない(伸びしろ!)
もっとElixirでお仕事したいよぉ〜〜