大規模サービスをNuxt.jsで作り変えた話

by icchiman

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

# 自己紹介    市來晟弥（いちきせいや） @hey_icchiman    ・経歴  　・プログラミング歴10年ぐらいの２５歳   　・ Far Connection - CEO   　・元 ZEALS - CTO   　・元 3minute（現GREEグループ） - フロントエンド/アプリエンジニア   　・ WARC - フロントエンド   　・ TENTIAL - CTO   　・他にもスタートアップ数社に技術顧問として参画中     ・インフラ、サーバーからフロントまで   　・ Meteor.js / express.js / react / react native / vue.js(nuxt.js)  

Slide 3

Slide 3 text

# 自己紹介    市來晟弥（いちきせいや） @hey_icchiman    ・経歴  　・プログラミング歴10年ぐらいの２５歳   　・ Far Connection - CEO   　・元 ZEALS - CTO   　・元 3minute（現GREEグループ） - フロントエンド/アプリエンジニア   　・ WARC - フロントエンド   　・ TENTIAL - CTO → 今日はテンシャルでのお話  　・他にもスタートアップ数社に技術顧問として参画中     ・インフラ、サーバーからフロントまで   　・ Meteor.js / express.js / react / react native / vue.js(nuxt.js)  

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

# 前提  TENTIAL　EC

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

・商品管理・SKU（商品サイズ,タイプ）管理・注文履歴・在庫履歴管理・ユーザー管理（会員ユーザー、未会員ユーザー）・クーポン発行/使用履歴管理・LP管理・広告管理（ASP、トラッキングログ） # 大規模の定義 > 大規模を作るに至った理由     ・記事管理、記事用監修者（一般的なニュースだけでなくEC内メディアも）・診断管理・お問い合わせ管理・その他設定（税率や手数料、送料）・管理者管理（配送担当者やCS,CXの担当者、広告運用担当者、メディア担当者など管理者も多いため管理体制もしっかりする）・分析用CSV/スプレ連動(GAS組み込み) 今回は機能ベースで定義

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Nuxt.jsにおける注意点 

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

# メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点     ページが増える / 機能が増える ↓ 共通関数/コンポーネントの設計をしていく（随時）無闇に実装に走らない

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

# メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点     破綻する ↓ バグの原因が追えなくなる, 分からなくなる後からの改修が厄介（結局その機能を作り直しすることも ...）

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

# pages, storeの設計 > Nuxt.jsにおける注意点     Aというページで使った&&加工したstoreが遷移してBというページでも使われる（引き継がれる）ただ、Bというページをリロードしたら store値が違うみたいなこと避けよう（データ整合の不一致） storeでゴリゴリview管理するあるある画面遷移 Page - A Page - B

Slide 26

Slide 26 text

# pages, storeの設計 > Nuxt.jsにおける注意点     storeの設計が出来ていない / 肥大化すると ↓ ・どこで何をしているかわからなくなる・確かにレンダリングが楽かもしれないが楽=正しい設計かどうかは精査する Nuxt.jsのstore/dispatchのディレクトリ構造素晴らしい

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

# pages, storeの設計 > Nuxt.jsにおける注意点     これらマーケター絶対困ってます ↓ ・タグ設置やCV計測方法などが通常の MPAとは設置,計測方法が違う・ちゃんとマーケターと MTG入れて　gtmタグやトリガーの設計を共有 /理解し合う・SPAの理解からしてもらう必要がある

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

運用してみた感想 

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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