大規模サービスをNuxt.jsで作り変えた話

Transcript

1. 大規模サービスをNuxt.jsで作り変えた話

2. # 自己紹介
 
 市來晟弥 （いちきせいや） @hey_icchiman
 
 ・経歴
 　・ プログラミング歴10年ぐらいの２５歳

   
 　・ Far Connection - CEO 
 　・ 元 ZEALS - CTO 
 　・ 元 3minute（現GREEグループ） - フロントエンド/アプリエンジニア 
 　・ WARC - フロントエンド 
 　・ TENTIAL - CTO 
 　・ 他にもスタートアップ数社に技術顧問として参画中 
 
 ・インフラ、サーバーからフロントまで 
 　・ Meteor.js / express.js / react / react native / vue.js(nuxt.js) 


3. # 自己紹介
 
 市來晟弥 （いちきせいや） @hey_icchiman
 
 ・経歴
 　・ プログラミング歴10年ぐらいの２５歳

   
 　・ Far Connection - CEO 
 　・ 元 ZEALS - CTO 
 　・ 元 3minute（現GREEグループ） - フロントエンド/アプリエンジニア 
 　・ WARC - フロントエンド 
 　・ TENTIAL - CTO → 今日はテンシャルでのお話
 　・ 他にもスタートアップ数社に技術顧問として参画中 
 
 ・インフラ、サーバーからフロントまで 
 　・ Meteor.js / express.js / react / react native / vue.js(nuxt.js) 


4. # 目次
 
 
 
 　　
 　　・大規模を作るに至った理由
 　　・Nuxt.js(Vue.js)を選んだ理由
 　　・Nuxt.jsにおける注意点
 　　・運用してみた感想


5. # 前提
 TENTIAL　EC

6. 大規模を作るに至った理由


7. 技術的な理由でビジネスサイドの限界を決めてしまう（開発速度の低下も然り） ↓ シリーズA以降は勢い/ガムシャラにするだけではどうにもならない ちゃんと長期的スキームに応えられる設計にしていかないといけない # 大規模を作るに至った理由
 
 
 
 ECプラットフォーム（sho◦ifyのような）からの大リニューアル


   


8. ・商品管理 ・SKU（商品サイズ,タイプ）管理 ・注文履歴 ・在庫履歴管理 ・ユーザー管理（会員ユーザー、未会員ユーザー） ・クーポン発行/使用履歴管理 ・LP管理 ・広告管理（ASP、トラッキングログ） # 大規模の定義

   > 大規模を作るに至った理由 
 
 ・記事管理、記事用監修者（一般的なニュースだけでなくEC内メ ディアも） ・診断管理 ・お問い合わせ管理 ・その他設定（税率や手数料、送料） ・管理者管理（配送担当者やCS,CXの担当者、広告運用担当者、メ ディア担当者など管理者も多いため管理体制もしっかりする） ・分析用CSV/スプレ連動(GAS組み込み) 今回は機能ベースで定義

9. ・Nuxt.js (SSR) 　　・Vue.js 　　・express.js (api server) 　　・MongoDB ・インフラ 　　・elastic beanstalk

   (docker) 　　・S3 　　・codepipeline 　　・github actions(eslint, prettier) # システム構成 > 大規模を作るに至った理由 
 


10. ・Nuxt.js (SSR) → 今日はここのお話 　　・Vue.js 　　・express.js (api server) 　　・MongoDB ・インフラ

    　　・elastic beanstalk (docker) 　　・S3 　　・codepipeline 　　・github actions(eslint, prettier) # システム構成 > 大規模を作るに至った理由 
 


11. # 目次
 
 
 
 　　
 　　・大規模を作るに至った理由
 　　・Nuxt.js(Vue.js)を選んだ理由　
 　　・Nuxt.jsにおける注意点
 　　・運用してみた感想


12. Nuxt.js(Vue)を選んだ理由
 


13. そこにNuxt(Vue)があったから # Nuxt.js(Vue.js)を選んだ理由
 
 とか言えたらかっこいいよね ...

14. # Nuxt.js(Vue.js)を選んだ理由
 
 ・SSRの最適化（これに尽きる） ・express.js と同居できる 　（これに尽きる、サーバーからフロントまで全部jsで書く組織なため、１つのプロジェクトにおいてはなるべく同居できていた方が理解が早く深ま る） ・学習コストの低さ（日本語ドキュメントも豊富） ・規約がしっかりしている（どこでなにをすればいいか明確）

    ・その割には汎用的な設計ができる ・Reactiveの万能さ 　（再描画が詰まることが少ない、$nextTickやcomputedの恩恵やreactでいうshouldComponentUpdateが不要）

15. # 目次
 
 
 
 　　
 　　・大規模を作るに至った理由
 　　・Nuxt.js(Vue.js)を選んだ理由
 　　・Nuxt.jsにおける注意点　
 　　・運用してみた感想


16. Nuxt.jsにおける注意点


17. # Nuxt.jsにおける注意点
 
 ・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM

    / optimize

18. ・メソッド/関数の設計、共通化　 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize #

    Nuxt.jsにおける注意点
 


19. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 
 
 ページが増える / 機能が増える ↓

    共通関数/コンポーネントの設計をしていく（随時） 無闇に実装に走らない

20. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 
 
 無闇に実装に走る（すぐできますって言っちゃう） ↓ 各エンジニアでオレオレ手法を用いちゃって破綻 する

21. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 
 
 破綻する ↓ バグの原因が追えなくなる, 分からなくなる

    後からの改修が厄介 （結局その機能を作り直しすることも ...）

