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
Elixir以外の言語もよく使うエンジニアが考える、Phoenix LiveViewの使いどころ
Search
mokichi
May 17, 2024
Programming
1
360
Elixir以外の言語もよく使うエンジニアが考える、Phoenix LiveViewの使いどころ
【東京】Elixir/Phoenix 入門セミナー(初心者歓迎)
https://daimon-ex.connpass.com/event/312959/
mokichi
May 17, 2024
Tweet
Share
More Decks by mokichi
See All by mokichi
Rubyistから見たElixir
mokichi
1
430
動的画像変換サービス「imagepix」のご紹介
mokichi
1
260
Phoenix LiveViewをプロダクション利用してみた所感
mokichi
3
930
Phoenix1.6で標準搭載されたLiveViewに入門してみよう
mokichi
0
220
Ractorが出たからRubyの並列処理をおさらいする
mokichi
0
750
WebエンジニアのためのKubernetesサクッと入門
mokichi
1
150
未来予知できない凡人の生存戦略
mokichi
0
74
Other Decks in Programming
See All in Programming
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
1.1k
Team operations that are not burdened by SRE
kazatohiei
1
260
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
110
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
250
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
100
Create a website using Spatial Web
akkeylab
0
310
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
270
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
570
ニーリーにおけるプロダクトエンジニア
nealle
0
580
C++20 射影変換
faithandbrave
0
540
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
110
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
550
Featured
See All Featured
Building Applications with DynamoDB
mza
95
6.5k
Designing for humans not robots
tammielis
253
25k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
700
A designer walks into a library…
pauljervisheath
207
24k
Designing for Performance
lara
609
69k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.3k
Code Review Best Practice
trishagee
68
18k
Transcript
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 の管理コンソールをチラ見せします