Node.js と MongoDB を使用してモバイル・アプリを開発する: 第 1 回 チームが採用した手法とその結果

Systems of Engagement (人と関わりあうシステム) のタイム・ツー・バリューを短縮する

Node.js (サーバー・サイドの JavaScript) を使用して Systems of Engagement (人と関わりあうシステム) を開発する利点を探ってください。この記事では、IBM Extreme Blue チームが Node.js と MongoDB を使用して、Systems of Engagement (人と関わりあうシステム) の概念を実証するアプリケーションである IBM Passes で挙げた成果を紹介します。このチームが Node.js と MongoDB を使用した経験は、企業でも使われ始めているこれらのソリューションを使用することで、いかに迅速なアプリケーション開発が実現できるかについて、興味深い洞察をもたらしてくれます。Node.js と MongoDB を使用することにした場合には、この連載の第 2 回を参照してください。第 2 回では、Node.js による本番環境での詳しいハウツー情報とベスト・プラクティスを説明しています。

2014年 1月 30日の更新内容: 企業において、Java と並んで Node.js がエンタープライズ・アプリケーション・プラットフォームとして使用されるようになっていることについて明確な記述を追加しました。

Zach Cross, IBM Extreme Blue intern, IBM

Author photo - Zach CrossZach Cross は、ノースカロライナ大学 (UNC) チャペルヒル校でコンピューター・サイエンスの学士号を取得しました。現在は、UNC 大学院でコンピューター・サイエンスの学位を目指しているところです。彼の専門分野はソフトウェア・エンジニアリングおよびシステムです。特に、ネットワーク・プロトコルを得意としていて、分散システムと GPGPU プログラミングにも強い関心があります。余暇は、自転車、読書、料理を楽しんでいます。2013年 8月に IBM Extreme Blue インターンシップを終えました。



Aga Pochec, IBM Extreme Blue intern, IBM

Author photo - Aga PochecAga Pochec は、ワルシャワ経済大学で国際ビジネスの修士号を、そして高名なヨーロッパの CEMS (Community of European Management Schools and International Companies) プログラムで修士号を取得しました。現在は、ボストンのハーバード・ビジネス・スクールで経営管理学の修士課程を修了しつつあり、IBM で Extreme Blue インターンとして働いています。彼女はヨーロッパおよびアジア太平洋で 5 年間のビジネス・インテリジェンスおよびコンサルティングの経験を持つプロジェクト・マネージャーであり、マーケティング、ストラテジー、ビジネス開発を専門としています。旅行をこよなく愛し、時間があるときには新しい文化と料理を探索しています。2013年 8月に IBM Extreme Blue インターンシップを終えました。



Daniel Santiago, IBM Extreme Blue intern, IBM

Author photo - Daniel SantiagoDaniel Santiago は、現在プエルトリコ大学でコンピューター・エンジニアリングを学んでいる学生です。プログラミングに情熱を傾ける彼は、モバイル、バックエンド、Web 開発に関心を持っています。また、Node.js や MongoDB などの新しい技術にも好んで取り組んでいます。余暇は、料理、ランニング、そしてゲーム用コンピューターのアセンブルを楽しんでいます。2013年 8月に IBM Extreme Blue インターンシップを終えました。



Divit Singh, IBM Extreme Blue intern, IBM

Author photo - Divit SinghDivit Singh は、現在コンピューター・サイエンスの修士号を目指しているバージニア工科大学の大学院生です。PhoneGap および Sencha Touch でクロスプラットフォーム・アプリケーションの作成に取り組んでいる彼は、モバイル技術を専門としています。アプリケーションの開発を楽しんでいて、開発したアプリケーションを Google Play Store と GitHub で公開しています。また、Node.js などの新しい Web 技術にも好んで取り組んでいます。趣味は、スポーツ、音楽、テレビ・ゲームです。2013年 8月に IBM Extreme Blue インターンシップを終えました。



2014年 1月 30日 (初版 2013年 9月 19日)

モバイルおよびクラウド技術の発展は、企業が顧客に働きかけて顧客とつながる方法を劇的に変化させました。企業は、スケーリングしやすく、クラウドとモバイルですぐに使うことができ、迅速に本番へ移行できるバックエンド・ソリューションをより一層求めるようになっています。

