Twitter を例にとると、彼らは twitter.com を独自の API のクライアントと呼んでいます。これが、Twitter が非常に「遅い」理由の 1 つになるのでしょうか?
参考：http ://engineering.twitter.com/2010/09/tech-behind-new-twittercom.html
メインのウェブサイト/アプリに独自の API を使用することをお勧めしますか?
独自の API を使用しても問題ない場合、パフォーマンスの問題を回避する方法は何ですか?
独自の API の使用について:トレードオフについてです。Twitter の例では、独自の API を使用することで、「より多くのリソースを API チームに割り当てる」ことができました。彼らにとってのメリットは、パフォーマンスへの影響を上回りました。言及されていない他の利点もあります。たとえば、API を最初に精査し、システムへの単一の統一されたエントリ ポイントを持つことです。あなたが投稿したリンクに記載されている欠点もあります。
アプリケーションでは、達成したいアーキテクチャの品質を調べ、それと与えられた制約とのバランスを取り、独自の選択を行う必要があります。超高性能がリストの一番上にある場合は、その目標を達成するためのソリューションを作成してください。
独自の API を使用する場合のパフォーマンスについて:これも状況によります。Twitter の場合、彼らは JavaScript で API にアクセスすることを知っていました。したがって、物理的なジャンプはブラウザ -> サーバー -> DB です。クライアント/サーバー開発を行っている場合、これらのホップを回避する方法はありません。あなたが投稿したリンクで、彼らはDBに直接行くことについて話しました。はい、それはより高速ですが、JavaScript クライアントからそれを行う方法がわかりません。カスタム API に websocket を使用していた場合、それはより高速だったと思いますが、開発コストはどれくらいでしたか。
まとめパフォーマンスが低下したのは、独自の API を使用しているからではなく、クライアントを HTTP ホップ 1 つ離れた場所に配置したかったからです。これらのコメントはどれも、サーバー --> db 呼び出しがどのように見えるか、そのキャッシング戦略、またはボトルネックになる可能性のある他の多くのことについて話しているものではないことに注意してください。