掘力計画第 26 期北京ステーションオフラインサロン｜node.js の実践と未来について話す - 掘金
三つの共有
1/3 SSR と Worker についての簡単な話#
梁伟文字字跳動 - NodeJs Infra - 研究開発エンジニア
五年前端の職務経験があり、美団、字節跳動で働いてきました。現在は字節跳動で基盤技術の研究開発に従事しています。
SSR に関すること#
SSR の基本概念の紹介、CSR の概念との区別。
SSR の利点
- より良い SEO
- fp/fcp の時間により注目。
- 統一された言語
- 選択的導入
SSR を使用しないシナリオ
- TTFB - time to first byte を改善するため
- より早いインタラクション TTI - time to interactive
- 重い UI インタラクション
- 複雑なユーザー認証
実行時サポート Node.js、Deno、cf workers など
Worker#
サービスワーカーを導入することで fetch を導入でき、リクエストを構築したことになります。この観点から、winterCG の組織が導入され、異なる実行時が含まれています。Web API の標準化に対応し、一つのコードが異なる実行時で動作します。
複合標準の標準的な実行時。
worker の利点
- web 標準の実行時。
- v8 に基づいて開発された標準的な実行時で、独立性と制御性を実現し、API から実行時までを掌握できます。
- プライベート API の開発
- 軽量で、サーバーの負担が非常に少なく、pm2 で 3-4 のインスタンスを起動できますが、自分の worker を使用すれば、数百のプロセスを実行できます。
- デプロイも迅速で、例えば字節内部で node から worker への移行で、デプロイ時間が 90% 短縮されました。
- 汎用的なソリューションで、同構造で同じツール、開発プロセスを使用できます。
worker の問題
- node 環境を完全に互換することは不可能で、fs や net などはありません。例えば pupeteer や node-gyp など。
- fetch のみがリクエストをトリガーし、rpc やタイマーなどはできず、tcp データベースも使用できません。
- リンクトレースの ID に標準がなく、混乱しやすいです。
互換性の問題が多いです。
技術共有の延長として「字節跳動 Serverless 高密度デプロイと Web-interoperable Runtime の実践」を紹介します。
worker の実際の落地、qrcode を生成するサービスが迅速にオンライン化されました。serverless 高密度デプロイシステムのため、スケーラビリティや性能仕様を気にする必要がありません。
特徴：軽量、デプロイが速い。
落地シナリオ：
- worker をプロセスエンジンとして使用し、コードを実行するノードを埋め込むことができます。例えば langchain を使用して、入力と出力を処理します。
- 広告ルールの計算。費用
- 製品戦略の選択。上記は主に速さ、軽量さ、オンライン化の容易さに関するものです。
- 例えば、いくつかのコアサービスの伴生サービスは、元のサービスに負担をかけることはできません。
- 自動化された生産物、例えば設定インターフェース、インターフェースサービスを得ることができます。
SSR と worker の組み合わせ#
- SSR は js runtime 実行時が必要で、worker がそれです。
- SSR web 標準
- SSR シンプルロジック
使用シナリオの例を挙げますが、無視します。
SSR を worker に置くと、worker は edge、CDN などに熟知していません。
SSR を worker に置いたので、異なるシナリオで実行できます：
- nsr-native サイドレンダリング モバイル端末のレンダリング、次のページのレンダリングを予測し、モバイル端末の秒開を得る。
- ストリーミングレンダリング、ttfb を解決するために、一部のコンテンツを現出させる。
- edge デプロイ、ttfb の最適化が可能ですが、他の問題も発生します。
- csr のバックアップ、エラーのフォールバック。
- 設定や cdn のようなキャッシュが可能です。
QA 部分#
- SSR と auth の組み合わせ、ユーザー権限との連携が可能かどうかを尋ねたところ、選択によるとの回答があり、キャッシュには注意が必要です。
- SSR には SSR+csr の部分があり、いくつかのロジックの実行タイミングを区別する方法、例えば window オブジェクト、location オブジェクトについて
- サーバーサイドには window がないため、polyfill を導入して window がエラーを出さないようにするか、csr の方が適切かを判断する必要があります。
- SSR と csr のリクエストをどのように区別しますか？これはリンクトレースをマークする必要があるかもしれません。
延伸#
自分の JavaScript ランタイムを作成する
2/3 ユーザー体験のデジタル化と効率化#
去哪儿 qunar ホテル前端責任者任龍飛
アウトライン
- ユーザー体験のデジタル化
- フロントエンドのデジタル化による効率化
- まとめと展望
ユーザー体験のデジタル化#
ビジネスの背景と分析
ユーザー運営シナリオの細分化。ユーザー体験、開発体験。
ユーザー体験をどのように測定しますか？異なる指標があり、ここでは図を示しました。色の部分。
細分化の方向。
技術的視点からの距離
以前は零散的なツールと指標があり、ここで全体的なデジタル化を行います。
指標部分は流暢さ tti/fcp/lcp など、安定性 crash exception killRate、エネルギー消費 energy cpu overheat など。
能力部分、架空、apm、報告書など。
全体的なデジタル化を行うには、指標を定め、監視を行い、プラットフォームを構築することが必要です。ゲストが図を示し、詳細を展示しました。
ここで話していることは私には馴染みがなく、具体的にどのように体験を最適化するかを話します。まず評価指標を持ち、すべての部門が認識を合わせ、実行可能なプランをまとめます。具体的な部門が体験の最適化部分を行ったら、それを抽象化して普及させ、基盤部門にプランを作成させます。
その後、全ライフサイクルでデータを測定し、特別な最適化を行います。
しかし、フロントエンドの最適化には限界があり、最終的にはデータ取得の段階に戻ります。どのように最適化するかは、予測や事前検索を行い、ユーザーが次のページにより早く進めるようにすることです。
それは事前リクエストのプラン設計に変わります。異なる戦略を通じて、どの行動の後に事前リクエストをトリガーするかを計算します。
技術的な利益：予測リクエストのヒット率 31%、TTI が 60% 以上低下。
トリガーのタイミング、例えばファーストスクリーンのトリガー、ブラウジングのトリガー、ジャンプのトリガー。
測定ができれば、監視を行い、トレンドを見て問題を見つけ、指標を分解し、特別な最適化を行います。
競合分析は、できるだけ自動化テストを行います。例えば、携帯電話のスクリーンショット、コード注入、ocr 認識など、依然として自動化手段に落とし込み、データを組み合わせます。
これは業界内でのデジタル化の比較のためです。
定期的に競合と比較します。指標を定義し、データを測定し、分析をまとめます。
フロントエンドのデジタル化による効率化#
ビジネスに責任を持ち、オンラインサービスの内容が多く関与していますが、フロントエンドの効率をどのように最適化するのでしょうか？
ローコードプラットフォームの設定。BFF も serverless 上のサービスを提供しています。
ここでは、自社開発の Serverless プラットフォームの紹介を行いました。図には特に何もありませんが、後で必要があれば戻って聞いてください。
ローカルからクラウドへの開発。システムの完成品も紹介されました。システム設計図。toC のコンテナトラフィックは常にあります。
単一の pod、多くの関数、安全性を考慮したビジネスの隔離。
まとめ#
qa 部分
- 単一の pod の安定性、熔断はどのように処理しますか？例えば、特定の単一関数 pod が満杯になった場合、レプリカ数はどのように設定しますか？非常に専門的ですね。
- システムは内部プラットフォームであり、オープンソースにはなりません。
- 使用しているのは aws リソースで、nestjs を使用しています。関数間の相互呼び出しにはボトルネックがありますが、どのように処理しますか？
- 関数はすべて呼び出すことができ、invoke または new で実行できます。
- aws では iam role を使用してリソースを区別し、関数リソースの権限管理はどのように行いますか？現在はデフォルトで全開です。
- 関数のカスタムランタイムは、node ランタイムのみを実装しました。
- 可視化編集は行いましたか？sdk 編成はどのように行いますか？エンティティを編集し、実行します。複数のサービス呼び出しは編成可能ですか？実施の難易度はかなり高いです。
3/3 AI 時代における node.js V20 の機会#
狼叔！
- node バージョンの変化
- node v20 の紹介
- ai 時代の新しい機会
- 再び全栈を見直す
node バージョンの変化#
2017 node v8 - 2023 node v21
v20 では多くの機能が安定しています。
node v20#
いくつかの基礎知識と実践。
commonjs から esm にデフォルトで移行し、以前は混乱していましたが、今は統一され、v21 ではデフォルトで正規化され、より簡単になりました。
コミュニティは esm の導入を積極的に推進しており、esm のみをサポートし、cjs はサポートしていません。sindresorhus が発表した esm only のレンダリングについても言及されており、これは一つの契機です。
- esm サービスの変換：
- 例えば、従来の react プロジェクトでは、依存関係を分析して esm.sh 上の依存関係に変換します。
- ts リソースに遭遇した場合、sucrose を使用して esm にトランスパイルし、ローカルで直接実行します。
- カスタムレンダリングを通じて、タグの内容を html に書き込むことで、ブラウザ開発を実現し、ページレンダリングを完了します。
- ローコードの場合、cli を使用せずに実現できます。
- vite が代表的で、rust に移行し、cli を必要としない可能性があります。esm の方向性では cli が不要になる可能性があります。
- node は web コンテナを実行できます。
未来は期待できます。
node 内蔵の構文。node v20 では deno のようなリモートからの実行が可能ですが、まだ最新バージョンには搭載されていません。
非同期フロー制御。error first/promise/async-await の三つの方法。歴史的には geneator/blue brid などは少なくなり、主流は Promise と async/await の方法を受け入れています。
テスト方向 xv、node assert テスト文を作成し、xv で実行します。非常に軽量です。
テストフレームワーク内蔵 node:test、以前はフレームワークとアサーションライブラリを使用していましたが、今は必要ありません。直接 node --test --test-reporter spec --watch ./*..test.js*、node + node
ts は一等市民として、deno/bun はすでに内蔵サポートしています。知識の進化、equal タイプ体操 tsc/tsd/tsx/tsup/tsdoc など、ioc デコレーター、デザインパターン、oop など。
mongo から primay /drizzle などに移行し、型を導入しました。Proxy/Reflex、トランザクション処理はまだ少し面倒で、開箱即用のものはまだ少ないです。
oop の未来は java との違いはあまりないでしょう。
今、node モジュールを書くのも簡単ではありません。deno/bun を使用する場合は簡素化されるでしょう。
deno bun と比較。利点と欠点。
node は互換性と安全性に重点を置き、直接的に速さを追求するわけではありません。node の性能は十分です。matteo collina の「why is bun faster than node.js」から。
より軽量なランタイム。例えば noslate workers、wintercg に対して良好な worker を実現し、シーン faas + er。
thread worker/vm/vm2 の選択肢は多くあります。
node の得意なこと、そして副作用を理解する。補足は少なくします。
node v8 から v20 までの追加されたもの。
ai 時代の新しい機会#
融合とエコシステム。
prd から ui の認識、コードまで、各ステップには大量の計算があります。非常に苦痛です。
ai がコードを書くのを助けることを理解することは、より多くの専門家 + ai です。
ai sdk のサポートは、node に対してもサポートがあり、多くのアプリケーションがより早くなります。他の言語よりもアプリケーション層を構築するのが早いです。
下の図は ai 技術ソリューションです。
node を使用して迅速に組み立ててオンライン化することができ、node + ai には利点があります。
documate + node、勝場 ai 文書、aricode のオープンソース。彼の依存関係を見て、orama ベクトルデータベース、コードの実装が簡単で、node は機能を実現するのに非常に適しています。
融合、trpc は前後の呼び出しを型付きで実現します @trpc/client。aircode にも言及されました。
httpc.dev を使用すると呼び出しが実現できます。sdk 上でパラメータを組み立て、対応する関数を呼び出します。
node - faas は軽量化され、sdk を通じて http に関する知識を隠し、難易度が下がります。
再び全栈を見直す#
フロントエンドは死んだ？外注、サーバーサイドの置き換えの現象。
next.js で直接 use server を呼び出す現象は、php の時代に戻ったように感じます。フロントエンドには大きな革新がありません。前後の循環、全栈。
rails dhh の変化について話します。
ローコード、作業量は変わらず、作業量を減らし、中間段階を減らすにはどうすればよいか。retool.com を話し、ローコード、sql、自動 UI を巻き込みます。
書き巻 4、次の十年、
QA
- cpu 集中計算。thread-worker アーキテクチャを分割し、napi を rust に調整することは、能力の分割が最も効果的です。例えば golang を使うこと。
- node に ts を内蔵する可能性はありますか？はい。
- js+ts、型に基づいて最適化します。はい、エコシステムは現在 ts の型推論に依存しています。
三つの共有を聞いた後の展望#
三人は確かに素晴らしいです。多くのことが理解できず、実戦からの経験です。ただ、密度が少し高いです。
最初の話を聞いて、worker についてさらに理解でき、cloudflare 上の workers/puppeteer/ d1 などの製品のシナリオ制限も理解しました。元々バックエンドを行っていたので、必ずしも node である必要はありません。
二つ目は少し難しく、レベルが高く、詳細な内容が特に多く、実践したことがないので理解はできても消化できません。
三つ目は、node のこれらの変化を再び見直しました。