Java は、現在なお、エンタープライズ・アプリケーションやクラウドを構築する際に使用される標準的なプログラミング言語ですが、その一方で業界内には、アプリケーションを構築する際に、コンテキスト・スイッチングの量を削減する強力な動きがあります。モバイル・ファーストで設計するという考え方が最新のトレンドであることから、開発者は「アウトサイド・イン」のアプローチで開発を始めるようになりつつあります。「アウトサイド・イン」の設計は、ユーザーに関する部分から始まるため、真っ先にユーザー・インターフェースが開発されます。UI を開発する上で要となるものの 1 つが JavaScript です。JavaScript を使用してクライアント側から開発を始められるようにし、あとからサーバー側でその同じ JavaScript のスキル (Node.js と MongoDB はどちらも JavaScript がベースになっています) を再利用できるようにすることで、開発者が理解しなければならない各種プログラミング言語間でのコンテキスト・スイッチングの量を大幅に削減することができます。Walmart、General Motors、Linkedin のような業界大手では公然と Node.js を採用、支持しており、Node.js は相当な勢いで Java と並ぶエンタープライズ・アプリケーション・プラットフォームとして企業に採用されつつあるようです。

IBM Extreme Blue チームについて

Extreme Blue プログラムとは、ソフトウェア開発と MBA の学位を目指す有能な学生を対象とした IBM のインターンシップ・プログラムです。詳細については、ibm.com/extremeblue にアクセスしてください。

ノースカロライナ州、リサーチ・トライアングル・パーク (RTP) にある IBM ラボの Extreme Blue チームは、IBM Passes のバックエンド全体を Node.js で開発するという課題に取り組みました。その結果、チームは同じ機能を提供する Java によるソリューションに比べ、開発に要する時間を 40% 短縮することに成功しました。さらに包括的なパフォーマンス・テストも行い、Node.js バックエンドはスケーラビリティーの点でもハードウェアの使用効率の点でも Java より優れていることを実証しました。

この記事では、MongoDB と併せて使用した場合の Node.js の重要な特徴と利点を紹介します。Node.js による本番環境に最適なソリューションのタイプ、そして Node.js による本番環境の利点と欠点を学んでください。

Node.js、JavaScript、JSON、および RESTful な Web サービスの基本概念を理解している開発者の方であれば、この記事を最大限に活用できるはずです。

 

IBM Passes

IBM Passes は、2012年の秋に Apple からリリースされた Apple Passbook を中心に構築されたソリューションです。Apple Passbook は、ユーザーが飛行機の搭乗券、映画のチケット、小売店のクーポン券、ポイント・カード、そしてその他の顧客エンゲージメントのための材料 (「パス (passes)」と呼ばれます) のすべてを 1 箇所に保管できる便利なアプリケーションです。Apple は、このアプリケーションをパスの仕様と併せてリリースしましたが、企業がこれらのパスを作成して管理する方法までは提供しませんでした。この問題に対処するのが、IBM Passes です。IBM Passes は、他のアプリケーションで使用できる API を提供する RESTful な Web サービスを特徴としています。このサービスは IBM PushWorks を介して Apple の Push Notification Service とやりとりし、IBM WebSphere Analytics Platform を使用してアナリティクスを処理します。

IBM はこのサービスのフロントエンドを作成して、ユーザーがパスを作成、更新、配布できるようにしました。このフロントエンドは、「パス・ビルダー (Pass builder)」と呼ばれます (図 1 を参照)。パス・ビルダーは、Passes バックエンドの RESTful なインターフェースを利用する HTML/JavaScript ソリューションです。パス・ビルダーの詳細については、包括的な紹介、または簡単な紹介と動画を参照してください。

図 1. IBM が提供するパス・ビルダー (Pass builder) のインターフェース

