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.3k
大規模サービスを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
3.5k
Nuxt.js v2からv3へ on TENTIAL
icchi
0
1.1k
Other Decks in Technology
See All in Technology
AWS を使う上で知っておきたいオンプレミス知識/aws-on-premise-essentials
emiki
1
4.2k
自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 / Centralized management of Error/Alert/Runbook to minimize operational costs using automated code generation
biwashi
9
2.1k
疲弊しない!AWSセキュリティ統制の考え方 #devio_osakaday1
masahirokawahara
6
5.9k
Databricks におけるデータエンジニアリング
databricksjapan
0
380
Tebiki株式会社 エンジニア採用資料
tebiki
0
4.1k
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.4k
Postman v10リリース後を振り返る
nagix
0
130
20240416_devopsdaystokyo
kzkmaeda
1
190
複雑な構成要素を持つUIとの向き合い方 〜新・支出グラフでの実例〜 / B43 TECH TALK
nakamuuu
0
100
開発生産性向上サービスを作るFindyが自分たちで開発生産性を爆上げした組織づくりの歩み / Findy's path to boosting its own development productivity 2024-04-17
ma3tk
3
340
オブザーバビリティの Primary Signals
onk
PRO
0
550
なぜ NOT A HOTEL が Web3 に取り組むのか - NOT A HOTEL TECH TALK
ynunokawa
0
160
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
13
1.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
154
14k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Learning to Love Humans: Emotional Interface Design
aarron
266
39k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
The Mythical Team-Month
searls
215
42k
Design by the Numbers
sachag
274
18k
The Cult of Friendly URLs
andyhume
74
5.7k
How to name files
jennybc
64
92k
The Brand Is Dead. Long Live the Brand.
mthomps
48
28k
Designing Experiences People Love
moore
136
23k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
16k
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で作り変えた話 でした! 以上
ご静聴ありがとうございました!