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
TypeScriptで統一したアーキテクチャ
Search
iseki
November 19, 2021
Technology
1
78
TypeScriptで統一したアーキテクチャ
https://increments.connpass.com/event/229358/
「次世代フロントエンドに向き合ったバックエンドアーキテクチャの話」での発表資料です。
iseki
November 19, 2021
Tweet
Share
More Decks by iseki
See All by iseki
TypeScriptで統一したアーキテクチャ
masayaiseki
0
1.2k
QUICの安全性解析と証明
masayaiseki
0
23
WebRTCの安全性証明をしたい
masayaiseki
0
25
Precise study on a SOA-PSA based optical signal regenerator with numerical analysis
masayaiseki
0
27
Other Decks in Technology
See All in Technology
ストレージエンジニアの仕事と、近年の計算機について / 第58回 情報科学若手の会
pfn
PRO
4
940
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
630
datadog-incident-management-intro
tetsuya28
0
110
dbtとAIエージェントを組み合わせて見えたデータ調査の新しい形
10xinc
7
1.7k
仕様駆動開発を実現する上流工程におけるAIエージェント活用
sergicalsix
10
5.2k
マルチエージェントのチームビルディング_2025-10-25
shinoyamada
0
240
次世代のメールプロトコルの斜め読み
hirachan
2
250
ラスベガスの歩き方 2025年版(re:Invent 事前勉強会)
junjikoide
0
800
2025/10/27 JJUGナイトセミナー WildFlyとQuarkusの 始め方
megascus
0
100
進化する大規模言語モデル評価: Swallowプロジェクトにおける実践と知見
chokkan
PRO
3
430
NOT A HOTEL SOFTWARE DECK (2025/11/04)
notahotel
0
660
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
2
200
Featured
See All Featured
Building Adaptive Systems
keathley
44
2.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
Music & Morning Musume
bryan
46
6.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
116
20k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Documentation Writing (for coders)
carmenintech
76
5.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
191
56k
RailsConf 2023
tenderlove
30
1.3k
Site-Speed That Sticks
csswizardry
13
940
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Raft: Consensus for Rubyists
vanstee
140
7.2k
Transcript
EventHub All Rights Reserved. TypeScriptで統一したアーキテクチャ 2021年11月19日
EventHub All Rights Reserved. 自己紹介 • 井関 正也(@iskmsy) • 株式会社EventHub
取締役CTO • 2016年2月に代表の山本と一緒に EventHubを創業 • 開発組織、技術、プロダクトをみてます Chromium、Geckoのコミッターでした。 2
EventHub All Rights Reserved. 3 All-in-One Event Management Platform EventHubはデータを一元管理・分析する事により
イベントの成果を最大化するプラットフォームです オンライン・ハイブリッド・オフラインを問わず イベントの準備・開催・管理を効率化します
EventHub All Rights Reserved. メンバーの推移と沿革 2020年からの1年間で 11名から49名 に拡大しています。 4 2016
2017 2018 2019 2020 2021 新オフィス (神田) 会社設立 オンライン版 リリース EventHub リリース 資金調達 (Salesforce) 資金調達 (Sansan) 新オフィス (馬喰横山) 2名 2名 4名 6名 11名 49名
EventHub All Rights Reserved. 今日お話すること 少人数のエンジニアからスタートしたEventHubでどういった 理由で選定した技術なのかをお話します 5
EventHub All Rights Reserved. 技術選定の判断軸 6 組織 技術 製品 市場に受け入れられる製品であり続けるために、技術と組織を変化させていく
EventHub All Rights Reserved. 製品-フェーズによって求められる要件 7 PSF(Problem Solution Fit)到達前 顧客課題の発見・解決策の模索。できるだけコードは書かずに検証できるのが理想。
PMF(Product Market Fit) 到達前 最適な顧客体験・プランの構築。将来の拡張性を考慮しつつ個人あたりの開発効率を向上さ せていく。 PMF(Product Market Fit)到達後 更なる顧客拡大のために組織も拡大していきたい。個人あたりの開発効率も維持しつつ組織 拡大させていく。 1 2 3
EventHub All Rights Reserved. 製品-フェーズによって求められる要件 8 PSF(Problem Solution Fit)到達前 顧客課題の発見・解決策の模索。できるだけコードは書かずに検証できるのが理想。
PMF(Product Market Fit) 到達前 最適な顧客体験・プランの構築。将来の拡張性を考慮しつつ個人あたりの開発効率を向上さ せていく。 PMF(Product Market Fit)到達後 更なる顧客拡大のために組織も拡大していきたい。個人あたりの開発効率も維持しつつ組織 拡大させていく。 1 2 3
EventHub All Rights Reserved. 組織-開発スタイル 9 • EventHubは、スクラムによる開発を推進しており、 フルサイクルを前提としています •
一部のスペシャリストを除いて、エンジニアは原則、 設計から開発・テスト、QA、リリース、O&M、 サポートの全ての工程に携わります Design Develop QA Deploy O&M Support Fullcycle Developer
EventHub All Rights Reserved. 技術スタック 10 フロントエンド Typescript、React、styled-component バックエンド Typescript、Node.js、NestJS、TypeORM
データベース MySQL インフラ AWS(Fargate、Elastic Beanstalk) CI CircleCI モニタリング Sentry、AWS CloudWatch
EventHub All Rights Reserved. 選定技術 11 TypeScriptでの統一 フロントエンド・バックエンドを同一リポジトリで管理 NestJSの採用 1
2 3
EventHub All Rights Reserved. TypeScriptでの統一 12 選定理由 • 言語スイッチによる認知負荷の低減できる •
フロントエンド・バックエンドでコードを共通化できる デメリット • プロダクト要件に合わせたバックエンドの選定ができない。
EventHub All Rights Reserved. Validationの統一 13 • class-validatorを利用して、フロントエンド・バックエンドにおいて処理を統一 ◦ 共通のクラスファイルを作成
◦ フロントエンドでリクエストする際にvalidationを実行 ◦ バックエンドでリクエスト内容をvalidationを実行 共通クラス NestJSでのバリデーション フロントエンドでのバリデーション
EventHub All Rights Reserved. フロントエンド・バックエンドを同一リポジトリで管理 14 選定理由 • モジュールを横断した編集がしやすい(管理がしやすい) •
環境構築やビルドなどのプロセスを統一しやすい デメリット • コードベース・組織が大きくになるにつれて影響範囲が分かりづらくなる
EventHub All Rights Reserved. NestJSの採用 15 選定理由 • 実装方法の指針がある •
TypeScript との親和性が高い デメリット • 学習コストがかかる
EventHub All Rights Reserved. 選定技術(まとめ) 16 TypeScriptでの統一 フロントエンド・バックエンドを同一リポジトリで管理 NestJSの採用 1
2 3 • 認知負荷を低減できる • コード共通化できる • モジュールを横断した編集がしやすい • 環境構築やビルドなどのプロセスを統一しやすい • 実装方法の指針がある • TypeScript との親和性
EventHub All Rights Reserved. エンジニア積極採用中です!!! 17 https://jobs.eventhub.co.jp/ • Webエンジニア •
セキュリティエンジニア • QAエンジニア • インフラエンジニア • エンジニアリングマネージャ • コーポレートエンジニア