モバイルアプリケーション用の日曜大工クラウドバックエンド。 パート2

最初のパートでは、Windows AzureクラウドでRESTful APIを作成する方法と、モバイルアプリケーションでRESTful APIを使用する方法について説明しました。 このテキストと例はこの記事に大きく依存しているため、この記事をよく理解することをお勧めします。



モバイルアプリケーション向けのクラウドバックエンドの開発に関する記事の第2部では、APIのチーム開発のメリットを最大化する方法、1回書く方法、たくさん使う方法、およびコミュニティのヘルプを使用する方法について説明します。 始めましょう。

Windows AzureとGit

既に誤った話を聞いているように、Microsoftは最近、オープンソーステクノロジーに注目を集めるようになりました。 たとえば、 Visual Studio 2013の最新バージョンでは、 Gitバージョン管理システムのサポートが「そのまま」導入されました。 Windows Azureクラウドも除外されておらず、TFSだけでなくGitや他のシステム（SVN、Dropbox、Bitbucket）を使用してコードを操作できるようになりました。



Windows Azure Mobile Servicesはさらに先に進み、Gitのみを機能させることにしました。 おそらく、これはこのソリューションのプレビューバージョンの期間だけですが、企業の動向を考えると、このオプションはリリースに移行できます。



プロジェクトでGitを使用する理由は何ですか？ はい、すべてがいつもとまったく同じです。 つまり-コードの共同作業、各チームメンバーのローカルリポジトリ、バージョン管理のサポート。 しかし、さらに重要なのは、継続的統合の原則、つまりリポジトリ内のコードの新しいチェックインごとにソリューションを継続的に展開するという原則を遵守することです。 チームメンバーの1人がサーバーに変更を送信するたびに、クラウドに展開されます。 これらはすべてKudu （別のオープンソースプロジェクト）で機能し、非常に成功しています。

サービスでGitを有効にする

Gitを使用してモバイルサービスの操作を開始するには、このサービスのコントロールパネルに移動し、適切なアイテムを選択する必要があります。







アクションに自信があるかどうかを尋ねられ、関数がプレビュー段階にある間にいくつかの問題が発生する可能性があることを警告します。 同意して続行します。



リポジトリの作成が完了すると、サービスコントロールパネルの[構成]ページでリポジトリのアクセス設定を確認できます。 ソース管理セクションには、リポジトリへのアクセスのURLとソリューションの展開を開始するURLの2つのパラメーターがあります。







作成操作が完了すると、クラウドベースのGitの準備が整います。 サーバーに保存されているファイルをローカルリポジトリに取得しましょう。 標準のGitコンソール（たとえば、 Git Bash for Windows ）を使用できます。



次のコマンドを使用して、サーバーリポジトリをローカルに複製します。

git clone <URL_>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラウドサービス構成のGIT URLパラメーターで指定されたURLを指定する必要があります。 また、Gitユーザーのログイン名とパスワードを入力する必要があります（持っていない場合は、Gitリポジトリの最初の作成時に、Windows Azureがこのペアを作成することを提案します）。 結果は、次の画像のようになります。

リポジトリ構造

コマンドが完了するとすぐに、モバイルサービスの名前のディレクトリがハードドライブに表示されます。 その中には、 サービスフォルダーと.deploymentファイルがあります。 このファイルは重要ではありませんが、 サービスフォルダー内を見る価値があります。

 $ ls api extensions package.json scheduler shared table
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービス内のフォルダーの名前に注意を払うと、それらがすべてWindows Azureモバイルサービスのサブシステム（API、スケジューラー、およびテーブル）と同じであるというパターンに加えて、名前がextensionおよびsharedの 2つのディレクトリーをトレースできます。

APIディレクトリ

