Nuxt.js v2からv3へ on TENTIAL


# 自己紹介
 
 市來晟弥 （いちきせいや） @hey_icchiman
 
 ・経歴
 　・ ２7歳（プログラミング歴12年ぐらい） 
 　・ Far Connection - CEO 
 　・ 元 ZEALS - CTO 
 　・ 元 3minute（現GREEグループ） - フロントエンド/アプリエンジニアリード 
 　・ WARC - フロントテックリード 
 　・ TENTIAL - CTO２年目 
 
 ・インフラ、サーバーからフロントまで 
 　・ vue(nuxt.js) / express.js / meteor.js / react / react native 


# 目次
 
 
 　
 　　・TENTIALの技術スペック
 　　・なんでv3, composition apiへ移行しているのか
 　　・実際の移行作業
 　　・composition api の感想
 　　・２年間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関数を管理するディレクトリを整理
 
 
 → 共通化する処理や関数のイメージを
 共通認識
 
 　 (１番重いページをベースに議論できると尚良) 


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フォルダの設計がぐちゃぐちゃに） 
 # ２年間Nuxt.jsを運用してみた反省


# ２年間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へ
 でした！
 以上


ご静聴ありがとうございました！