こんにちは、私の名前はアレクサンダー・ゼレニンで 、私はウェブ開発者です。

情報は、アプリケーションまたはサービスの基礎です。







10年以上前、私はポーカールームの所有者と話をし、彼は1日あたり約10,000ドルをもたらすページを見せてくれました。 それは完全に平凡なページでした。 スタイルやグラフィックはありませんでした。 ヘッダー、セクション、およびリンクで壊れた実線のテキスト。 それは私の頭に収まりませんでした-どうしてこれがそんなお金をもたらすことができますか？



秘密は、「これ」が最初の包括的なオンラインポーカーガイドの1つだったことです。 このページにはPageRank 10/10（またはポイントではなく9）があり、検索結果では最初に出会ったものでした。



アプリケーションの目的は、それが何であれ、ユーザーに情報を伝える（受け取る、処理する）ことです。











あなたはすでにアイデアを持っていると思います。 例は際限なく引用できます（別の例：設計のためにWikipediaにアクセスしません。さらに、Wikipediaからの情報の一部は、サイト自体を開かなくても検索結果にすぐに表示されます）。 （または郵送/ PMで）、それがまだ適用される理由を説明します。



だから：あなたが何をするにしても、情報は常に第一になります。 ユーザーは確かに良質で高品質の情報を見つけて、あなたに連絡します。



次のように情報を使用して作業を整理する方法を説明します。

1.スケーラブル-レプリケーション、シャーディングなど。 アプリケーションと干渉することなく構成されます。

2.ユーザーにとって便利-文書化が簡単で、使い方を理解できます。

3.開発者にとって便利-ラピッドプロトタイピング、最適化の機会のみが必要です。



コンポーネントと開発者の数が少ない小規模なプロジェクトの場合、このアプローチは意味がありません。







目次：

1. 情報消費者
2. 情報の操作方法（API）
3. API内層
4. API外層
5. ヘビーデューティー最適化
6. ユーザー
7. スケーリング
8. キャッシング
9. バージョニング
10. まとめ

情報消費者

情報利用者は、内部と外部の2つのカテゴリに分類できます。



内部のものはあなたの製品とサービスです。 違いは、「それらの」APIがより制限の少ないはるかに幅広い機能を提供できることです。 たとえば、独自のドメイン上の同じGoogleマップはwebglを使用して動作する可能性があり、その結果、はるかに高速になりましたが、組み込みのマップは動作できませんでした（状況が変わると確認できませんでした）。



外部 -自社が所有していないエンドユーザーまたは製品。 たとえば、Googleマップの場合、あなたは外部ユーザーです。 通常、外部からの情報へのアクセスは厳しく制限されており、特別なアクセスキーが必要になることがよくあります。

情報を扱う方法は？

情報を操作するために、Web APIを提供します。 2つのレイヤー（外部および内部）を実装します。 レイヤーとは、少なくとも別個のアプリケーションを意味します。



なぜAPIが必要なのですか？



APIを使用すると、プラットフォームに依存しない形式でデータを提供できます。 データがどのように、どこで使用されるかは常にわかっているわけではありません。APIの開発は、「情報があります-お問い合わせください」と言ってよい方法です。



すべてのコード例は、多くの実装の1つにすぎません。 これにより、最終製品の実装方法に関係なくデータを使用できるようになります（ネットワークへの少なくとも1回のアクセスを提供するオフラインアプリケーションを含む）。



まず、モデルとデータコレクションを記述する必要があります。 アプリケーションがJavascript（サーバー上のnodejs）に実装されている場合、クライアントとサーバーの両方で同じモデルを使用できます。



モデルとは、特定のエンティティ（音楽トラックなど）の説明です。 モデルのフィールド、プロパティ、情報へのアクセス方法および提供方法です。 モデルはデータベーススキーマを複製できますが、追加情報を使用してモデルを拡張することもできます。 さらに、モデルには複数のテーブル/コレクションからの情報を含めることができ、1つのエンティティとして表すことができます。 サーバーでは、テーブルの操作、サーバーアクセスなどの説明を使用してモデルを拡張する必要があります。 クライアントでは、データアクセスアドレスでモデルが拡張されます。



データにアクセスするとき、モデルにはリクエストに関する追加のメタ情報（実行時、データベース内のレコードの位置、通信）、仮想フィールド（たとえば、パスがデータベースに保存されている場合-ファイルへの相対パス、計算される仮想URLフィールドを追加できます） 「オンザフライ」）。



例として、特定の音楽サービスを説明するコードを提供します。



例はJavascriptで記述されますが、説明されているものはすべての言語に適用されます。 php、python、c ++でも同様のことをしました。 プロジェクトのサイズに応じてすべてを変える必要があります。

