新規サービスにNuxt.jsを採用した話
島村崇氏：こんにちは。本日は「新規サービスにNuxt.jsを採用した話」という内容でお話をさせていただこうと思います。よろしくお願いします。
（会場拍手）
まず自己紹介ですが、DMM.comのテクノロジー本部CTO室でエンジニアをしている島村と申します。経歴は、2014年にDMMに入社してこんな感じで、実は一昨年まではマネジメントもやっていました。
では、さっそくなのですが、今回紹介するサービスは、9月リリースに向けて今まさに新規開発しているEC系のサービスになります。開発メンバーですが、エンジニアは5名で、デザイナー、POという構成で、その中にフロント実装するエンジニアが3名います。
アプリケーションの構成はざっくりとこんな感じで、フロントはサービスサイトと管理サイト、両方ともNuxt.jsで実装していて、API側はGo言語で実装しています。
Nuxt.jsを採用した理由
今回、Nuxt.jsを採用した理由をご紹介したいと思います。先ほどご紹介したように複数人でフロントの実装をするので、コードの統一感を担保したいという話があがりました。Nuxt.jsはフレームワークのルールに沿って開発ができるので、コードの統一感が担保できてよいのではないか。ということで、まずこれが採用理由の1つになりました。
もう1つが学習コストを抑えられることです。Nuxt.jsは公式ドキュメントが充実していたり、DMM社内での知見が多かったり、また同じチーム内にもNuxt.jsの経験者がいたので、これらも今回の採用理由になりました。あと、Vue.jsなので、HTML・CSS・JSの基本的な知識があれば、Reactなどに比べて理解しやすいのかなと思って採用しました。
では、実際Nuxt.jsを選んでどうだったのか。
学習コストについては狙いどおりでした。公式ドキュメントを読めばだいたい実装ができたのと、なにかあったときにすぐ聞ける知見が社内にあったのはやはり心強かったです。
あとは、環境構築が楽でした。Nuxt.jsは必要なライブラリが最初からだいたい揃っていて、プラグインも設定ファイルを書くだけで簡単に追加できてしまうので、すごくよかったなと。あと、Vuexやルーティングの設定はNuxt.jsがやってくれるので、ここらへんもかなり楽できたかなと思います。
ただ、Nuxt.jsを導入したときの注意点なのですが、ルールに沿ってとはいっても、やはり設計はいろいろ必要だったなという感想です。例えば、値の保持をどうするか。storeもしっかり設計しないとすぐ肥大化してしまうので、ここらへんの設計周りとか。
やはりコンポーネントの粒度の話ですね。やはりここらへんもしっかり設計しておかないと、componentsディレクトリ配下がぐちゃぐちゃで大変なことになってしまいます。
あとは、今回サーバサイドレンダリングをしたのですが、Nuxt.jsはVue.jsに加えて独自のライフサイクルメソッドがあったり、サーバサイドとクライアントサイドで挙動が変わったりするので、そこをしっかり意識して実装する必要はありました。とくに画面をリロードしたときの挙動はけっこう注意が必要でした。
それとwindowなどのブラウザのAPIですね。今回ローカルストレージも使ったのですが、そういったところにアクセスする際は「クライアントサイドのみ」という分岐処理を書く必要もありました。
開発に伴って工夫したこと
では、今回、開発に伴って工夫したことをいくつか紹介したいと思います。
まずパフォーマンスチューニングなのですが、1つがコンポーネントのキャッシュです。propsの値で一意の描画結果が決まるものは、サーバ側でコンポーネントをキャッシュしました。v-forなどで何度も繰り返すようなコンポーネントには、キャッシュ処理は有効だったかなと思います。
ソースコードだとこんな感じです。このserverCacheKey というメソッドを実装して、propsをもとにキャッシュするためのキーを文字列でリターンしてあげると、サーバ側でコンポーネントをキャッシュすることができます。別途モジュールのインストールは必要なのですが、実装としてはこんな感じになります。
もう1つパフォーマンスチューニングとして、非同期コンポーネントがあげられます。v-ifなどで必要なタイミングで表示するコンポーネントの場合は、非同期コンポーネントにするとJSのbundleに含まれなくなるので、初期表示にかかる時間の削減が期待できます。
ソースコードだとこんな感じです。コンポーネント設定するところをこういったかたちでダイナミックインポートすると、非同期で必要なコンポーネントを必要なタイミングで読むようになります。
あと最後に、今回はCSS設計に「RSCSS」という手法を採用しました。Vue.jsなのでしっかりとしたCSS設計は不要だったのですが、複数人で開発するのに何もルールがなのはやはり可読性が悪くなるので、最低限のルールとして採用しました。
コンポーネントベースにマッチしていて、ルールもシンプルで学習コストもけっこう低く、採用してみてよかったので、ご紹介したいと思います。
ソースコードだとこんな感じで、コンポーネント名はkebab-caseで2単語以上というルールがあります。その下のelementsはなるべく子セレクタを使用して定義します。あと、variantではダッシュ・プレフィックスをつけて、こんな感じで書きます。
BEMなど使われている方はわかるかなと思うのですが、それよりもかなりシンプルに書けるので、見通しも良くなってよかったかなと思います。
というわけで、まとめです。Nuxt.jsを導入してみて、学習コストは狙いどおり低めにできたのと、環境構築にかかるコストがかなり削減できたのですごくよかったなと。
ただし、注意としては、細かい設計は必要という点と、サーバサイドとクライアントサイドの処理をしっかり意識する必要があるという点。あとは、CSSはゆるくでもルール設定しておいてよかったな、という感想です。
では、ちょっと最後スポンサーっぽいことを言わせてください。DMM.comでは共に働くエンジニアを募集しています。ということで、本日はどうもありがとうございました。
（会場拍手）
