これは「回りくどくてパフォーマンスによくないのではないか?」と思いました。
まぁ、シビアな世界の話をすればそうですね。
パフォーマンス気にするならなんでPHPなんて使ってるの?全部Golang(gin)でやれば良くね?と思います。
ですが実際の現場だったらよくある光景ですね。
PHPのエンジニアが多いから基本的にはPHPでいきたいが、この機能だけはどうしても速度が欲しいからNode.jsやGolang使いましょうとか、
PHPやRubyで書いたWebサービスが大当たりした、ScalaやGolangで書き直そう!でもリソースの問題あるから、URLのパス文字列で区切って、今月はここの部分だけ書き直します!
また、高速でフロント(JS+Ajax)、バック(PHP)の両方から問い合わせる両対応なWebサーバが欲しいよねー
・・・という要件もありGolangみたいな高速な言語に白羽の矢が立つ事があります。
沢山の事はしないけど1個の事は超上手くやるWebサーバ…これをマイクロサービスアーキテクチャと呼びます。
本当にlocalhostを経由する必要があるのでしょうか?
一般的にはリバプロですかね〜。
Nginxが得意です。
大量のリクエストを捌いてくれるNginxに80番ポートを紐付け、代表的なWebサーバとして構築します。
PHPは適当に3000番ポート、Golangは4000番ポートに紐づけて動かします。
リクエストがやってきたらパス文字列を確認しながら、/api
で始まるから4000番ポート、それ以外は3000番ポート、静的ファイルはNginxがそのまま返すという構成が人気ありますね。
こういったリバースプロキシ目的でNginxを採用する企業は数多くあります。
そうすればJavaScriptからAjaxで直接GolangにGraphQL問い合わせができますね。
PHPもGolangに気軽に問い合わせられるようになります。
もっとうまいやり方がある気がします。
速度だけでいうなら色々と選択肢があります。
しかし、自分の中で閉じるlocalhostのHTTP通信は十分速いです。
Twitterのような売れっ子サイトになる前の今悩むのは捕らぬ狸の皮算用だと思いますがいかが?
これらの代替手段を使った場合、それはHTTP通信を待ち受けるWebサーバではありません。
PHPの裏で走るだけのアプリなら速度を求めてUNIXドメインソケットで実装すれば良いのですが、
自分で直接フロントに立ってHTTP通信を捌きたいならWebサーバとして立ち上げるしかありません。
なので全体的に見てlocalhostにHTTP通信投げるやり方は最も良い案の一つではあります。
GraphQLサーバーをアプリケーションサーバーと呼ぶのでしょうか?
GraphQLは単なる会話の規約ですよね。
リンク先の記事の実装にはnet/httpモジュールを使っている跡がありますし、
あくまでGraphQLでの通信はHTTPサーバのリクエストを受け付けた先のやり取りの話を指してますよね?
でしたらそれはWebサーバです。
そしてWebサーバもそっからRestfulサーバ、APIサーバ・・・などなど色々派生していくわけで、
Webサーバでもあり、APIサーバでもあり、マイクロサービスアーキテクチャで作られたアプリケーションサーバでもあるといったところでしょう。