Model.extend('Track', { //   attributes: { id: 'integer', //     title: 'string', url: 'string', // /   duration: 'integer', album: 'app.model.Album.model', //     artist: 'app.model.Artist.model' } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コレクションは、エンティティのコレクションです（通常は同じ性質、つまり、音楽トラックなど）。 データセットには、セット自体に関連する追加データも含まれる場合があります。 メタ情報として、選択されたトラックの数、残りの（選択されていない）トラックの数、ページ番号、ページ数を表示できます。 仮想フィールドは、すべてのトラックの合計期間にすることができます。

 Model.List.extend('Track.List', { //   attributes: { duration: 'virtual' //  ,     } }, { duration: function(tracks) { //     return _.reduce(tracks, function(totalDuration, track) { return (track.duration || 0) + totalDuration; }) } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

API内層

このレイヤーは、当社製品でのみ使用可能です。



モデルにはすでに多くの情報が含まれているため、最小限のコードでデータへのアクセスを提供できます。







このレイヤーでは、クエリの柔軟性が最大限になります。

API外層

外側の層は、エンドカスタマーが直接利用できます。 Webサイトでも、サードパーティ開発者向けのAPIでもかまいません。



外側のレイヤーでは、内側のレイヤーのような柔軟性は提供しませんが、基本的な機能（メインリクエストパラメーター、インデント、数量など）へのアクセスのみを提供します。 そして、これには制限があります。



一部は、内部APIのプロキシであり、いくつかの重要な追加機能があります。



すぐに例：

 app.get('/api/track/:id', ..., function(req, res) { return app.model.Track.findOne({id: req.params.id}); })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「...」の代わりに、必要な権利チェックを行い、リクエストを変更し、フォーマットを決定します。 データは、要求と同じ形式で同じ方法で返されます。

つまり httpおよびjsonの場合、データが返されます。 ソケットおよびxmlの場合、応答はソケットを介してxmlで行われます。



したがって、外部からアクセスできるもの、方法、条件などを完全に制御できます。

ヘビーデューティー最適化

それ以前は、データベースをできるだけ抽象的に操作することを説明しました。もちろん、そのようなリクエストは最適化されたリクエストよりもはるかに遅く実行されます。 最初のステップで、（プロファイラーを使用するか、または便利な別の方法で）要求の一部が遅いことがわかります。



クエリがゆっくりと機能していることに気づいたとします。この場合、アルバムとミュージシャンに関する情報とともにトラックが選択されます。 最適化するには、新しい内部メソッドを作成する必要があります。

 Model.extend('Track', { 'GET /track/{id}/withAdditionalData': function() { var track = ...; //       //      return track; } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外側の層の呼び出しを提示されたものの内側の層に変更します。 それだけです エンドクライアントの場合、何も変更されておらず、キャッシュ、パス、受信データは同じですが、すべてが高速になりました。

ユーザー

ユーザーと作業する際の主なタスクは、ユーザーの権利を確認することです。



ユーザーがログインするとすぐに（メソッドは重要ではありません：Cookie、キー、別のオプション）、インナーレイヤーに1つのリクエストを行い、IDを確認して権限を取得します。 外側の層でさらにチェックを行います。

スケーリング

スケーリング段階で大きな利点が得られます。



また、任意の数のインスタンスで外部および内部APIレイヤーを起動し、バランサーの助けを借りて負荷を分散できます。 この分離により、データキャッシュを備えた独自のCDNネットワークを受信し、エンドクライアントにできるだけ近い外部層で多くのアプリケーションを実行できます。



データベースは、タスクに応じて古典的な方法で拡張されます。

キャッシング

内側の層では、データベースへのクエリの結果をキャッシュし、外側の層では、内側の層から取得した結果をキャッシュします。 エンドクライアントにもキャッシュがあります。



前の例の1つには、「cache：1800」という行がありました。これは、外部層でキャッシュを提供し、30分間サーバーで結果を記憶し、クライアントで結果をlocalStorage（wellまたは別のクライアントリポジトリ）などに追加します。

バージョニング

プロジェクトの開発に伴い、新しいメソッドが表示され、古いメソッドは残ります。 バージョンを示すために、 セマンティックバージョニングをお勧めします。 特に、下位互換性なしでAPIのメジャーバージョンを変更することに関心があります。 APIアクセスパスは簡単に分割できます：/ api / {version}



ファイルを整理し、さまざまなバージョンをサポートするには、いくつかの方法があります。例：

1.フォルダーv1、v2を作成し、それらに関連するすべてのコードを入れます。 APIバージョンのいずれかを変更する場合、もう一方は影響を受けません。

2.さまざまなリポジトリがさまざまなアプリケーションとして機能します。

まとめ

1. すべての段階でデータの移動を完全に制御できます。
2. 開発者は満足しています。特定の形式でデータを受信するための超スマートなメソッドを実装するために、APIチームから待つ必要はありません。
3. 開発者は満足しており、最適化できるのはスローダウンするもののみです。
4. 顧客は満足しています-APIはより安定しており、一部のリクエストが遅かったためにパスを変更しません。
5. 顧客は満足しています-サーバーの場所が可能な限り近いため、アクセス速度が向上します。

ご要望に応じて、記事にセクションを追加できることを嬉しく思います。

また、どこかでコードを明確にしたい場合-私が書いて添付しますので、尋ねてください。

おそらくこれは、さまざまなトピックに関する一連の大規模な記事の始まりです（ または、すでに始まっています ）。 多くの資料が蓄積されていますが、体系化されていません。