ココナラでの共通UIについての取り組み
こんにんちは。
フロントエンド開発グループのいっちーです。
ココナラでは新規サービスの立ち上がりに伴い、ヘッダやフッタといったすべてのサービスで利用される共通UIの需要が高まってきております。
今回はその課題解決に向けて現在進行している取り組みについてのお話になります。
課題感
すべてのサービスで共通のUIとして実装されているヘッダ、フッタに変更が生じた場合、すべてのサービス（リポジトリ）で修正する必要がありその都度対応していくのがものすごく大変なのは想像に難くないかと思います。
そこで共通UIを外部に切り出し、各サービスがそれを参照するような構成にすることでこれを解消しようと考えます。
マイクロフロントエンドにおける水平分割を部分的に行うようなイメージです。
技術選定
技術選定に際し下記の3点について考慮しました。
- サービスごとのフレームワークとの競合
- パフォーマンス劣化
- SEOへの影響
弊社のサービスではフロントエンドのフレームワークとしてVue(Nuxt)もしくはReact(Next.js)が利用されています。
これらのフレームワークや今後採用されうるフレームワークとの競合を回避するため、CSSのスコープを限定的にできるWeb Componentsを採用しました。
Web Componentsはもともと命令型のAPIしかなくクライアントサイドレンダリングでしか動作しないイメージがありましたが、今年に入って宣言的なAPIであるDeclarative Shadow DOMが主要ブラウザでサポートされたこともあり採用に踏み切りました。
これによりパフォーマンス劣化(特にCLSによるもの)とSEOへの影響はクリアできたかと思います。
また共通UIはあらかじめ静的に生成してCDNに配備したものを各サービスで読み込んで表示しています。
共通UI側でサーバーサイドレンダリングさせないことでパフォーマンスへの影響を低減しており、静的なコンテンツであることでサービス側でキャッシュを持つこともできるのでさらに影響を小さくすることも可能です。
ログイン後に表示されるユーザーアイコンなどユーザー固有の部分に関してはクライアントサイドでAPIからデータを取得した後に表示させるようにしています。
断念した部分
今回、ユーティリティファーストなCSSフレームワークのUnoCSSを利用しようとしたのですが、共通のカスタムプロパティがコンポーネントごとに出力されてしまい配信するコンテンツサイズが肥大化してしまう懸念があったため見送ることにしました。
まとめ
本番環境にリリースされておらず開発していく中でまだまだ課題がでてくるかと思いますが、ココナラのすべてのサービスに関わる重要な機能ですので「こんなはずじゃなかった」ということにならないように、それらの課題に1つ1つ対応していければと思います。
最後に
ココナラではエンジニアを募集しています！
よろしければぜひ以下のページもご覧ください。
フロントエンドの求人はこちらです！
Discussion