【Ltech#14】大きめレガシープロジェクトのフロント行く末

575 Views

March 01, 21

#ltech #lifull #lifull home's #technology #frontend #engineering #フロントエンド開発 #技術的負債 #レガシーシステム #Stimulus #WebComponents

スライド概要

2021/03/02　Ltech#14 「LIFULL HOME'S」のフロントエンドについて語り尽くします！

中島拓哉

株式会社LIFULL

@LIFULL

スライド一覧

LIFULL HOME'Sを運営する株式会社LIFULLのアカウントです。 LIFULLが主催するエンジニア向けイベント「Ltech」等で公開されたスライド等をこちらで共有しております。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

ダウンロード(pdf - 609.89kB)

関連スライド

pmconf2023【プロダクトマネジメントで高速PDCA】アウトカムが激増したLIFULL HOME’Sのグロース事例

プロダクトマネジメントプロダクトマネージャー lifull

株式会社LIFULL 23.5K

HNSWの内部構造

lifull hnsw search

株式会社LIFULL 19.8K

CloudWatch LogsからGrafana Lokiにログ基盤を移行

lifull aws grafana ログ

株式会社LIFULL 18.2K

PrometheusとGrafanaで追求する、より良いアプリケーションの可観測性

lifull grafana ログ kuberentes

株式会社LIFULL 14.6K

LIFULL HOME'SでのSolrの構成と運用の変遷

lifull lifull home's engineering

株式会社LIFULL 11.4K

趣味と仕事の違い、現場で求められるアプリケーションの可観測性

技育祭エンジニア engineering programming プログラミング

株式会社LIFULL 9.6K

各ページのテキスト

大きめレガシープロジェクトのフロント行く末 Nakajima Takuya 2010年4月入社アプリケーションエンジニアと入社して10年、現在はややフロント寄りの業務をしている学生時代にネトゲで嶌田氏と知り合い、その辺がきっかけでウェブ開発を始めたウェブとDHHが大好き Copyright© LIFULL Co.,Ltd. All Rights Reserved. Twitter: @nazomikan

大きめレガシープロジェクトのフロント行く末 LIFULL HOME’Sのサイト内情 10年前にリニューアル後、以降大きなリニューアルもなく開発され続けてきたサイト(部分的にマイクロサービス化している) アプリケーション側の技術スタック • Symfony2 • Twig • jQuery + Backbone.View的な設計 • Babel/Rollup/Sass/部分的にtypescript JavaScript files (ignore library) 1498 files. 136565 lines. Copyright© LIFULL Co.,Ltd. All Rights Reserved. おかしいな、さほど大きめではないような…

大きめレガシープロジェクトのフロント行く末既存コードでのViewの考え方基本的にはBackbone.Viewと同じ考え方テンプレートパーツと対になるJavaScript側のViewがあって、それ単位で振る舞いを記述している Backbone同様にイベント機構の統一などは重なっている View同士の連携はグローバルなカスタムイベントを使ってやりとりしていた。 (Backbone.Eventsをグローバル放出してpubsubするのとほぼ同じ) Copyright© LIFULL Co.,Ltd. All Rights Reserved.

大きめレガシープロジェクトのフロント行く末後にわかるコードの隙結局なくならないDOM探索 • DOM探索で埋漏れるビジネスロジック • セレクタに依存してDOMの変更に弱い • 似た少し違うコードが量産されて、build時間が増大していく • 横方向の区切りはできても縦方向のviewの境目が守られない • 安易なDOM探索が子,親viewを犯してしまう • 親・子分割がうまく行かず巨大な親だけ作られていく • インスタンスが露出して外部から使役される懸念が残る • XHR等で後に挿入されたHTMLへの振る舞いのアタッチが手動になり、それでまたビジネスロジックが汚染される Copyright© LIFULL Co.,Ltd. All Rights Reserved.

DHH say: 「HTMLとJavaScriptの概念的距離を圧縮したい」 HTMLとJavaScriptはよく見ると、PHPとmysqlみたいな関係にあるセレクタというQueryを投げてDOMを得ているデータアクセスには手続きが必要で、壊れやすく、ビジネスロジックはそのコードに埋もれ、さらには独特なそのデータ形式(NodeList等)の normalizeに苦心する DOMが変数やプロパティにアクセスするかのように簡単に参照でき、それらへのアクセスに制限を設けることができれば問題は軽減する Copyright© LIFULL Co.,Ltd. All Rights Reserved.

10.

11.