IBM Passes バックエンドの現在の実装では、Java サーブレットを使用して DB2 にアクセスしています。このソリューションの場合、JSON 文書は DB2 のリレーショナル・データベース内にストリングとして保管されるため、JSON 文書が関わるすべてのトランザクションでシリアライズとデシリアライズが必要となり、オーバーヘッドが追加されます。さらに、ネストが深くなるにつれて、JSON 文書のプロパティーに対するクエリーの実行がますます複雑になってきます。


Java に代わる手段: Node.js および MongoDB 技術スタック

私たちが選択した技術に関する注記

最初の IBM Passes アプリケーションを手掛けたチームは、当初、このアプリケーションに Node.js と MongoDB を使用することを検討していました。しかし、この記事には述べられていないさまざまな理由から、バックエンドには従来からのエンタープライズ・アプリケーション開発プラットフォーム (Java EE と SQL データベース) を使用することとなりました。

私たちのプロジェクトで焦点となったのは、IBM Passes ソリューションの RESTful なバックエンドを別の手段で実装することです。その手段として、Node.js と MongoDB という、まったく別の技術スタックを使用しました。これにより、Java 実装を置き換えながらも、フロントエンド・クライアントを引き続きサポートすることが可能になりました。この実装が提供する API は、Java 実装と同じ API のセットであるため、パス・ビルダー・クライアントのバックエンドとして使用することもできます。

私たちは Java バージョンの機能を再現することに加え、両方のアプリケーションで包括的なパフォーマンス・テストを実施しました。また、私たちが使用した技術スタックでコア機能を実装するのに要した開発期間は 3 週間で、Java チームが 5 週間かかったのに比べると、タイム・ツー・バリューにして 40% の短縮となりました。この技術スタックを使用することに決めた理由は以下のとおりです。

  • Apple Passbook の仕様 (完全に JSON) に基づいていること
  • JSON を第 1 のデータ交換フォーマットとする RESTful な Web サービスであること
  • JavaScript Everywhere (フロントエンド、バックエンド、データ・ストア) であること

Node.js を選んだ理由

Node.js の利点

Node.js (Node) は Google Chrome の JavaScript ランタイムをベースに作成されたスケーラブルなイベント駆動型の I/O 環境であり、基本的には JavaScript のサーバー・サイドでの実装です。Google V8 は、実際には JavaScript をネイティブ・マシン・コードにコンパイルしてから実行するため、通常の JavaScript にはない特性として、極めて高速なランタイム・パフォーマンスを実現できます。したがって、Node.js では電光石火の如く高速で、並行性に優れたネットワーク・アプリケーションを迅速に構築することができます。

Node.js は、JavaScript の Web サーバー・ランタイムです。Node.js では JavaScript を使用することから、フロントエンドの開発者はバックエンドの開発者と同じ言語で作業することができます。このような概念は、JavaScript Everywhere と呼ばれます。実際面では、この概念により、開発者が理解しなければならない技術の種類が減り、開発作業が統一化されます。しかも、最もよく使用されているデータ交換フォーマットである JSON をフロントエンドでもバックエンドでもネイティブに構文解析することができます。これも処理のオーバーヘッドを削減できる手段の 1 つであり、シリアライズの単純化を通じて行われます。スクリプト言語を使用する利点に加え、Node.js の軽量のランタイムは、迅速な開発およびデプロイメントを可能にします。したがって、通常は反復作業を縦割りで行わなければならないアジャイル開発には、Node.js が強力なソリューションとなります。

表 1. IBM Passes に使用されている主要な技術
パス・ビルダー・フロントエンドPasses バックエンド
JavaScriptJava
Node.jsサーブレット・コンテナー
MongoDBDB2
JSONSQL
JSON

Node.js には、最近の Web のワークロードをサポートする特徴があります。それは、頻繁に小さな構造化データを交換することです。このような特徴があることから、Node.js は Systems of Engagement (人と関わりあうシステム) に最適です。別の言葉で言い換えると、計算プロセスではなく情報の交換が関わってくるアプリケーションには Node.js が理想的な候補となります。技術的に言うと、これは Node.js が CPU バウンドなアプリケーションよりも I/O バウンドなアプリケーションに適していることを意味します。IBM Passes は、そのようなアプリケーションの好例です。計算コストの高い処理は、暗号化を用いる署名と圧縮 (zip 圧縮) だけしかありません。アプリケーションのそれ以外の部分は、JSON データと画像リソースの交換が中心になります。

