クライアント⇔BFF⇔他言語APサーバやるぐらいなら、クライアント⇔APPサーバ on TS(ランタイムはbunでもnodeでも)でFullStackで良くねに思える。ほとんどがIOバウンド主体だし。でも、個人開発じゃ大規模なリクエストでも問題ないっすわ！とも言えず、モニョモニョしてる
— ござパイセン (@gothedistance) 2024年5月20日
シングルスレッドが問題になるとしたら、FastAPIが動いているPythonもGILなのでシングルスレッドじゃねって思ったのがきっかけ。asyncioがNodeにおけるノンブロッキングI/Oと等価だと思う。PythonのGIL、3.13で廃止されるんだってね。そうなると、gunicornのようにワーカープロセスを何本かあげて管理するモデルも、お役御免になるかも。
php-fpmやgunicornのように親のプロセスでサーバ起動して、ワーカープロセスに各々リクエストを処理させることで、シングルスレッドでマルチプロセスで並行処理ってのもわかる。Nodeもやろうと思えば出来るしそういうNPMパッケージがあるけど、expressの上にかぶせたっていう話は聞いたことがない。僕は。さーせん。今の時代はリクエストの並行稼働をコンテナ単位でスケーリングしようとするから、Expressどうこうじゃないのかもしれない。
APサーバでやることって、バックエンドのDBとか、別コンテナとかにビジネスロジックの実行を依頼することが多い。9割がIOバウンド。PythonでSQL発行すると速いのにTypeScriptでSQL発行すると遅いって、言語が原因ではないでしょ。
SQLを実行しているのDB。SQL自体は早くてレスポンスが遅いなら、コネクションの問題であって言語の問題じゃない。TCP開けるのにPythonが速くてNodeが遅いって意味がわからん。
BFFは必要悪だと考えていて、全部TSで行う致命的なデメリットはない派。IOバウンド主体の処理を動かすなら、パフォーマンス面のデメリットはあまり感じられない。PDF1000ページのPDF作るなら、マルチプロセスでやらないときつかろう... 帳票生成系はNode弱いです。HeadlessChrome起動してHTML->PDFみたいなことやったけど、遅かった。
とんでもないリクエストをPHPで捌いているグラブルのエンジニアチームが「Webサービスにおけるパフォーマンスにおいて、言語の差は誤差です」って仰ってくれたらそれを額縁に入れて飾るのに・・・！
上記仮説が正しいか検証するには大規模プロダクトのバックエンドを全部書き換えないといけないけど、そんな機会がどこにあるんだよなので、自分が受託して請けた範囲でFull TSでやっていきいき。
