Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模サービスをNuxt.jsで作り変えた話
Search
icchiman
May 27, 2020
Technology
0
1.6k
大規模サービスをNuxt.jsで作り変えた話
Nuxt.js, Vue.jsにおけるTENTIAL ECのお話
icchiman
May 27, 2020
Tweet
Share
More Decks by icchiman
See All by icchiman
【TENTIAL】テクノロジー本部_事業部説明
icchi
0
4.5k
Nuxt.js v2からv3へ on TENTIAL
icchi
0
1.4k
Other Decks in Technology
See All in Technology
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
生成AIを活用した野球データ分析 - メジャーリーグ編 / Baseball Analytics for Gen AI
shinyorke
PRO
1
230
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
280
マルチモーダル基盤モデルに基づく動画と音の解析技術
lycorptech_jp
PRO
2
260
Vision Language Modelと自動運転AIの最前線_20250730
yuyamaguchi
1
590
地域コミュニティへの「感謝」と「恩返し」 / 20250726jawsug-tochigi
kasacchiful
0
100
AI人生苦節10年で会得したAIがやること_人間がやること.pdf
shibuiwilliam
1
210
Kiro Hookを Terraformで検証
ao_inoue
0
140
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
160
With Devin -AIの自律とメンバーの自立
kotanin0
2
790
興味の胞子を育て 業務と技術に広がる”きのこ力”
fumiyasac0921
0
290
M365アカウント侵害時の初動対応
lhazy
7
5.1k
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
BBQ
matthewcrist
89
9.8k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
390
Done Done
chrislema
184
16k
For a Future-Friendly Web
brad_frost
179
9.8k
Bash Introduction
62gerente
613
210k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Transcript
大規模サービスをNuxt.jsで作り変えた話
# 自己紹介 市來晟弥 (いちきせいや) @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)
# 自己紹介 市來晟弥 (いちきせいや) @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)
# 目次 ・大規模を作るに至った理由 ・Nuxt.js(Vue.js)を選んだ理由 ・Nuxt.jsにおける注意点 ・運用してみた感想
# 前提 TENTIAL EC
大規模を作るに至った理由
技術的な理由でビジネスサイドの限界を決めてしまう(開発速度の低下も然り) ↓ シリーズA以降は勢い/ガムシャラにするだけではどうにもならない ちゃんと長期的スキームに応えられる設計にしていかないといけない # 大規模を作るに至った理由 ECプラットフォーム(sho◦ifyのような)からの大リニューアル
・商品管理 ・SKU(商品サイズ,タイプ)管理 ・注文履歴 ・在庫履歴管理 ・ユーザー管理(会員ユーザー、未会員ユーザー) ・クーポン発行/使用履歴管理 ・LP管理 ・広告管理(ASP、トラッキングログ) # 大規模の定義
> 大規模を作るに至った理由 ・記事管理、記事用監修者(一般的なニュースだけでなくEC内メ ディアも) ・診断管理 ・お問い合わせ管理 ・その他設定(税率や手数料、送料) ・管理者管理(配送担当者やCS,CXの担当者、広告運用担当者、メ ディア担当者など管理者も多いため管理体制もしっかりする) ・分析用CSV/スプレ連動(GAS組み込み) 今回は機能ベースで定義
・Nuxt.js (SSR) ・Vue.js ・express.js (api server) ・MongoDB ・インフラ ・elastic beanstalk
(docker) ・S3 ・codepipeline ・github actions(eslint, prettier) # システム構成 > 大規模を作るに至った理由
・Nuxt.js (SSR) → 今日はここのお話 ・Vue.js ・express.js (api server) ・MongoDB ・インフラ
・elastic beanstalk (docker) ・S3 ・codepipeline ・github actions(eslint, prettier) # システム構成 > 大規模を作るに至った理由
# 目次 ・大規模を作るに至った理由 ・Nuxt.js(Vue.js)を選んだ理由 ・Nuxt.jsにおける注意点 ・運用してみた感想
Nuxt.js(Vue)を選んだ理由
そこにNuxt(Vue)があったから # Nuxt.js(Vue.js)を選んだ理由 とか言えたらかっこいいよね ...
# Nuxt.js(Vue.js)を選んだ理由 ・SSRの最適化(これに尽きる) ・express.js と同居できる (これに尽きる、サーバーからフロントまで全部jsで書く組織なため、1つのプロジェクトにおいてはなるべく同居できていた方が理解が早く深ま る) ・学習コストの低さ(日本語ドキュメントも豊富) ・規約がしっかりしている(どこでなにをすればいいか明確)
・その割には汎用的な設計ができる ・Reactiveの万能さ (再描画が詰まることが少ない、$nextTickやcomputedの恩恵やreactでいうshouldComponentUpdateが不要)
# 目次 ・大規模を作るに至った理由 ・Nuxt.js(Vue.js)を選んだ理由 ・Nuxt.jsにおける注意点 ・運用してみた感想
Nuxt.jsにおける注意点
# Nuxt.jsにおける注意点 ・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM
/ optimize
・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize #
Nuxt.jsにおける注意点
# メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 ページが増える / 機能が増える ↓
共通関数/コンポーネントの設計をしていく(随時) 無闇に実装に走らない
# メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 無闇に実装に走る(すぐできますって言っちゃう) ↓ 各エンジニアでオレオレ手法を用いちゃって破綻 する
# メソッド/関数の設計、共通化 > Nuxt.jsにおける注意点 破綻する ↓ バグの原因が追えなくなる, 分からなくなる
後からの改修が厄介 (結局その機能を作り直しすることも ...)
◦ メソッド/関数設計で意識したこと ・関数型言語のフィロソフィーを利用 ・細かく各関数(値をreturnで返す)を切り分けて作り 1つの処理に対してフィルターのように複数の関数を通していく ・より共通化 / 規約を作る # メソッド/関数の設計、共通化
> Nuxt.jsにおける注意点 “このページ”の”この機能だけ”使いたい → この関数だけ使えば使えるよ
・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize #
Nuxt.jsにおける注意点
# pages, storeの設計 > Nuxt.jsにおける注意点 ◦意識したこと 各ページのSSR(asyncData)やmountedにて 必要な時に必要なデータを取得する
ような設計 なんでもかんでも/store/index.jsや 関係が薄いページでも storeにぶち込んでview管理するな
# pages, storeの設計 > Nuxt.jsにおける注意点 Aというページで使った&&加工したstoreが 遷移してBというページでも使われる(引き継がれる) ただ、Bというページをリロードしたら
store値が違う みたいなこと避けよう(データ整合の不一致) storeでゴリゴリview管理するあるある 画面遷移 Page - A Page - B
# pages, storeの設計 > Nuxt.jsにおける注意点 storeの設計が出来ていない / 肥大化すると
↓ ・どこで何をしているかわからなくなる ・確かにレンダリングが楽かもしれないが 楽=正しい設計かどうかは精査する Nuxt.jsのstore/dispatchのディレクトリ構造素晴らしい
# pages, storeの設計 > Nuxt.jsにおける注意点 グローバルで持ちすぎず 必要な時に必要なデータを取得しよう
・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize #
Nuxt.jsにおける注意点
◦ apiのエンドポイント構造/レスポンス形式の最適化 ・サーバーサイドと各viewの理解・共通認識を深める ・機能やDBごとでエンドポイントを設計できているか (ビジネスサイド側とも必要であればすり合わせる) ・レスポンスやリクエストパラメータを統一 # apiエンドポイントの設計 > Nuxt.jsにおける注意点
必然的にサーバー側の処理も統一される → MTG × MTG MTG妥協すな
・メソッド/関数の設計、共通化 ・pages, storeの設計 ・apiエンドポイントの設計 ・GA / GTM / optimize #
Nuxt.jsにおける注意点
◦ GAはSPAの性質上、バグが起きやすい ・dl, dp, dt辺りのパラメータが遷移時に正常に送られていない ・ログインリダイレクトなど更新される refererは除外しよう (SNSやfirebaseログイン使っている人などは特に) # GA
/ GTM / optimize > Nuxt.jsにおける注意点 pageviewは手動(コード側)で送る方が確実 ga('send', 'pageview')
◦ GTM ・GTMトリガーの「ページビュー」は遷移で検知しない 当たり前だがSPAは一部のDOMが更新される 都度ブラウザリフレッシュを行う = ページビューの形式ではない # GA /
GTM / optimize > Nuxt.jsにおける注意点 遷移に関しては「履歴の変更」で検知する
◦ optimize ・gtm側でgoogle optimizeを設定しようとすると GA連携が必須となり必然的に初回ページビューが重複発火される # GA / GTM /
optimize > Nuxt.jsにおける注意点 optimizeに関してもコード側で対応するのが確実
# pages, storeの設計 > Nuxt.jsにおける注意点 これらマーケター絶対困ってます ↓ ・タグ設置やCV計測方法などが通常の
MPAとは設置,計測方法が違う ・ちゃんとマーケターと MTG入れて gtmタグやトリガーの設計を共有 /理解し合う ・SPAの理解からしてもらう必要がある
# 目次 ・大規模を作るに至った理由 ・Nuxt.js(Vue.js)を選んだ理由 ・Nuxt.jsにおける注意点 ・運用してみた感想
運用してみた感想
・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な風通しが良くなった # 運用してみた感想
◦ コードレビューが楽になった ・規約がしっかりしている組織体制にできた ・DB設計、apiのendpoint設計から入ることで どこに何がつながっているかがわかっている・わかってくる ・実際にブランチ切り替えてデバッグせずとも コードを見ただけでだいたい的確なレビューができる # 運用してみた感想
・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
◦ eslint(test)、Sentry入れとかないと地獄 ・規約のある中ではあるが多少は自由に書けてしまう とりあえず”ローカル”で動けば大丈夫で書いてしまう → docker内でエラー多発&サーバー落ちの原因になる ・undefinedエラーが出やすい ・近世フロント側(js)でロジックを持つことが多いため、 以前よりもバグ(見えないところでも)が多発する可能性 /ケースが多い 開発者が増える前・ジョインするタイミングでコード規約もしっかり決めておく
(今後の糧にもなるため今のうちから徹底していく) # 運用してみた感想
・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
・コードレビューが楽になった ・eslint(test)、Sentry入れとかないと地獄 ・採用がしやすい、成長もさせやすい ・各MTGを出来るだけ入れることで社内の技術的な理解 /風通しが良くなった # 運用してみた感想
大規模サービスをNuxt.jsで作り変えた話 でした! 以上
ご静聴ありがとうございました!