Node.js が大抵の Web アプリケーション・ランタイムと異なる点は、その並行性の対処方法にあります。Node.js では、スレッド化によって並行性を実現するのではなく、単一のプロセスで実行されるイベント駆動型ループを利用します。Node.js は非同期 (非ブロッキング) モデルをサポートする一方、Java などの技術は同期 (ブロッキング) モデルをサポートします。この 2 つの概念の主な違いを明らかにするために、以下に説明するレストランの例えを検討してみましょう。

非同期モデル

例えば、Web アプリケーションはレストランであり、着信リクエストは料理を注文する顧客だとします。非同期アプリケーションでは、1 人のウェイターが複数の顧客に同時に対応します。注文が完了すると、そのウェイターが顧客に料理を運びます。このウェイターは、顧客からの新しい注文には、手が空いたときに対応します。

同期モデル

同期モデルの「レストラン」では、顧客が注文をする始めから食事の終わりまで 1 人のウェイターが 1 人の顧客に専任で対応します。そのため、レストランには顧客の数と同じだけのウェイターが必要になります。その上、ウェイターには他の作業を行うことが可能でも待機している時間があります。

この例えで説明している両者の違いは、並行性を実現するためのメカニズムのみです。Java はスレッドを使用して並行性を実現する一方、Node.js はイベント・ループを使用します。このことから、Java では、スレッド間のコンテキスト・スイッチの際にオーバーヘッドが追加されることになります。言い換えれば、スレッドの数が多くなると、それだけコンテキスト・スイッチに費やされる時間も増えることになり、その分、着信リクエストを処理する時間が少なくなります。そのため、Java アプリケーションは拡張すればするほどコストが高くなります。

一方、Node.js は、ファイルの読み取り処理の完了や、データベース・クエリーの完了といったイベントに基づき、非同期 I/O をサポートします。これらのイベントはコールバック関数によって処理されるため、I/O が行われている間でもアプリケーションの処理を続行することができます。これらのイベントを処理するのは、イベント・ループです。イベント・ループの詳細については、Andrew Glover 氏による developerWorks の記事「Java 開発者のための Node.js」を参照してください。


MongoDB を選んだ理由

MongoDB は、容易に開発およびスケーリングできるように設計されたドキュメント指向のデータベースです。MongoDB では JavaScript オブジェクトをネイティブに保管できるため、時間と処理能力が節約されます。MongoDB でクエリーを行うには、SQL のようなドメイン特化言語ではなく、単純な JavaScript インターフェースを使用します。検索対象を部分的に記述する JavaScript オブジェクトを渡すだけで、簡単にドキュメントを検索することができます。

前述のとおり、Apple Passbook の仕様は JSON にかなり依存していることから、私たちの問題領域には MongoDB が理想的なソリューションでした。事実、パス自体は JSON オブジェクトとして記述されます。そのため、準複合 JSON 構造を (DB2 などの) 1 つのリレーショナル・データベースにおける複数のリレーションにするよりも、パスをそのままの形で MongoDB に保管したほうがより望ましい方法となります。


ベンチマーク・テスト

私たちが行ったパフォーマンス・テストの手法

チーム (IBM Mobile Cloud Development チームと Extreme Blue チーム) は、完全なスタックの本当の評価を曖昧にしておこうとするのではなく、はっきりと評価を下すことに決めました。そして私たちは、Node.js には DB2 を扱うためのアダプターがないのと同様に、Java ベースの技術の中で MongoDB を扱うためのアダプターを見つけるのは容易ではないことがわかりました。そこで私たちは、時間がうまく使われて、昔ながらの技術と新しい技術が隔てられるのだろうと考えました。私たちは、組み合わされる技術は通常、古いもの同士か、新しいもの同士であることもわかったため、技術を選択する際には、主にこのような技術の組み合わせとなることに重点を置きました。

