Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Nuxt.js, Vue.jsにおけるTENTIAL ECのお話

icchiman

May 27, 2020
Tweet

More Decks by icchiman

Other Decks in Technology

Transcript

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

    View full-size slide

  2. # 自己紹介


    市來晟弥 (いちきせいや) @hey_icchiman


    ・経歴

     ・ プログラミング歴10年ぐらいの25歳 

     ・ Far Connection - CEO 

     ・ 元 ZEALS - CTO 

     ・ 元 3minute(現GREEグループ) - フロントエンド/アプリエンジニア 

     ・ WARC - フロントエンド 

     ・ TENTIAL - CTO 

     ・ 他にもスタートアップ数社に技術顧問として参画中 


    ・インフラ、サーバーからフロントまで 

     ・ Meteor.js / express.js / react / react native / vue.js(nuxt.js) 


    View full-size slide

  3. # 自己紹介


    市來晟弥 (いちきせいや) @hey_icchiman


    ・経歴

     ・ プログラミング歴10年ぐらいの25歳 

     ・ Far Connection - CEO 

     ・ 元 ZEALS - CTO 

     ・ 元 3minute(現GREEグループ) - フロントエンド/アプリエンジニア 

     ・ WARC - フロントエンド 

     ・ TENTIAL - CTO → 今日はテンシャルでのお話

     ・ 他にもスタートアップ数社に技術顧問として参画中 


    ・インフラ、サーバーからフロントまで 

     ・ Meteor.js / express.js / react / react native / vue.js(nuxt.js) 


    View full-size slide

  4. # 目次




      

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

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

      ・Nuxt.jsにおける注意点

      ・運用してみた感想


    View full-size slide

  5. # 前提

    TENTIAL EC

    View full-size slide

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


    View full-size slide

  7. 技術的な理由でビジネスサイドの限界を決めてしまう(開発速度の低下も然り)

    シリーズA以降は勢い/ガムシャラにするだけではどうにもならない
    ちゃんと長期的スキームに応えられる設計にしていかないといけない
    # 大規模を作るに至った理由




    ECプラットフォーム(sho○ifyのような)からの大リニューアル


    View full-size slide

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


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

    View full-size slide

  9. ・Nuxt.js (SSR)
      ・Vue.js
      ・express.js (api server)
      ・MongoDB
    ・インフラ
      ・elastic beanstalk (docker)
      ・S3
      ・codepipeline
      ・github actions(eslint, prettier)
    # システム構成 > 大規模を作るに至った理由


    View full-size slide

  10. ・Nuxt.js (SSR) → 今日はここのお話
      ・Vue.js
      ・express.js (api server)
      ・MongoDB
    ・インフラ
      ・elastic beanstalk (docker)
      ・S3
      ・codepipeline
      ・github actions(eslint, prettier)
    # システム構成 > 大規模を作るに至った理由


    View full-size slide

  11. # 目次




      

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

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

      ・Nuxt.jsにおける注意点

      ・運用してみた感想


    View full-size slide

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


    View full-size slide

  13. そこにNuxt(Vue)があったから
    # Nuxt.js(Vue.js)を選んだ理由


    とか言えたらかっこいいよね ...

    View full-size slide

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


    ・SSRの最適化(これに尽きる)
    ・express.js と同居できる
     (これに尽きる、サーバーからフロントまで全部jsで書く組織なため、1つのプロジェクトにおいてはなるべく同居できていた方が理解が早く深ま
    る)
    ・学習コストの低さ(日本語ドキュメントも豊富)
    ・規約がしっかりしている(どこでなにをすればいいか明確)
    ・その割には汎用的な設計ができる
    ・Reactiveの万能さ
     (再描画が詰まることが少ない、$nextTickやcomputedの恩恵やreactでいうshouldComponentUpdateが不要)

    View full-size slide

  15. # 目次




      

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

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

      ・Nuxt.jsにおける注意点 

      ・運用してみた感想


    View full-size slide

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


    View full-size slide

  17. # Nuxt.jsにおける注意点


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

    View full-size slide

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


    View full-size slide

  19. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点


    ページが増える / 機能が増える

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

    View full-size slide

  20. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点


    無闇に実装に走る(すぐできますって言っちゃう)

    各エンジニアでオレオレ手法を用いちゃって破綻
    する

    View full-size slide

  21. # メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点


    破綻する

    バグの原因が追えなくなる, 分からなくなる
    後からの改修が厄介
    (結局その機能を作り直しすることも ...)

    View full-size slide

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


    “このページ”の”この機能だけ”使いたい
    → この関数だけ使えば使えるよ

    View full-size slide

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


    View full-size slide

  24. # pages, storeの設計 > Nuxt.jsにおける注意点


    ○意識したこと
    各ページのSSR(asyncData)やmountedにて
    必要な時に必要なデータを取得する
    ような設計
    なんでもかんでも/store/index.jsや
    関係が薄いページでも storeにぶち込んでview管理するな

    View full-size slide

  25. # pages, storeの設計 > Nuxt.jsにおける注意点


    Aというページで使った&&加工したstoreが
    遷移してBというページでも使われる(引き継がれる)
    ただ、Bというページをリロードしたら
    store値が違う
    みたいなこと避けよう(データ整合の不一致)
    storeでゴリゴリview管理するあるある
    画面遷移
    Page - A Page - B

    View full-size slide

  26. # pages, storeの設計 > Nuxt.jsにおける注意点


    storeの設計が出来ていない / 肥大化すると

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

    View full-size slide

  27. # pages, storeの設計 > Nuxt.jsにおける注意点


    グローバルで持ちすぎず
    必要な時に必要なデータを取得しよう

    View full-size slide

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


    View full-size slide

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


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

    View full-size slide

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


    View full-size slide

  31. ○ GAはSPAの性質上、バグが起きやすい
     ・dl, dp, dt辺りのパラメータが遷移時に正常に送られていない
     ・ログインリダイレクトなど更新される
    refererは除外しよう
       (SNSやfirebaseログイン使っている人などは特に)
    # GA / GTM / optimize > Nuxt.jsにおける注意点


    pageviewは手動(コード側)で送る方が確実
    ga('send', 'pageview')

    View full-size slide

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


    遷移に関しては「履歴の変更」で検知する

    View full-size slide

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


    optimizeに関してもコード側で対応するのが確実

    View full-size slide

  34. # pages, storeの設計 > Nuxt.jsにおける注意点


    これらマーケター絶対困ってます

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

    View full-size slide

  35. # 目次




      

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

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

      ・Nuxt.jsにおける注意点

      ・運用してみた感想


    View full-size slide

  36. 運用してみた感想


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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


    View full-size slide

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

    でした!
    以上

    View full-size slide

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


    View full-size slide