Upgrade to Pro — share decks privately, control downloads, hide ads and more …

社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道

社内 TSKaigi 実施を経た Full Stack TypeScript 強化の道

2024/06/04 TSKaigi 2024 After Talk に登壇した際の資料です。
https://layerx.connpass.com/event/318123/

Niwa Takeru

June 04, 2024
Tweet

More Decks by Niwa Takeru

Other Decks in Technology

Transcript

  1. 2 自己紹介 2 主催 理事 丹羽 健 (Niwa Takeru) 取締役

    CTO Full Stack TypeScript と呼ぼう委員会 (英語圏ではこの言い方が一般的) TSKaigi After Talk にまで参加いただき 皆さん、ありがとうございます!! @niwa_takeru < フォローお願いします!
  2. 7 Full Stack TypeScript の技術選定 7 プロダクト開発開始、2021年春 (3年前) • シード期の限られたリソース

    2.5億円調達、エンジニア4名 • 物流という複雑かつディープな ドメインでマルチプロダクト開発 • 1人あたりの”プロダクト開発”の 生産性を圧倒的に高める技術選定 • Full Stack TypeScript を選択し 1エンジニアが複数領域を 越境して開発する文化を作る “プロダクト開発”の生産性を追求する ※2021年当時は Full Stack TS の知見共有はほぼ無い状況
  3. プロダクトエンジニアを支える Full Stack TS 8 8 • 1エンジニアのフルスタック化 (フロント、バック、インフラ) •

    生産性の向上と技術の平易化で どう作る?から何を作るか?へ • 技術領域の越境の発生から連鎖し デザイン、ビジネスの越境が発生 • プロダクト志向が発展し、 エンジニアがPdMの一部役割を担うエン ジニア組織へ成長 Full Stack TS の恩恵 プロダクトエンジニアへの進化
  4. Monorepo 認証サービス メインサービス(ロジックス) 共通モジュール 9 現状の Full Stack TS の構成

    9 core frontend backend core backend frontend native 参照 domain-core プリミティブな 値オブジェクト logic-helpers プリミティブな ロジック集 design-kit • 1Repository で管理し yarn workspace で参照 • モノリポ & 同一言語なので シームレスな開発体験 • core モジュールでModelや ドメインロジックを共有 • core で API の IF を定義 IF変更時にFE/BEの型が 壊れてくれる嬉しさ 良さは多くありつつも 課題はまだ存在している 構成の特徴
  5. class ベースからの脱却 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 10 現状の Full

    Stack TS の課題点 10 次世代ライブラリへの移行 技術選定した2021年当時のままとなっている フレームワークを構成するライブラリの移行 Full Stack TS の連携性の向上 APIのIF定義をcoreモジュールを通して共有できているが 1つ1つを手で書いている状態。 Full Stack TS ならではのモジュール間連携のナレッジは 世間的にも少ない状況。 よりTSを活かした関数型DDDへ DDDは取り入れているがJava時代から 変わらない class ベースな DDD の構成 TypeScriptの取り回しやすさを活かし 関数型DDDへの移行で表現力を上げ、 生産性を挙げられるのではと期待 class ベースからの脱却 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 class ベースからの脱却 ドメインロジックをまとめるために class ベースの書き 方となっており、TypeScriptで取り回しがしやすい object や primitive な型をベースとして書くことができ ていない悩ましさ Server Framework Validation Library yup
 Zod core frontend backend class type

  6. class ベースからの脱却 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 11 現状の Full

    Stack TS の課題点 11 次世代ライブラリへの移行 技術選定した2021年当時のままとなっている フレームワークを構成するライブラリの移行 Full Stack TS の連携性の向上 APIのIF定義をcoreモジュールを通して共有できているが 1つ1つを手で書いている状態。 Full Stack TS ならではのモジュール間連携のナレッジは 世間的にも少ない状況。 よりTSを活かした関数型DDDへ DDDは取り入れているがJava時代から 変わらない class ベースな DDD の構成 TypeScriptの取り回しやすさを活かし 関数型DDDへの移行で表現力を上げ、 生産性を挙げられるのではと期待 class ベースからの脱却 機能リリース後に顧客ギャップを埋めることで 初めてアウトカムが実現される。 高頻度にデプロイを実行し顧客検証を素早く繰り返す。 平均復旧時間を縮める施策をすることで仕様的な失敗に 対する安全性を高めることもできる。 class ベースからの脱却 ドメインロジックをまとめるために class ベースの書き 方となっており、TypeScriptで取り回しがしやすい object や primitive な型をベースとして書くことができ ていない悩ましさ Server Framework Validation Library yup
 Zod core frontend backend class type
 TypeScript のスペシャリストがいないので TypeScriptを活かしきれていない!! Full Stack TS のナレッジが世の中に少なすぎる TSConfJP 再来してほしい TypeScript のカンファレンスを求めるなら 自分で作ればいいじゃないか
  7. • 2024年05月 • TypeScriptのカンファレンスが必要と決心 • TSConfJPの運営者へのヒアリングを中心に開催ナレッジを収集 • 2024年10月 • TSKaigi

    運営コミュニティ発足 • 同じくTSConf再開に向けて動いていたコアメンバーと合流し、 運営スタッフを集めるキックオフMTGを実施 • 2025年01月 • TSKaigi 開催準備・スポンサーチームリーダーを担当 • スポンサーチームは各種特典の履行のため、全チームの間を駆け回る • 2025年05月 • TSKaigi 2024 開催 🎉🎉 • 計2400名以上の参加者・計49のセッション/LT 12 TSKaigi 開催に向けて動く 12 アセンドの事業PMF📈& 第1子誕生👶 & TSKaigi で爆発する 詳細ストーリーはこちらに
  8. 13 TSKaigi プラチナスポンサーにて協賛 13 • アセンドはプラチナスポンサー協賛 ◦ 初めてのスポンサー・ブース出展 ◦ 幕間動画CM、ノベルティ、チラシ

    ◦ 模索しつつ、チーム一丸となって準備。 • TSKaigi 当日、ブース運営 ◦ 「TS コンパイルチャレンジ」を企画 ◦ ブースに来てくれた皆様に感謝! しかし、ブースを運営していると 肝心のセッションが聴けない問題
  9. 14 社内 TSKaigi を実施 14 • 全員で集まり、気になる登壇資料を読む • アセンドの現状の技術構成と照らし合わせ 取り入れたい知見を共有し議論

    • 即座に改善アクションの合意を形成 • 情報の非対称性がない状態で改善を進行 • 何より改善へのモメンタムが沸いた 2024/05/15 Wed. ASCEND Office, Tokyo 社内
 社内 TSKaigi の効果 その後、Hono勉強会、zod勉強会をチームで実施。
  10. 16 Full Stack TS 強化のロードマップ 16 class からの脱却 ・Entity, 値オブジェクトが対象

    ・Branded Type の導入 zod.brand() ・関数型DDD に向けた下準備 関数型DDD への進化 ・Effect TS を利用し workflow ベースに? ・パラダイム的な難易度は高いため  場合によっては撤退も想定している Validation を Zod に変更 ・Zod は TS と相性が良く表現力も高 ・他パッケージとの連携も多い Result 型の導入 ・戻り値の表現力の向上 ・Effect TS 説が濃厚(vs fp-ts, neverthrow) API IF 定義の高度化 ・Zodios を使うかは検討中 ・package間の依存関係が悩ましい ・tRPCを使うかも悩ましい Server FW を Hono に移行 ・将来性が高いHonoを選定 ・少機能のサービスで先行運用 実行中 TypeScript のテックリードを切実に求めています。 検証中
  11. 17 TS を活かした関数型 DDD を目指して 17 • Zod.brand() による Nominal

    型を活用 ◦ classを廃止, primitiveなオブジェクトへ ◦ z.parse() が必ず求められる 値が保証された型へ • スキーマファーストな型定義 ◦ Zod のエコシステムに乗り FormやAPIのvalidationに再利用可能 Zod による Model の軽量化と表現力の向上 TypeScript のテックリードを切実に求めています。 関数型DDDへの今後の展開 • この Model をベースに、 Effect TS等での メソッドチェーンによる workflow化を予定
  12. We are hiring !!! 21 TypeScript のテックリードを切実に求めています。 CTO 丹羽 の

    𝕏 (@niwa_takeru) お気軽にフォローください。 Full Stack TypeScript ロードマップを推進する TypeScript TechLead 募集! 生産性高く Full Stack TypeScript で開発したい プロダクトエンジニア募集!