時間的制約のために、実行できなかったことが 2 つありました。そのうちの 1 つを挙げると、私たちのチームには長い間 Web コンテナーを扱ってきたメンバーがいたので、どのメソッドに最もコストがかかっていたかを示すために、あるコール・スタック・レベル (浅いレベルと、深いレベルの両方) でパフォーマンスの数値を確認し、それぞれのメソッドの実行に要している時間を詳細な累積的ビューで得られると良かったです。

私たちは、Node.js で実装した IBM Passes を Java で実装したものと比較するために、この 2 つのアプリケーションのエンド・ツー・エンドのパフォーマンスについて、ベンチマーク・テストを行うことにしました。最終的に関心がある測定基準は、各種 API エンドポイントへの HTTP リクエストに対する応答時間です。この手法の主な目的は、それぞれのソリューションの背後にあるスタック全体のパフォーマンスを記録することでした。私たちはオペレーティング・システムやネットワークなどの可変の部分を考慮したので、2 つのアプリケーションを客観的に比較することができました。さらに、データベースに対するクエリーの実行時間や、個々の関数の実行時間を測定するといった粒度の細かい分析よりも、エンド・ツー・エンドの応答時間を測定した方が、実際のユーザー・エクスペリエンスをより適切に反映したものになるという確信もありました。

方法

両方のアプリケーションのベンチマーク・テストを行うために、HTTP ベンチマーク・テスト・コマンドライン・ツールである Apache Bench に対する Node.js ラッパーを作成し、そこから一般的なテスト定義を実行して結果を生成するベンチマーク・テスト・フレームワークを作成しました。Apache Bench は、平均応答時間とその標準偏差、1 秒あたりのリクエスト完了数、失敗 (200 以外の) 応答数、サーバー・エラーの発生回数、タイムアウトの発生回数を知らせてくれます。パラメーターとしたのは、並行性レベル、リクエストの数、リクエストの構成です。このフレームワークにテスト定義とセットアップ関数を追加し、アプリケーションのベンチマーク・テストに取り掛かりました。

私たちはベンチマーク・テスト・プロセスのツール面にも対処しました。このプロセスには科学的手法を意図していたことから、テスト環境は、テストそのものよりも重要とは言わないまでも、テストそのものと同じく重要です。そこで、OpenStack を使用してクラウド環境を模倣することにしました。Node.js アプリケーション、Java アプリケーション、そして負荷生成アプリーションに対し、いずれも同じインスタンスを構成しました。各インスタンスには 2.4 GHz のクアッド・コア (仮想) プロセッサー、8 GB の (仮想) RAM、そして 80GB のストレージを割り当てました。図 2 に、使用した OpenStack デプロイメントのトポロジーを示します。

図 2. OpenStack デプロイメントのトポロジー

これらのインスタンスは、同じ基本イメージ (Ubuntu Server 12.04 64-bit) を使用して構成されています。また、インストールしたのは、アプリケーションを実行してモニターするのに必要なソフトウェアだけです。ランタイム構成に関して言うと、Node.js にはデフォルト構成 (Chrome V8 エンジンが利用しているのと同じ構成) を使用しました。

サーブレット・コンテナーと DB2 には、Java チームに JRE のランタイム構成を問い合わせて、そのデフォルト構成を使用しました。さらに構成を行うことで、バックエンドのパフォーマンスが改善される可能性があることは認めますが、これは Node.js ランタイムにも該当することであり、重要なポイントではありません。私たちの目的は、Node.js がアジャイル開発を促進するだけでなく、パフォーマンス基準を満たし、(垂直スケーリングではなく) 水平スケーリングに対応可能である、という事実を証明することにあります。

ベンチマーク・テスト・ジョブは、負荷生成プログラム・インスタンスの Web インターフェースから手動でキューに入れられるか、コード・ベースが変更された結果としてキューに入れられます。ベンチマーク・テストは OpenStack 環境内で継続されます。私たちはベンチマーク・テスト・ジョブを、すべてのテスト・スイートを実行するもの (API エンドポイントを実行する一連のグループなど) として定義し、ブランチ名、並行性レベル、実行されたリクエストの合計数の各パラメーターを指定しました。ベンチマークにおいては、ベンチマーク・テスト・ツールによって一定の API エンドポイントのセットをテストしました。これらのテストは、順次 (つまり、トラフィックがオーバーラップすることがないようにして) 実行しました。また同じ理由から、ベンチマーク (テストのグループ) も順次実行しました。