大きめレガシープロジェクトのフロント行く末しぶり続けて早5年、理由はよくあるやつ • Existing DOMの安心感はなんだかんだ半端ない • JavaScriptが最悪動かなくてもHTMLドキュメントとして最低限機能を果たしてくれる • SEO的な懸念の回避 • インデックスが遅いだけで大丈夫とか、心配ならSSRすればとかあるけどそもそもそんな不安や複雑性を抱えたくない • 現行の資産(負債)の大きさ故にシステム構成レベルの変革を望まない • 負債は一括返済ではなく分割で返済したい • • カバーする領域がJavaScript領域に閉じてない • 将来的な別ソリューションの登場時に撤退容易性が低い • • 返さなくていい負債は返すつもりもない命預けるなら普遍的なHTMLを軸にしたライブラリにしたい将来的にビルドプロセスをなくしたいのでxxx-loader系と縁を持ちたくない • ビルド時間を気にしたり、ビルド設定に時間を費やすのはソフトウェアライターとして本質的ではない Copyright© LIFULL Co.,Ltd. All Rights Reserved.

12.

大きめレガシープロジェクトのフロント行く末わがままな私たち • Existing DOMのアプローチでDOMアクセスを省略できて、インスタンスを隠蔽できて、振る舞いのアタッチを自動化できたらそれが一番いい • ついでに流行りのライブラリのようにHTML側からみて振る舞いが宣言的であれば嬉しい • ブラウザの敷いた道から離れたくない (戻るの大変なので) • WebComponentsがやや近しい?気がしてそれの発展に期待していた • 振る舞いの自動アタッチ • インスタンスの隠蔽 • DOMアクセスの制限(shadow root内に限られる) Copyright© LIFULL Co.,Ltd. All Rights Reserved.

13.

14.

大きめレガシープロジェクトのフロント行く末 Stimulus • Basecamp製のJavaScriptライブラリ (thx. dhh, sstephenson, javan • Existing DOMアプローチ • DOMの変更をMutationObserverで監視し、対象のDOMが出現したら自動で定義した振る舞いをアタッチする。 • 操作したいDOMを明記しておくとgetterメソッドが自動で作られてプロパティのようにアクセスできる data-cotrollerでHTMLと JavaScriptを接続 data-action=“evt>controller#method”で要素に振る舞いをアタッチ data-[controller]-target=“xxx” の要素にthis.xxxTargetでアクセス Copyright© LIFULL Co.,Ltd. All Rights Reserved.

15.

16.

大きめレガシープロジェクトのフロント行く末 Stimulus is great solution • Existing DOMの絶対的安心感 • アクセスするDOMは事前に定義でき、それらはシームレスにプロパティとしてアクセスできる • HTML側にアクセスする要素を記述するのでJavaScript側はHTMLの構造変更の影響をほぼ受けない • 振る舞いは自動でアタッチされインスタンスの隠蔽で悩む必要はない • HTML側からみて振る舞い、状態が宣言的である • HTMLの出現時に自動で振る舞いや状態がアタッチされるのでサーバ側からは大きなjsonを返す必要はなくHTMLを返せばいい • • 必然的に型・スキーマの重要性が下がる Primitiveなcontrollerの再利用製の高さ • DOMをセレクタで探索するのではなくDOM側に対象を明記するのでDOMの構造差異に強く振る舞い自体の再利用製が高い • disclosure/remover/modal/content-loader等、再利用製高い単一用途のcontrollerを作ってガンガン再利用できる Copyright© LIFULL Co.,Ltd. All Rights Reserved.

17.

大きめレガシープロジェクトのフロント行く末 LIFULL HOME’Sの戦略 • stimulusでHTMLとJavaScriptの概念的距離を縮め、さらには振る舞いを宣言的にする • 全移行はコストかかるので本気ださない • • 長い期間、既存設計と併用になるがそれを厭わない(困らないので) • 新しくそこを触るときにstimulusで置き換えられるところをそっと切り出すだけでいい Build Processをいつか捨てるという夢は諦めない (ie11が死んだ暁には…) • bye babel, bye bundler, bye transpiler • アプリケーションの設定的な複雑性から解放されたい • PrimitiveなControllerを大量生産してコード量を1/20(次期目標)にしていく • 新規開発において既存のcontrollerをロードしてhtml側で属性組み立てるだけでそのページの振る舞いが完成することが夢 • 書いたコードは例外なく将来負債になる • コードは書かないに越したことはない Copyright© LIFULL Co.,Ltd. All Rights Reserved.

18.

19.