【ITニュース解説】Node.js gRPC calls and Promises

現代のITシステム開発において、異なるシステム間での連携は不可欠な要素である。特に、Webサービスを構築する際には、複数のマイクロサービスや外部APIと効率的に通信する必要がある。このような文脈で、Node.jsを使ったアプリケーション開発において、非同期処理の理解はシステムエンジニアにとって非常に重要となる。

Node.jsはサーバーサイドJavaScriptの実行環境であり、その最大の特徴の一つが非同期I/Oとイベントループに基づく処理モデルである。これにより、単一のスレッドで多数の同時リクエストを効率的に処理できるため、スケーラブルなアプリケーションを構築するのに適している。しかし、この非同期処理の特性を正しく理解していなければ、予期せぬ動作やバグに遭遇することがある。

ニュース記事では、Node.jsサービスがgRPCという仕組みを使って別のサービスと通信する際に発生した問題とその解決策が取り上げられている。gRPCとは、Googleが開発したリモートプロシージャコール（RPC）のフレームワークであり、異なるプログラミング言語で書かれたサービス間でも効率的かつ高速に通信することを可能にする技術である。サーバーとクライアント間で定義されたインターフェース（プロトコルバッファ）を通じて、まるでローカルの関数を呼び出すかのようにリモートの関数を実行できるのが特徴である。

記事で示された問題は、Node.jsアプリケーションにおける非同期処理の典型的な課題を浮き彫りにしている。具体的なコード例を見てみよう。まず、MyControllerというコントローラがあり、これがmyService.getItem()というサービスメソッドを呼び出している。コントローラではawait myService.getItem()と記述されており、awaitキーワードは通常、その処理が完了するまで次の行へ進まない、ということを意味する。これにより、サービスからデータが返ってくるのを待ってから、コントローラがres.status(200).json(data)を実行し、クライアントに応答を返すことを期待する。

しかし、実行結果のログを見ると、驚くべきことにcontroller: undefinedが先に表示され、その後でservice: {"id": "item-1234", "foo": "bar"}が表示されている。これは、コントローラがサービスからのデータ取得を待たずに、undefinedの状態で処理を完了させてしまったことを示している。なぜこのような現象が起きたのだろうか。

問題の核心は、IstServiceクラス内のgetItemメソッドの内部にある。このメソッドはthis.grpcClient.GetItemを呼び出しているが、このGetItemメソッドが非同期処理の結果を返すのに、伝統的な「コールバック関数」のパターンを使用しているからである。コールバック関数とは、ある処理が完了した後に実行されるように登録される関数のことである。this.grpcClient.GetItemは、最初の引数でリクエストデータを、二番目の引数でコールバック関数を受け取っている。このコールバック関数は、gRPC通信が成功した場合はresponseを、失敗した場合はerrを受け取って処理を行う。

ここで重要なのは、awaitキーワードは「Promise」というオブジェクトを返す関数に対してのみ、その完了を待つことができるという点である。記事のオリジナルのIstService.getItemメソッドでは、this.grpcClient.GetItemはPromiseを返さず、単にコールバック関数を実行するだけである。そのため、myService.getItem()内でawait this.grpcClient.GetItem(...)と記述しても、awaitは待つべきPromiseオブジェクトを見つけられず、すぐに解決されてしまう。結果として、myService.getItem()自体もPromiseを返さず、コントローラでawait myService.getItem()と記述されていても、実質的に待機する意味がなくなってしまう。これが、コントローラがundefinedをログに出力し、gRPCコールが後から完了したことを示すログがサービス側で表示された原因である。JavaScriptやTypeScriptでは、このようにawaitが意味をなさない場所でも文法エラーとならないため、気づきにくい問題となることがある。

この問題を解決するために、JavaScriptの非同期処理の進化の歴史を理解することが役立つ。かつてはコールバック関数が非同期処理の主流だったが、処理が複雑になるにつれてコールバックが何重にもネストされ、「コールバック地獄」と呼ばれる可読性の低いコードになりがちだった。これを解決するために導入されたのが「Promise」である。Promiseは、非同期処理の最終的な完了（または失敗）と、その結果の値を表現するオブジェクトである。Promiseを使うことで、非同期処理の連鎖をより分かりやすく記述できるようになる。

さらに、ES2017で導入されたasync/await構文は、このPromiseをさらに扱いやすくするための「シンタックスシュガー」である。asyncキーワードを付けた関数内でawaitキーワードを使うと、Promiseが解決されるまで関数の実行を一時停止し、Promiseが返した結果を直接変数に代入できるようになる。これにより、非同期処理をあたかも同期処理のように記述できるようになり、コードの可読性が大幅に向上する。

記事が提示する解決策は、まさにこのPromiseとasync/awaitの仕組みを正しく活用することにある。IstService.getItemメソッドの内部で、new Promise()を使ってthis.grpcClient.GetItemのコールバックパターンをPromiseでラップするのである。

新しいgetItemメソッドは、次のように変更される。 return new Promise((resolve, reject) => { ... }); ここでnew Promiseのコンストラクタには、resolveとrejectという二つの関数を引数に取る関数を渡す。resolve関数は非同期処理が成功したときに呼び出され、その結果の値を渡す。一方、reject関数は非同期処理が失敗したときに呼び出され、エラーを渡す。

this.grpcClient.GetItemのコールバック関数内で、エラーが発生した場合はreject(err)を呼び出してPromiseを失敗状態にする。エラーがなければresolve(response)を呼び出してPromiseを成功状態にする。これにより、IstService.getItemメソッドは正しくPromiseオブジェクトを返すようになる。

この修正によって、コントローラ側のawait myService.getItem()は、IstService.getItemから返されるPromiseが解決されるまで、本当に待機するようになる。gRPCコールが完了し、resolve(response)が呼び出されると、そのresponseがmyService.getItem()の戻り値としてコントローラに渡され、data変数に正しく代入される。その結果、コントローラはundefinedではなく、gRPCサービスから取得した実際のデータをクライアントに返すことができるようになるのである。

この経験は、システムエンジニアを目指す上で非同期処理の仕組みを深く理解することの重要性を教えてくれる。JavaScriptにおける非同期処理は、単にコードを記述するだけでなく、その裏側で何が起きているのか、コールバック、Promise、async/awaitがどのように連携し、どのように機能するのかを把握することが、予期せぬ問題を回避し、堅牢で効率的なシステムを構築するための鍵となる。特に、外部ライブラリやフレームワークがどのような非同期パターン（コールバックかPromiseか）を使用しているかを常に意識し、必要に応じてPromiseでラップするなどの適切な対応をとる能力は、非常に価値のあるスキルである。