結果

このテスト・ケースでは、並行性レベルが 50 を超えると、Node.js および MongoDB の実装の方が Java の実装よりも、応答時間が短いことが明らかになりました。これは、Passes アプリケーションの I/O バウンドな性質によるものだと考えられます。並行性レベルが 50 より低ければ、Java で実装したアプリケーションのほうが高速になります。これは、負荷が低い状態では、アプリケーションが I/O バウンドから CPU バウンドになるためです。並行性レベルが高い場合には、すべての API 呼び出しについて、Java/DB2 よりも単一の Node.js インスタンスのほうが明らかにパフォーマンスに優れています。

図 3. パフォーマンスの結果 (アプリケーションごとの「より高速な」エンドポイントの数)

Node.js による実装と Java による実装のハードウェア使用状況を比較するために、この 2 つのアプリケーションが実行されるインスタンスのプロファイルを作成する必要がありました。そのために使用したのは、CollectD および StatsD という 2 つのよく使われている統計収集アプリケーションです。CollectD をインスタンスにインストールすると、無視できる程度のオーバーヘッドがもたらされますが、このインストールによって、CPU 使用率、メモリー使用量、ディスク使用量が明らかになります。これらの統計を収集するために、モニター対象のインスタンスでは StatsD を使用しました。さらに、同じインスタンスで Graphite も使用して、時系列データをダッシュボード形式で示されるグラフとして表示しました。

このようにすることで、各ベンチマークを時系列のハードウェア使用状況データに関連付けることが可能になりました。エンドポイントごとのベンチマーク・テスト中に、メモリー使用量と CPU 使用率の平均値を取るなかで気付いたのは、全般的な傾向を示すことがより有益であるという点です。図 4 に、長時間のベンチマーク実行期間にわたる測定基準を示します。Node.js アプリケーションのほうが平均的に CPU 使用率が低く、メモリー使用量も少なくなっています。この低い CPU 使用率は、アプリケーションが持つ I/O バウンドという性質の結果として解釈できると思います。

図 4. ハードウェア使用状況のベンチマーク・テストによるパフォーマンスの結果

まとめ

Node.js は最近の Web が抱えるあらゆる問題の解決策にはならないかもしれませんが、Systems of Engagement (人と関わりあうシステム) の要求に対しては理想的なソリューションです。Node.js は I/O バウンドなアプリケーションおよび頻繁な情報交換を主眼として設計されています。その軽量のランタイムは、アジャイル開発と即時の反復作業を可能にします。IBM Passes のテスト・ケースではっきり示されたように、Node.js によってタイム・ツー・バリューが 40% 短縮されるだけでなく、(Java 実装と比べて) 半数のサーバーで 2 倍のトラフィックに対応することができます。すなわち、Node.js は Java と同じ機能を実現できるだけでなく、迅速な開発、そしてハードウェア使用状況の改善という点で Java よりも優れています。


謝辞

私たちのメンターとして、インターンシップ期間全体にわたりその見識と経験で私たちを導いてくださった Joshua A. Alger 氏、Andy Dingsor 氏、Curtis M. Gearhart 氏、Christopher Hambridge 氏、Todd Kaplinger 氏に深く感謝いたします。私たちの成功は、IBM Extreme Blue の RTP Lab Manager である Ross Grady 氏の忍耐強さと励ましで絶え間なく改善を重ねることができたおかげです。また、Node.js の経験と貴重なフィードバックを提供してくださった Jeff Jagoda 氏にも感謝の意を表明いたします。

参考文献

学ぶために

製品や技術を入手するために

議論するために

  • developerWorks コミュニティーに参加して、開発者によるブログ、フォーラム、グループ、Wiki を調べ、仲間やエキスパートとのつながりを持ってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development, Java technology
ArticleID=945550
ArticleTitle=Node.js と MongoDB を使用してモバイル・アプリを開発する: 第 1 回 チームが採用した手法とその結果
publish-date=01302014