22. ◦ メソッド/関数設計で意識したこと 　・関数型言語のフィロソフィーを利用 　・細かく各関数(値をreturnで返す)を切り分けて作り 　　１つの処理に対してフィルターのように複数の関数を通していく 　・より共通化 / 規約を作る # メソッド/関数の設計、共通化

    > Nuxt.jsにおける注意点 
 
 “このページ”の”この機能だけ”使いたい →　この関数だけ使えば使えるよ

23. ・メソッド/関数の設計、共通化 ・pages, storeの設計　 ・apiエンドポイントの設計 ・GA / GTM / optimize #

    Nuxt.jsにおける注意点
 


24. # pages, storeの設計 > Nuxt.jsにおける注意点 
 
 ◦意識したこと 各ページのSSR（asyncData）やmountedにて 必要な時に必要なデータを取得する

    ような設計 なんでもかんでも/store/index.jsや 関係が薄いページでも storeにぶち込んでview管理するな

25. # pages, storeの設計 > Nuxt.jsにおける注意点 
 
 Aというページで使った&&加工したstoreが 遷移してBというページでも使われる（引き継がれる） ただ、Bというページをリロードしたら

    store値が違う みたいなこと避けよう（データ整合の不一致） storeでゴリゴリview管理するあるある 画面遷移 Page - A Page - B

26. # pages, storeの設計 > Nuxt.jsにおける注意点 
 
 storeの設計が出来ていない / 肥大化すると

    ↓ ・どこで何をしているかわからなくなる ・確かにレンダリングが楽かもしれないが 楽=正しい設計かどうかは精査する Nuxt.jsのstore/dispatchのディレクトリ構造素晴らしい

27. # pages, storeの設計 > Nuxt.jsにおける注意点 
 
 グローバルで持ちすぎず 必要な時に必要なデータを取得しよう

28. ・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計　 ・GA / GTM / optimize #

    Nuxt.jsにおける注意点
 


29. ◦ apiのエンドポイント構造/レスポンス形式の最適化 　・サーバーサイドと各viewの理解・共通認識を深める 　・機能やDBごとでエンドポイントを設計できているか 　　　（ビジネスサイド側とも必要であればすり合わせる） 　・レスポンスやリクエストパラメータを統一 # apiエンドポイントの設計 > Nuxt.jsにおける注意点

    
 
 必然的にサーバー側の処理も統一される →　MTG × MTG　 MTG妥協すな

30. ・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize　 #

    Nuxt.jsにおける注意点
 


31. ◦ GAはSPAの性質上、バグが起きやすい 　・dl, dp, dt辺りのパラメータが遷移時に正常に送られていない 　・ログインリダイレクトなど更新される refererは除外しよう 　　　（SNSやfirebaseログイン使っている人などは特に） # GA

    / GTM / optimize > Nuxt.jsにおける注意点 
 
 pageviewは手動（コード側）で送る方が確実 ga('send', 'pageview')

32. ◦ GTM 　・GTMトリガーの「ページビュー」は遷移で検知しない 　　当たり前だがSPAは一部のDOMが更新される 　　　都度ブラウザリフレッシュを行う = ページビューの形式ではない # GA /

    GTM / optimize > Nuxt.jsにおける注意点 
 
 遷移に関しては「履歴の変更」で検知する

33. ◦ optimize 　・gtm側でgoogle optimizeを設定しようとすると 　　GA連携が必須となり必然的に初回ページビューが重複発火される # GA / GTM /

    optimize > Nuxt.jsにおける注意点 
 
 optimizeに関してもコード側で対応するのが確実

34. # pages, storeの設計 > Nuxt.jsにおける注意点 
 
 これらマーケター絶対困ってます ↓ ・タグ設置やCV計測方法などが通常の

    MPAとは設置,計測方法が違う ・ちゃんとマーケターと MTG入れて 　gtmタグやトリガーの設計を共有 /理解し合う ・SPAの理解からしてもらう必要がある

35. # 目次
 
 
 
 　　
 　　・大規模を作るに至った理由
 　　・Nuxt.js(Vue.js)を選んだ理由　
 　　・Nuxt.jsにおける注意点
 　　・運用してみた感想


36. 運用してみた感想


37. ・コードレビューが楽になった　 ・eslint(test)、Sentry入れとかないと地獄 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な風通しが良くなった # 運用してみた感想
 


38. ◦ コードレビューが楽になった 　・規約がしっかりしている組織体制にできた 　・DB設計、apiのendpoint設計から入ることで 　　どこに何がつながっているかがわかっている・わかってくる 　・実際にブランチ切り替えてデバッグせずとも 　　コードを見ただけでだいたい的確なレビューができる # 運用してみた感想
 


39. ・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄　 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
 


40. ◦ eslint(test)、Sentry入れとかないと地獄 　・規約のある中ではあるが多少は自由に書けてしまう 　　とりあえず”ローカル”で動けば大丈夫で書いてしまう 　　→　docker内でエラー多発&サーバー落ちの原因になる 　・undefinedエラーが出やすい 　・近世フロント側（js）でロジックを持つことが多いため、 　　以前よりもバグ（見えないところでも）が多発する可能性 /ケースが多い 開発者が増える前・ジョインするタイミングでコード規約もしっかり決めておく

    （今後の糧にもなるため今のうちから徹底していく） # 運用してみた感想
 


41. ・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄　 ・採用がしやすい、成長もさせやすい 　 ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
 


42. ・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄　 ・採用がしやすい、成長もさせやすい　 ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
 


43. 大規模サービスをNuxt.jsで作り変えた話 
 でした！ 以上

44. ご静聴ありがとうございました！