あなた自身のAPIのクライアントであるというパフォーマンス上の問題はありますか？

Question

Twitterを例にとると、twitter.comは自分のAPIのクライアントと言います。これがTwitterがかなり「遅い」理由の1つになりますか？

参考：http://engineering.twitter.com/2010/09/tech-behind-new-twittercom.html

は、あなたがメインのウェブサイト/アプリのために独自のAPIを使用して勧めますか？

独自のAPIを使用しても問題ない場合は、どのような方法でパフォーマンスの問題を回避できますか？

Answer 1

独自のAPIの使用について：これはトレードオフです。ツイッターの例では、独自のAPIを使って「APIチームにもっと多くのリソースを割り当てる」ことができました。それらの利益は、パフォーマンスヒットを上回った。他にも言及されていない他の利点があります。例えば、あなたのAPIを獣医師が最初に確認し、システムへの単一の統一されたエントリポイントを持つことです。あなたが投稿したリンクにも言及されている欠点もあります。

アプリケーションでは、達成したいアーキテクチャの特性を見て、それを与えられた制約とバランスさせて、自分で選択する必要があります。超高性能がリストの最上位にある場合は、その目標を達成するためにソリューションを工夫してください。

独自のAPIを使用する場合のパフォーマンスについて：もう一度異なります。 Twitterのケースでは、彼らはJavaScriptでAPIにアクセスすることを知っていました。したがって、物理的なジャンプはブラウザ - >サーバー - > DBです。クライアント/サーバー開発を行っている場合、これらのホップを回避する方法はありません。投稿したリンクの中で、彼らはDBに直接行くことについて話しました。はい、それは高速ですが、私はどのようにjavascriptクライアントから行うか分からない。私は彼らがカスタムAPIにウェブソケットを使用していたとすれば、それはより早いだろうが、どの開発コストであろうと思う。

要約パフォーマンスヒットだった独自のAPIを使用しているわけではありません。クライアントがHTTPホップを離れたかったからです。 これらのコメントのいずれも、サーバーのdbコールの外観やキャッシュ戦略、またはボトルネックとなる可能性のある他のダースのものについては言及していません。