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 v2からv3へ on TENTIAL
Search
icchiman
October 20, 2021
0
1.2k
Nuxt.js v2からv3へ on TENTIAL
株式会社TENTIALのNuxt.js v2からv3への移行話
icchiman
October 20, 2021
Tweet
Share
More Decks by icchiman
See All by icchiman
【TENTIAL】テクノロジー本部_事業部説明
icchi
0
3.9k
大規模サービスをNuxt.jsで作り変えた話
icchi
0
1.4k
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
90
47k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
KATA
mclloyd
20
13k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
The Cost Of JavaScript in 2023
addyosmani
31
4.7k
Principles of Awesome APIs and How to Build Them.
keavy
124
16k
Automating Front-end Workflow
addyosmani
1362
200k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.5k
Web Components: a chance to create the future
zenorocha
307
41k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
A better future with KSS
kneath
231
17k
GitHub's CSS Performance
jonrohan
1026
450k
Transcript
Nuxt.js v2からv3へ on TENTIAL
# 自己紹介 市來晟弥 (いちきせいや) @hey_icchiman ・経歴 ・ 27歳(プログラミング歴12年ぐらい)
・ Far Connection - CEO ・ 元 ZEALS - CTO ・ 元 3minute(現GREEグループ) - フロントエンド/アプリエンジニアリード ・ WARC - フロントテックリード ・ TENTIAL - CTO2年目 ・インフラ、サーバーからフロントまで ・ vue(nuxt.js) / express.js / meteor.js / react / react native
# 目次 ・TENTIALの技術スペック ・なんでv3, composition apiへ移行しているのか ・実際の移行作業
・composition api の感想 ・2年間Nuxt.jsを運用してみた反省
# TENTIALの技術スペック Rails Nuxt (SSG -> SSR) Nuxt (SSR) Nuxt
(CSR -> SSR) ・Vue.js(all composition api) ・express.js (api server) ・Firestore ・all Typescript ・Vue.js ・express.js (api server) ・MongoDB ・JS -> TS移行中 ・composition api移行中 ・Vue.js ・express.js (api server) ・contentful(CMS) メディア事業 D2C事業 モール事業(新規事業) コーポレートサイト
新たにSCM(物流)システムを 自社で作ることに
# TENTIALの技術スペック Rails Nuxt2 (SSG -> SSR) Nuxt2 (SSR) Nuxt2
(CSR -> SSR) ・Vue.js(composition api) ・express.js (api server) ・Firestore ・all Typescript ・Vue.js ・express.js (api server) ・MongoDB ・JS -> TS移行中 ・composition api移行中 ・Vue.js ・express.js (api server) ・contentful(CMS) メディア事業 D2C事業 モール事業(新規事業) コーポレートサイト 物流システム(新規事業) ・apollo, graphql ・MongoDB ・TS Nuxt3 (SSR) 13名のエンジニアでこれらを支えている
# なんでv3, composition apiへ移行しているのか
# なんで移行しているのか Nuxt (CSR -> SSR) ・Vue.js(composition api) ・express.js (api
server) ・Firestore ・all Typescript composition api + TypeScript 快適過ぎる... モール事業(新規事業)
# なぜ快適なのか ・composition api → ロジックの抽出と再利用(特にvueメソッド) コンポーネント毎(一部の処理)でのロジックを再利用を可能。
あらゆる関数で共通化。 ・TypeScript → 静的型付け・型チェック。補完性。不要なエラーを削減。 ・Firestore → 単純なクエリ
# なんで移行しているのか Nuxt (CSR -> SSR) ・Vue.js(composition api) ・express.js (api
server) ・Firestore ・all Typescript composition api + TypeScript 快適過ぎる... モール事業(新規事業) 甘い蜜を知ってしまった僕たち
全サービス移行じゃぁ!!
# 今日の比較・移行対象のサービス Nuxt2 (SSR) Nuxt2 (SSR) ・Vue.js(composition api) ・express.js (api
server) ・Firestore ・all Typescript ・Vue.js(composition api) ・express.js (api server) ・Mongoose(MongoDB) ・JS -> TS移行中 (一部リリース済み) ・composition api移行中 (一部リリース済み) D2C事業 モール事業(新規事業) つらみ 快適
# D2CブランドTENTIAL 移行するぞ!!! Nuxt2 (SSR) ・Vue.js(composition api) ・express.js (api
server) ・Mongoose(MongoDB) ・JS -> TS移行中 (一部リリース済み) ・composition api移行中 (一部リリース済み) D2C事業
# D2CブランドTENTIAL 機能 ・カート ・決済(定期決済も) ・商品管理 ・SKU(商品サイズ,タイプ等)管理 ・注文履歴 ・ユーザー管理(会員ユーザー、未会員ユーザー)
・クーポン発行/使用履歴管理 ・LP管理 ・メーリングリスト ・広告管理(ASP、トラッキングログ) ・記事管理、記事用監修者(一般的なニュースだけでなくEC内メディア も) ・診断管理 ・お問い合わせ管理 ・その他設定(税率や手数料、送料) ・管理者管理(配送担当者やCS,CXの担当者、広告運用担当者、メディア 担当者など管理者も多いため管理体制もしっかりする) ・分析ページ Nuxt2 (SSR) ・Vue.js(composition api) ・express.js (api server) ・Mongoose(MongoDB) ・JS -> TS移行中 (一部リリース済み) ・composition api移行中 (一部リリース済み) D2C事業
# D2CブランドTENTIAL ファイルが多すぎる!!! 共通化されてない処理も多すぎる!!!
# D2CブランドTENTIAL だが、やらねばならぬ
# D2CブランドTENTIAL
# 実際の移行作業 js関数を管理するディレクトリを整理 → 共通化する処理や関数のイメージを 共通認識
(1番重いページをベースに議論できると尚良)
vue3で新しく入る ref, reactive等の命名も整理 # 実際の移行作業
this(Vueインスタンス) が使えなくなる問題!? → thisを多用している関数から composition api化を進める
(一旦は setup関数の引数contextで使えるが 根本的=共通化の解決にならない) # 実際の移行作業
# 実際の移行作業 SSRは要注意!! → refではなく ssrRef, shallowSsrRefを使う
(Nuxt特有。vue3で検索してきたコードをコピペする時注意)
refとreactiveや、 ssrRef, shallowSsrRefの使い分けも整理 → refはプリミティブ(1つの値に対して)使うstate (DBベースや共通関数化で使われている値になるケースが多い)
reactiveはobjectやcomponent単位で持つstate → 基本的にshallowSsrRefを使う (ssrRefが必要なケースはあまりない) # 実際の移行作業
・関数をかなり共通化できる ・設計や命名などかなりリファクタでき、 エンジニアメンバー間で共通認識を持つと共に 改修スピードのアップやバグ比率を削減 ・composition
api + SSRは注意すべき (中々、大規模サービスで行なっている先駆者がいないイメージでNuxt3に移行する時の一番心配な点) ・コアなサービスでは絶対に行うべき (一定のコストはかかるため放置してたりあまりメンテする必要のないサービスでは無理にしなくて良いかと) # composition api の感想
・component: true (nuxt.config.ts) にすべき(ダイレクトインポート) (falseで都度コンポーネントを自由にimportできてしまうとcomponentsフォルダの設計がぐちゃぐちゃに) # 2年間Nuxt.jsを運用してみた反省
# 2年間Nuxt.jsを運用してみた反省 ・component: true (nuxt.config.ts) にすべき (ダイレクトインポート) (falseで都度コンポーネントを自由にimportできてしまうとcomponentsフォルダの設計がぐちゃぐちゃに)
・設計や命名、共通関数化を全員が徹底すべき (3,4名以上から破綻) ・ファイルが多い場合はTS化の前に composition apiのみだけでも進めて 先に関数を共通化するのもアリかも (その後にts化。tsとcomposition apiは目的が違うため別に同時に進めなくても良い) ・複雑なクエリや処理になることはv3前は特に避けるべき (移行が大変) (弊社では売上分析など大量のDBをmongoose+expressで捌いてd3を使っていたりした →BQ(バッチ処理整形)+データスタジオに移行。などSaaSも積極的に検討する)
だから新規事業は、この構成にした
・コンポーネント設計の最適化(component: true) ・超共通関数化(Nuxt3, composition api) ・静的型付け(TypeScript) ・複雑なクエリを無くす(apollo, graphql)
# 日々アップデートする僕たち 物流システム(新規事業) ・apollo, graphql ・MongoDB ・TS Nuxt3 (SSR)
絶賛採用中 TS書きたい人募集
Nuxt.js v2からv3へ でした! 以上
ご静聴ありがとうございました!