APIディレクトリは、カスタムAPIコード（ 最初のパートで作成したもの）を記述するファイルを保存する役割を果たします。 ディレクトリに移動してその内容を確認すると、次の3つのファイルがあります。

 $ ls coolapi.js coolapi.json readme.md
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのフォルダーにあり、その内容を簡単に説明するreadme.mdファイルとは別に、js-scriptsがここに格納されます。これは、使用している各APIに対応しています。 また、コード付きのスクリプトごとに、特定のAPIへのアクセス権を記述する1つの.jsonファイルがあります。 これらのファイルの内容を見てみましょう。 以下は、 coolapi.jsファイルの内容です。

 exports.post = function(request, response) { // Use "request.service" to access features of your mobile service, eg: // var tables = request.service.tables; // var push = request.service.push; response.send(statusCodes.OK, 'Hello World!'); }; exports.get = function(request, response) { var result = {type: 'message', data: 'Hello World!'}; response.send(statusCodes.OK, result); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、このファイルは、前の記事でWindows Azureコントロールパネルで直接記述したコードを正確に繰り返しています。 各APIの背後には、Node.jsアプリケーションで動作する単純なjsスクリプトがあるため、これは理解できます。



coolapi.jsonファイルは、この形式ではなく以前に間接的にしか見ていなかったため、もう少し興味深いものです。

 { "routes": { "*": { "get": {"permission":"application"}, "post": {"permission":"application"}, "put": {"permission":"application"}, "patch": {"permission":"application"}, "delete": {"permission":"application"} } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、これは、作成時に最初に設定した特定のAPIへのアクセス権の説明にすぎません（ただし、管理ポータルのウィザードを使用してこれを行いました）。 ここでは、HTTPメソッドごとに特定の制限が規定されています。 この場合、 アプリケーションタイプはすべてのメソッドに設定されます。つまり、アプリケーションキーを持つユーザーのみがこれらのメソッドにアクセスできます。 有効な値は次のとおりです。

• パブリック-すべてのユーザーにアクセスが許可されます（ポータルのすべてのユーザーをアナログ）
• user-アクセスは登録ユーザーにのみ許可されます（アナログのみの認証済みユーザー）
• admin-管理者のみにアクセスが許可されます（アナログのみの管理者）

これらのファイルのテキストを変更してからリポジトリに保存すると、すべての変更がすぐに管理ポータルに表示されます（つまり、すべてのユーザーが利用できるようになります）。 たとえば、メソッドの1つでHello World文字列をGitからHelloに変更し、GETメソッドをパブリック（パブリック）にして、修正をクラウドに送信します。

 git commit . -m "My first Git commit" git push
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は次のようになります。







操作ログを見ると、単にファイルをサーバーにコピーするだけでなく、Kuduを使用してソリューションを展開する作業が進行中です。



ここで、モバイルサービス管理ポータルに移動してこのAPIのコードを確認すると、変更内容を確認できます。







また、ブラウザ経由でAPIにアクセスする場合（GETメソッドの制限を緩和した後に可能になりました）、外部から変更にアクセスできることを確認してください。

テーブルディレクトリ

このフォルダーには、その名前から推測できるように、モバイルサービスにあるテーブルに関連するものを保存する必要があります。 ただし、ここに保存されるのはテーブル自体のデータではなく（Gitにとって論理的です）、レコードの挿入/削除/変更のイベントを制御するコードです（テーブルの操作の詳細については、 こちらとこちらをご覧ください ）。 MyTableというテーブルを事前に作成し、挿入操作中に機能するスクリプトをわずかに修正しました。 そして、これがテーブルフォルダーに結果として得られたものです。

 $ ls MyTable.json mytable.insert.js readme.md
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モバイルサービスでファイルに名前を付けるロジックに従って、jsonファイルにはテーブルへのアクセス権に関する情報が含まれており（これは、このファイルはAPIで見たものと似ています）、コードはjsファイルに格納されているという論理的な結論に達することができます。 さらに、ファイルの名前は、それが属するテーブルの名前と、それが定義されている操作から形成されます。 したがって、同様のファイルをローカルコンピューター上で直接作成し（mytable.update.jsなどの名前を付けて）、その中にコードを記述してサーバーにコミットすると、これらの変更は、手動でハンドラーを作成することなく、コントロールポータルですぐに利用可能になります更新操作。

共有ディレクトリ

ここには、モバイルサービスの特定の部分に関係のないスクリプトを保存できますが、逆にどこでも使用できます。 単一のサービス内のライブラリコードリポジトリのようなもの。 このコードを使用するには、最初にそれを記述し（コントロールパネルからこれらのスクリプトに直接アクセスできないため、Gitを介してのみ実行できます）、次に、既存のコードで新しいモジュールを接続する必要があります。



以下に簡単な例を示します。 myshared.jsという名前と次の内容のファイルを共有フォルダーに作成します。

 exports.someSharedMethod = function () { return 'Hello from Shared!'; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

APIコードでは、次のコード行を追加してこのモジュールを使用します。

 exports.get = function(request, response) { var myshared = require('../shared/myshared.js'); response.send(statusCodes.OK, myshared.someSharedMethod); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Node.jsを既に使用している場合、このコードはおなじみのものです。 これは、外部モジュールをアプリケーションに接続するための標準的なメカニズムです。 概して、 共有フォルダーはハードドライブ上の単なるディレクトリであり、共有モジュールを保存することをお勧めします。 魔法がない、すべて正直に。

その他のディレクトリ

残りの2つのディレクトリについては、前のディレクトリとほぼ同じと言えます。コードはその中に保存されます。 schedulerフォルダーには、対応するサービスを管理するためのスクリプトが含まれ、extensionsフォルダーには、モバイルサービスのNode.jsアプリケーション全体に接続でき、起動時に一度だけ実行されるコードが含まれます。 拡張コードが完了するまで、アプリケーション内の他のすべての操作が中断されることが保証されています。 これは、モバイルサービスを再起動するたびにデータベースで特別な設定を行う場合に便利です。

NPMパッケージ

Node.jsのアプリケーションがモバイルサービスの背後で動作していることを理解したら、尋ねるのは理にかなっています-NPMはありますか？ 知らない人にとっては、 NPMはNode（NuGetやLinuxのようなもの）のパッケージマネージャーです。 これは、さまざまな目的（エラー処理、ロギング、ビューの標準化など）用に設計された多数のサードパーティライブラリを数秒でプロジェクトに接続できるため、アプリケーションの開発時に非常に便利です。



幸いなことに、Windows AzureモバイルサービスでNPMを使用できます。 これを行うには、package.jsonファイル（api、tableなどのディレクトリと同じファイル構造のレベル）を編集する必要があります。 このファイルに必要なモジュール（Node.jsの標準的な方法、 依存関係セクション）の記述を追加し、このファイルをサーバーにコミットすることにより、Windows Azureにアプリケーション用にそれらをダウンロードさせます。 requireを介してそれらを接続するだけで、コミュニティの作成を最大限に活用できます。

おわりに

Windows Azureで利用可能なPaaSプラットフォームは、迅速かつ高品質のソリューションを必要とし、インフラストラクチャの展開と管理に多くの労力をかけたくない開発者に非常に豊富な機会を提供します。 Windows Azureモバイルサービスは、豊富で多機能な機能を提供します。 特に、カスタムAPIは、さまざまなプラットフォーム向けの一般的なソリューションを開発する必要がある場合に、コードの重複の問題を回避するのに役立ちます。



さらに、Microsoftにとって良いと光栄なのは、同社が現代のトレンドに応えることを決定し、オープンソースとクロスプラットフォームを支持して独自技術の使用を部分的に放棄したことです。 お気付きの方は、この記事で紹介したすべてのことを、PC、Mac、Windows、Linuxのどのコンピューターでも完全に実行できます。 また、3つの主要なモバイルデバイスすべてにネイティブクロスプラットフォームライブラリが存在すること（およびそのサービスのほとんどに対するREST APIサポート）により、このクラウドをほぼどこからでも使用できます。 私の意見では、これはビジネスを行うための優れたアプローチであり、将来のための大きな準備金です。



PS最後に、モバイルサービスでのGitリポジトリの作業はまだプレビュー段階であるため、何かが不安定で、時間が経つにつれて変化する可能性があることに注意してください。

PPSこの記事は、 Microsoft Virtual Academyの YouTubeビデオチュートリアルまたはコースとしても利用できます。