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
4.1k
大規模サービスをNuxt.jsで作り変えた話
icchi
0
1.5k
Featured
See All Featured
Faster Mobile Websites
deanohume
304
30k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
Designing for humans not robots
tammielis
249
25k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Why Our Code Smells
bkeepers
PRO
334
57k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
How STYLIGHT went responsive
nonsquared
95
5.1k
For a Future-Friendly Web
brad_frost
174
9.4k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
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へ でした! 以上
ご静聴ありがとうございました!