Slide 1

Slide 1 text

期待しすぎずに取り組む 両面 TypeScript 株式会社一休 所澤 友大

Slide 2

Slide 2 text

2 両面 TypeScript って実際どうなの? 良いんだけど... 開発言語を統一するだけで フルスタックな開発ができるわけではない。

Slide 3

Slide 3 text

3 両面 TypeScript って実際どうなの? 1. 宿に特化した写真共有SNS 2. 飲食店の業務支援SaaS この二つのアプリケーション開発を振り返って、言語統一の利点や限界についてお話します。 私は直近2 年の間にふたつの両面 TypeScript なアプリケーションを開発してきました。

Slide 4

Slide 4 text

4 そもそもサーバーサイドを TypeScript で開発するのってどうなの? TypeScript はサーバー開発にも適した良い言語 1. モダンな言語機能 2. 静的型付け、柔軟で強力な型システム 3. 成熟したエコシステム ヒト・モノ・カネがふんだんに投入されている (特にWeb 開発の視点だと)Prisma や GraphQL 関連のライブラリの充実

Slide 5

Slide 5 text

宿に特化した写真共有SNS 『YADOLINK 』 5 新規事業(2022 年4 月 ~ 2023 年3 月) 少人数で開発 エンジニア2 名で5 ヶ月 10 人月くらいかけて初期開発 Next.js にべったり Next.js の Pages Router API Routes + Apollo Server + GraphQL Nexus シンプルなアプリケーション 基本的にはCRUD GraphQL の resolver 内にロジックをベタ書き

Slide 6

Slide 6 text

6 言語統一の恩恵を受けられた? YES ! フロントとサーバーのスイッチングコスト軽減 ビルドの設定、lint 、CI ・CD の設定、インフラなどの設定が一度で済んで楽 フルスタックな開発が実現できた 一人のエンジニアが一つの機能をまるっと担当できるため余計な調整コストが発生しない なだらかな学習曲線 もう一人エンジニアはサーバーサイド開発がほぼ未経験だったが途中から開発できるように

Slide 7

Slide 7 text

7 飲食店の業務支援SaaS 新規事業(2022 年 ~ 現在β ) 大規模なアプリケーション エンジニア8 名 100 人月ほどかけて開発 Turborepo を使った monorepo Next.js の Pages Router Fastify + Apollo Server + Pothos GraphQL 複雑なドメインロジックがある業務アプリ CQRS Query は resolver 内にロジックをベタ書き Mutation は関数型言語のエッセンスを取り入れたアーキテクチャ

Slide 8

Slide 8 text

8 言語統一の恩恵を受けられた? NO... 基本的にフロント・サーバーで分業体制 一部のフロントエンド・エンジニアが Query を触ることはある フロントエンド・エンジニアが Mutation に変更を入れることは結構難しい フロント・サーバー間で共有しているパッケージはそこまで多くない

Slide 9

Slide 9 text

9 パッケージ一覧 ドメインロジックの共有はしない! . ├── date-time ├── eslint-config-custom ├── feature-flag-setting ├── jest-config ├── reszaiko-ui ├── ts-utils └── tsconfig ちょっとした日付操作や Utility Types を共有している程度

Slide 10

Slide 10 text

10 何が言語統一の恩恵の寡多を決定するのか? 答え: 言語以外の複雑さ

Slide 11

Slide 11 text

11 アプリケーションの複雑さとは… 言語の複雑さ 例: Haskell 難しい! フレームワークやミドルウェアの複雑さ 例: React の宣言的UI 、GraphQL アーキテクチャの複雑さ 例: DDD 、関数型のパラダイム ドメインの複雑さ 例: 在庫のモデリング

Slide 12

Slide 12 text

12 シンプルなアプリケーションを作っています! そんなときは 言語統一が効く 例えば、新規サービスのMVP や小さくてシンプルなアプリケーション 極限まで複雑さを抑えるなら… Next.js の Server Component / Server Actions からDB 叩く選択肢もある

Slide 13

Slide 13 text

13 複雑なアプリケーションを作っています! そんなときは 言語統一にこだわりすぎない方がいいかも 言語を統一だけではフロント・サーバー間のスイッチング・コストを下げられない スイッチング・コストを下げたいなら シンプルなアーキテクチャの採用など言語以外の複雑さ軽減の取り組む必要がある フロントとサーバーで型を共有したいなら… GraphQL などほかの選択肢もある TypeScript 以外の選択肢を捨てるのはもったいない! もしSaaS を作り直すなら… Rust を検討します 速度、型システム、関数型パラダイムのサポートが⭕️

Slide 14

Slide 14 text

14 まとめ TypeScript はサーバーの実装にも向いた良い言語! 開発言語を統一すると言語をスイッチするコストを削減できる ただし… 言語統一だけでフロントとサーバーの壁を取り払えるわけではない

Slide 15

Slide 15 text

15 エンジニア募集中! 一休ではよりよいサービスを届ける仲間を募集しています。