こんにちは！株式会社Gemcookのバックエンドエンジニアのshunです。
今回は2024年11月16日(土)に参加したTSKaigi Kansai 2024のレポートです。
TSKaigi Kansai 2024とは
TSKaigi Kansai 2024とは、2024年5月に東京で開催した国内最大規模のTypeScriptのカンファレンスTSKaigi 2024の開催を受け、開催された初の地域型イベントです。
「東京以外の地域も盛り上げよう！」ということで6月ごろから準備し始め、最終的にチケットは200枚完売したとのことです！
会場: 京都市勧業館 みやこめっせ
参加したきっかけ
TypeScriptは会社的にも個人的にもHotな技術なため、勉強会も活用しより幅広くキャッチアップしていきたいと思ったのがきっかけです。また、なんと今回は弊社のバックエンドチームリーダーのsosoさんが司会の一人として参加しました😳！オフライン参加か迷っていましたが、「これは現地に行ってこっそり応援するしかない！」と思い参会してきました！
遠目ですが司会するバックエンドチームリーダーの様子です。
司会をするsosoさん
会場の雰囲気
QRコードで入場したら早速可愛いノベルティを受け取りました！会場のJobボードにはスポンサー企業からの書き込みも多くあり、会場の熱量を感じました🔥
また、ランチのお弁当は「唐揚げ弁当」と「牛肉弁当」の2つから選ぶことができました！(食べることに夢中で写真を撮り忘れてしまいました。。🍱)
ノベルティと会場の様子
イベントスタッフやコミニュティの方々のおかげでセッションやLTに集中することができました。さまざまな準備をしてくださり、ありがとうございました！
前置き
どのセッションも本当に良かったです！！新しい気づきをもらえるだけでなく、モチベーションアップにも繋がり、改めて参加できて良かったと感じました。会場が2つ(トグルルームとカミナシ堂)に分かれており、今回は私がいたトグルルームでのセッションやLTを中心に掲載していきます。
※アーカイブが見れるようになったので現地で見れなかったセッションやLTも順次みていきます！
印象に残ったセッション
型チェック 速度改善 奮闘記⏳
by Kenta TSUNEMI さん
サービスが成長しコード量が増えるにつれ、型チェックの速度が開発効率に影響してきたので、ボトルネックの調査と改善方法のお話でした。
-
Monorepoで管理
-
サービス拡大に伴うモジュールの増加
-
型チェックでVsCodeが重くなり、開発効率が落ちる
-
ボトルネックはRedux ToolkiのinitialStateの型推論
-
調査方法
- 大きく以下2パターンで調査
- tscコマンドで出力されるtrace.jsonを調査
- 解析は以下ツールがおすすめ
- VsCodeの拡張機能
- tscコマンドで出力されるtrace.jsonを調査
- 大きく以下2パターンで調査
-
対応
- initialStateの型を型定義
- 毎回型推論せず、型のキャッシュをした
- https://github.com/microsoft/TypeScript/wiki/Performance#naming-complex-types
-
結果
- 平均38%の速度改善 (詳細はスライド参照)
型チェックの速度の課題はサービスの拡大と相関して影響が大きくなると思います。こういう課題って徐々に積もり積もって気づいた時には結構膨らんでいるケースもあり、中々気づきにくいですよね。どのプロジェクトでも起こり得る課題なので日々の開発でもこの辺りは少しアンテナを張ってこれまで以上になるべく早く違和感に気づけるようにしておきたいです📡
型つき APIリクエストを実現するいくつかの手法とその選択
by ユーン さん
API連携時の型の共有方法をドキュメントやテストでカバーすると仕様と実装が乖離するので、コードファーストな共有方法へすることの有用性に関するお話でした。
-
メリット
- 仕様と実装が紐付く
- 型で表現できる文脈はテストケースを省略しやすい
-
TypeScriptファーストな手法 (Monorepo)
- ライブラリを使用せず型定義を共有
- Zodなどのライブラリを活用
- フレームワークの機能を利用
- いずれもTypeScriptに依存するため将来的な技術選定のネックになる可能性あり
-
言語に依存しない手法
- OpenAPIを活用
- サーバーコードからOpenAPIを自動生成
- OpenAPIからクライアントコードを自動生成
- メリット
- 言語に依存しない
- エコシステムが充実
- 既存の実装を維持しやすい
- 仕様と実装が揃う
- 常に最新
- デメリット
- OpenAPIを変更するには実装を変更しないといけない
- OpenAPIを活用
OpenAPIの活用はやはり仕様と実装が揃うのはメリットが大きいと思った反面、個人的な感想ですが「開発チームの技術や開発スタイルの方針」や「将来的にサービスをどれくらいスケールする想定か」によるところも大きいと感じました。
| TypeScriptファーストな手法 | 言語に依存しない手法 | |
|---|---|---|
| 学習コスト | 低い | OpenAPIの知識も必要で少し高め |
| スケールのしやすさ | clientはTypeSciptである必要がある | 言語に依存しないので柔軟にclientを増やしやいすい |
この辺りは技術選定の話にも通づるので非常に悩ましいですね。弊社でも採用しているHonoもOpenAPIの自動生成できるので、色々実験の余地がありそうです🔥
TypeScript、上達の瞬間
by sadnessOjisan さん
TypeScriptを学習するコツについてのお話でした。上達したきっかけの一つに「MinCaml」という教育用のコンパイラで、型推論を自分で実装し原理を学ぶことを通して型の必要性や意味を理解できたとのことでした。
- そのそもTypeScript自体に体系的な学び方はない..?
- 他の言語同様、機能は都度継ぎ足されて進化し続けている
- 学習が手探りになりやすい
- 最初に知っておくだけでその後の学習効率が上がる知識があった！
- TypeScriptの外側を型どる知識
-
「型」に対する学問としての知識
-
MinCamel
- 型調査を学べる
- そもそもプログラミング言語が動く仕組みを学べる
-
Go言語でつくるインタプリンタ
- MinCamlでの1つの大きなトピックである、構文解析までが丁寧
- Go言語の人はこっちの方がわかりやすいかも..?
- 型システム入門
- ゼロから学ぶRust
-
MinCamel
個人的に特に心にグッときたセッションでした!!
TypeScriptのメリットは検索すれば出てきますし型定義すれば型検査の恩恵を受けることはできます。過去に動的型付言語で開発していた自分としては、TypeScriptを書いてる中で「型を使うことの本質を理解しているのか？」という思いがよぎることがありました。
現代の開発にはプログラミングだけではなく、ミドルウェアやクラウドインフラなどあらゆる側面の知識や技術で成り立っていますが、セッションを通し、改めてプログラミングとより深く向き合うアプローチの1つを知ることができました。
今後、迷えるエンジニアと出会ったらこのセッション資料をそっと共有したいと思った素敵なセッションでした📕！
印象に残ったLT
生産性を爆上げするため入社後すぐBiomeを導入した話
by 鈴木 貴大 さん
-
Monorepoのformat/LintをBiomeへ移行
-
移行前
- deno fmt/lint + ESLint
- JavaScriptランタイムをdenoからNode.jsに移行したがdeno fmt/lintを継続使用
-
移行後
- Biome
- Rust製の高速なフォーマット & 静的解析ツール
- Prettierと97%の互換性
- 移行した理由
- 開発環境改善のため
- Biome
-
移行前の課題
- Node.js環境でVsCodeとdeno fmt/lintの相性が悪い
- VsCode上にlintが表示されない
- VsCodeで保存時にフォーマットされない
- fmt/lintするにはコマンド実行が必須
- VsCode上にlintを表示するためESLintを併用しているが機能が重複
- リポジトリが巨大化するにつれて移行のハードルが上がる
- Node.js環境でVsCodeとdeno fmt/lintの相性が悪い
-
MonorepoとBiomeの相性は？
- Biomeの現状
- 現時点ではそれほど相性が良いとは言い切れない
- ただし、ルートに置いた共通設定を各ディレクトリで上書きはできる
- Monorepoの設定に関する公式ドキュメント
- VsCodeの現状
- biome-vscodeが問題なく動作する
- BiomeもVsCodeのプラグインもMonorepo環境での導入に前向きなので期待大
- Biomeの現状
-
移行について
- 公式ドキュメントの方法を採用した
- 設定自体はしやすかった
- 移行して良かったこと
- 2 out 1 in
- 型検査が早くなった
- VsCodeでも問題なく動くのでOK
弊社でもBiomeに絶賛移行中のプロジェクトがあるので共感できる部分は多かったです。移行後の現場のメンバーからの感想が「早すぎて気持ち悪い笑」だったのが面白かったです🙂笑
また、個人的にはJavaScriptランタイムをRust製のdenoからNode.jsに移行した理由や経緯も気になりました。この辺りは双方の違いをもう少し調べてみようと思いました。
tslogで実現するセキュアなメタデータ管理とロギング
by sugar-cat さん
- アプリケーションログの話
-
tslog
- Node.jsとブラウザどちらも対応
- ライブラリの依存なし
- TypeScript製
- 出力方式
- Pretty
- JSON
- 秘匿性の高い情報の取り扱い
-
保存前にマスキング処理が走る
-
課題
- あらかじめkeyがわかる値はマスキング対応できるが、意図せず混入したフィールドのマスキングは難しい
-
対策
- TypeScriptの型を利用
- 方法1 (△)
- Loggerに渡す前にパースして特定のフィールドを除去する
- 方法2 (◯)
- シンプルにログ出力の文字列化の前にJSON.stringifyでリプレイスしてフィルタリングする
- 方法2の方を採用した理由
- ユーザーのリクストデータ以外に暗黙的にLoggerの処理で追加されたフィールド含めフィルタリングでき、カバー範囲が広い
- Zodを挟むよりもパフォーマンスが良かった
- 方法1 (△)
- TypeScriptの型を利用
-
JSON.stringifyでリプレイス処理を自動化したい！
-
Typiaを使用して自動化
- 型情報をもとにコンパイル時にバリデーションを生成する
- TypiaとZodの比較
-
Typiaを使用して自動化
-
結論
- tslogとTypiaを組み合わせてセキュアでハイパフォーマンスな構造化ロギングを実現できた
-
秘匿性の高くセンシティブなデータの取り扱いはサービスの信頼性に大きな影響を及ぼすので、必要な処理を自前で実装せず信頼できるライブラリで自動化するのは開発効率の面だけでなく、機能実装するエンジニア側の心理的安全性を担保する側面もあると感じ、仕組み化しておくことの重要性を改めて感じました。
Full-Stack TypeScript開発で共通化すべき型とは
by 龍野 卓己 さん
-
Full-Stack TypeScript開発で定義して良かった型は？
-
API通信のリクエスト / レスポンス
- フロントエンド、バッックエンドどちらかが実装中でも、型定義を元に実装を進めれる
- IEDで型を検索すると影響範囲が一目でわかる
-
他の方は共有すべきか？
- 以下は共有しても良さそう
- 認証や権限まわり
- ステータスや種別コードなどのサービス固有のリテラル型
- 外部APIのリクエスト / レスポンス
- 上記以外は無理に共有しなくても良さそう
- 以下は共有しても良さそう
-
-
過剰な型定義の共有はどのような影響があるのか？
- 型定義のファイルが余計に増えて管理が大変になる
- 本来バックエンドのみで必要な定義もフロントに露出することになる
-
対策は？
- ロジックの責務を整理することが先！
-
型定義と共有方法の選択肢
- 外部からimportして共有
- プライベートパッケージとして公開し、プライベート空間に共有
- Zodなどのライブラリで型定義を生成して共有
- react-hook-formのリゾルバを通してフォームのバリデーションに活用
- 外部からimportして共有
型定義は手段であってそれ自体が目的になってはならないという話でした。目的と手段がいつの間にかすり替わってしまうことは型共有の話だけでなく、機能実装においても発生します。違和感を感じた時に「目的に対する適切な手段を取れているか」を考えることはあらゆる場面で大切にしていきたいですね。
感想
初めてのカンファレンス参加でした！一番感じたことは、登壇されてる方だけでなく、会場で聞いている方々も非常に熱心に聞いていて会場からTypeScript愛が伝わりました。普段からTypeScriptを書いてる身としては非常にモチベーションが上がり、参加できて良かったと感じました！
これからも積極的にカンファレンスに参加していきたいと思います👍
Discussion