JSConf2023
まじまっちょ盛りだくさんだ
まじまっちょtc39のプロセスについて
ステージ0
アイディア、企画書、問題意識
ステージ1
チャンピオンが委員会に提出？
まじまっちょ
LLM全盛時代の開発プラクティス
Copilot
「飛行機などネットが使えないとGitHub Copilotが使えなくて困る」→ めっちゃわかる
constのみ／functionのみ／混在を比べる
既存の実装が不必要に統一されていない場合、サジェストの精度は落ちてしまう
そもそも統一感がないと「外在性認知負荷」が増えるため生産性が落ちる。
統一感がない場合TODOを貼るだけでサジェストの精度は上がる
→外在性認知負荷も下がりそう
統一感が大事
Figma To Code
AIレビューツール
まじまっちょwakamsha
マネフォのフロントエンドリアーキテクチャ
フロントエンド推進グループ（フロントエンドのイネイブリング）
老朽化＋大規模改修を控えたプロダクトを優先して作り直した
やったこと
- Rails依存のフロントエンドを剥がしてモダンなものに作り直し
- モダンフロントエンド開発のスキルをチームに移譲する
方針
- 丸暗記の排除（丸暗記している人が多かったらしい）
- 一度に多くの知見を盛り込まない
- CSSの苦手意識を払拭
- ペアプロで小さな成功体験をたくさん積んでもらう
- 自動テスト、ビルドを充実させる
- ドキュメンテーション慣習の醸成
- README環境構築、ディレクトリの責務を理解できる状態を作る
- 意思決定の過程を後から辿れるようにする
- Design Doc、ADRの利用
まじまっちょ
App RouterのRouter Cacheの複雑さ
Data Cacheの使い道がよく分からない
それぞれどこに保存される？
このトークのメインはClient Cache
prefetchしまくって必要なリソースをとってくる仕組みをCacheと呼んでいるらしい
force-dynamic するとprefetchしても遷移時にリクエストが飛ぶ
prefetch時はLayoutの外側だけ
遷移時に中身を返す（外側も含まれている？）
cacheのexpireの条件すごい複雑
cacheのpargeする手段が複数ある、（サーバーアクションから、クライアントから）
Intercepted Routes初めて知った prefetchと相性が悪いらしい
まじまっちょApp RouterでのMPA刷新
歴史がすごいレガシーアプリ
DataCacheはPage RouterのISR相当
グループウェア（toB）だから最新データが表示されるのが期待される。
セキュリティ上の問題からDataCacheはリスクがある
→無効化
Dynamic Functionsを実行することでDataCacheが使われなくなる
Route Segment Configでキャッシュを無効化する設定にする。
cookieで認証認可してるなら実は漏洩はしないように実装されているっぽいがドキュメントにその挙動はない
Use Clientのネストは避けたほうがいいっぽいが、Server / Client Component 両方で使いたいコンポーネントがある
Next LinkはイベントハンドラーをOptional Propsとして渡すことで回避している
StorybookはServer Componentを未サポート
presentational componentの分離
test
React Testing Libraryが未対応なのでE2Eテストに倒している
Server Actions
再レンダリング時にはrevalidatePath/Tagでキャッシュをクリアすると再レンダリングされる
App Routerは従来のMPAとメンタルモデルが近い
基本はサーバーでレンダリング、動きが必要になったらクライアント側で実装
まじまっちょ生成AIっぽい体験
タイムアウトとか大変そう
同時接続数とか
基本WebSocket？
発表内容
Loading Indicatorで今まではローディングを表現していたが、生成AIっぽさは生成中だということを示さないとけない
逐次的に生成されているということをユーザーにもそのまま見せるという体験
streamingですでに動画や画像については利用されている
Stream APIはNode.jsで最初に実装された。ブラウザは後
Web Stream APIにStreamingの仕様は統一されいく流れになっている
ReadbleStream/WritableStream/TransformStream
生成AIはテキストだけでなく画像もStreamになりうる
閉じタグが必要な形式は生成AIのストリーム形式のアウトプットとしては向いていないかも？
SSEとReadbleStreamの関係は？
SSEの順番が入れ替わってしまうことはない？
まじまっちょKOTLINで書かれたGRAPHQLサーバーをNODE.JSでモジュラモノリス化している話
技術スタックめっちゃバラバラなの親近感が湧く
一番古いRails（事業のコアの部分）がかなり厳しい負債化している
技術的負債の解消
技術スタックの統一
モジュラモノリス化
Node.jsを採用した理由
- フロントエンドとバックエンドは同じ人が触るから
Platform側はパフォーマンスの要求が厳しくなることが多いのでGoでかく方針
サービス間の通信はgRPCにしようと思っていたがGraphQLにした
- node.jsとgrpcの相性が悪い
- GraphQLで統一することのメリットが大きい
- パフォーマンスはgRPCの方がいい
モジュラモノリス
モノリスなアプリケーションの内部を機能単位でモジュールに分割したアーキテクチャ
重なっている部分のオーナーシップを誰が持つか？
障害対応やインターフェース変更を誰に相談したらいいか
モジュール単位で開発テスト運用していく
マイクロサービスではダメ？
マイクロサービスのつらみあるあるみたいなやつがつらい
モジュラモノリスのデメリット
- デプロイの単位が大きい
- CIが肥大化複雑化する
- モジュールの境界を維持するためのコストがかかる？→脱法的に他のモジュールを参照するということができてしまうので仕組みで防がなければならない
将来的にマイクロサービスにうつしやすくする設計？
半年から一年くらいでKotlinからNode.jsに移行する
NestJSだった…
モノレポにするメリットよりデメリットの方が大きかった
prisma-importでモジュールごとにSchemaを分けている
モジュールを跨いだJOINは許可しない
モジュールを跨いだトランザクションを許可するかは検討中
テスト
テストはDIのモックを使っている
モックを提供するのは誰の役割？
疑問
サーバー間GraphQLはStichingでやっている？
まじまっちょStoryBook駆動開発
Testing ToolとしてのStorybookの説明
聴講者側のStorybookの利用率9割超えている
プロダクト開発の大変さをStorybookによって解消することを目指している
（私見）腐敗防止層としてのFrontendは考え方としてはわかるがFigmaのDesign Prototypeとかで腐敗は止めてほしい
"Story"bookのUIの単位がStoryなのがユースケースに対応するものだというイメージに繋がりやすくて良い
play関数いいよね
Chromatic使ってVRTの話もあるかと思っていたがなかった