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.4k
大規模サービスを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.9k
Nuxt.js v2からv3へ on TENTIAL
icchi
0
1.2k
Other Decks in Technology
See All in Technology
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
ゆめみのアクセシビリティの現在地と今後
ryokatsuse
3
290
CTOから見た事業開発とプロダクト開発 / My Perspective on Business and Product Development as CTO
keisuke69
4
960
Matterport を使ってクラスメソッド各拠点のバーチャルオフィスツアーを作成してみた
wakatsuki
0
160
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
620
AIエージェントを現場に導入する目線とは
masahiro_nishimi
1
1.5k
LLMアプリケーションの評価の実践と課題 ~PharmaXにおける今後の展望~
pharma_x_tech
2
160
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
120
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
20240724_cm_odyssey_hibiyatech
hiashisan
0
110
エンジニアリングマネージャーはどう学んでいくのか #devsumi / How Do Engineering Managers Continue to Learn and Grow?
expajp
4
1.3k
Featured
See All Featured
A Tale of Four Properties
chriscoyier
155
22k
The MySQL Ecosystem @ GitHub 2015
samlambert
248
12k
How STYLIGHT went responsive
nonsquared
93
5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
17
1.5k
Optimizing for Happiness
mojombo
373
69k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Building Applications with DynamoDB
mza
89
5.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Designing for Performance
lara
604
67k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
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で作り変えた話 でした! 以上
ご静聴ありがとうございました!