Node.jsを使用するタイミングを決める方法
私はこの種のものには慣れていませんが、最近私は Node.js がどれほど優れているかについて多くのことを聞いています。 jQueryとJavaScript全般を扱うことが大好きであることを考えると、Node.jsをいつ使用するかを決定する方法について疑問に思うしかありません。私が考えているWebアプリケーションは Bitly のようなものです - いくつかのコンテンツを受け取り、それをアーカイブします。
私が過去数日間にやってきたすべての宿題から、私は以下の情報を得ました。 Node.js
- 通常のWebサーバーとして実行でき、JavaScriptプログラムを実行できるコマンドラインツールです。
- すばらしい V8 JavaScriptエンジン を利用しています
- あなたが同時にいくつかのことをする必要があるときにはとても良いです
- イベントベースなので、すべての素晴らしい Ajax -のようなものをサーバー側で実行できます。
- ブラウザとバックエンドの間でコードを共有できます
- mySQLと話すことができます
私が遭遇した情報源のいくつかは以下の通りです。
Node.jsは Amazon EC2 インスタンス上でほとんどそのまま使用できることを考慮して、私は、どんな種類の問題がNode.jsを必要としているのかを理解しようとしています。 PHP 、 Python 、 Ruby のように。私はそれが言語に関する専門知識に実際に依存していることを理解していますが、私の質問はより一般的なカテゴリーに分類されます。特定のフレームワークを使用するとき
あなたはNode.jsについて素晴らしいことを要約する素晴らしい仕事をしました。 Node.jsは、ブラウザからサーバーへの持続的な接続を維持したいアプリケーションに特に適していると私は感じています。 "ロングポーリング" として知られる技術を使用して、リアルタイムでユーザーに更新を送信するアプリケーションを書くことができます。 Ruby on Rails または Django のように、ウェブの巨人たちの多くを長時間ポーリングすると、アクティブな各クライアントが1つのサーバープロセスを消費するため、サーバーに大きな負荷がかかります。この状況は tarpit 攻撃になります。 Node.jsのようなものを使用するとき、サーバーはオープン接続ごとに別々のスレッドを維持する必要はありません。
これは、 ブラウザベースのチャットアプリケーション をNode.jsで作成できることを意味します。これは、非常に多くのクライアントにサービスを提供するためにシステムリソースをほとんど消費しません。この種のロングポーリングをしたいときはいつでも、Node.jsは素晴らしい選択肢です。
RubyとPythonの両方がこの種のことをするためのツール（それぞれ eventmachine と - twisted ）を持っていることに言及する価値がありますが、Node.jsは例外的にそしてゼロからそれをします。 JavaScriptはコールバックベースの並行処理モデルに非常によく位置しており、ここで優れています。また、クライアントとサーバーの両方にネイティブのJSONを使用してシリアライズおよびデシリアライズできることは非常に気の利いた方法です。
私はここで他の答えを読むのを楽しみにしています、これは素晴らしい質問です。
Node.jsは、クライアント/サーバーのギャップを越えて多くのコードを再利用するような状況にも適していることを指摘する価値があります。 Meteorフレームワーク はこれを本当に簡単にします、そして多くの人々はこれがウェブ開発の将来であるかもしれないと提案しています。経験から言うと、Meteorでコードを書くのはとても楽しいことです。その大部分は、データをどのように再構築するかについて考える時間を短縮することです。そのため、ブラウザで実行されるコードは簡単にできます。それを操作して返します。
こちらはpyramidとlong-pollingに関する記事です。geventからのちょっとした手助けで非常に簡単に設定できることがわかります： TicTacToeとPyramidを使ったLong Polling 。
Node.jsはリアルタイムのアプリケーション、オンラインゲーム、コラボレーションツール、チャットルーム、または他のユーザーがすぐに他のユーザーから見られる必要があるアプリケーションに対して実行される必要があるものに最適であると思います。ページを更新しないでください。
また、Node.jsと組み合わせてSocket.IOを使用すると、長時間のポーリングで可能なものよりもさらにリアルタイムの待ち時間を減らすことができます。 Socket.IOは最悪のシナリオとしてロングポーリングにフォールバックし、代わりにWebソケットまたはFlashが利用可能であればFlashを使用します。
しかし、スレッドが原因でコードがブロックされる可能性がある状況については、Node.jsを使用した方が適切な場合があることにも言及する必要があります。あるいは、アプリケーションをイベント駆動型にする必要があるあらゆる状況。
また、Ryan Dahl氏は、Node.jsベンチマークは通常の古いHTTPリクエストに対してNginxに匹敵することに私はかつて参加したとの講演で述べました。したがって、Node.jsを使用して構築すれば、通常のリソースを非常に効果的に提供できます。イベント駆動型のものが必要な場合は、それを処理する準備が整いました。
それに、いつもJavaScriptです。スタック全体でLingua Franca。
NodeJSを使用する理由：
Javascriptを実行するため、サーバーとクライアントでsame languageを使用でき、それらの間でコードを共有することもできます（たとえば、フォームの検証や、両端でビューをレンダリングするため）。
シングルスレッド イベント駆動型システムは fast であり、従来のマルチスレッドと比較して、一度に大量のリクエストを処理する場合でもシンプルです。 Java またはRORフレームワーク。
packages NPMからアクセス可能なの増え続けるプール。クライアント側およびサーバー側のライブラリ/モジュール、およびWeb開発用のコマンドラインツールを含みます。これらのほとんどはgithubでホストされており、問題を報告して数時間以内に修正されることがあります！標準化された問題報告と簡単な分岐により、すべてを1つの屋根の下に置くことができます。
Javascript-related toolsおよび他のweb-related toolsを実行するための事実上の標準環境になりました。分析プロセッサ。
プロトタイピング、アジャイル開発、および急速な製品の反復に非常に適しているようです。
理由not NodeJSを使用する場合：
コンパイル時の型チェックを行わないJavascriptを実行します。大規模で複雑なsafety-criticalシステム、または異なる組織間のコラボレーションを含むプロジェクトの場合、contractual interfacesを奨励し、static type checkingを提供する言語長期的には、デバッグ時間（およびexplosions）を節約できます。 （JVMは
nullでスタックしていますが、原子炉にはHaskellを使用してください。）それに加えて、NPMのパッケージの多くは少しrawで、まだ急速に開発中です。古いフレームワーク用のライブラリの中には、10年のテストとバグ修正を経たものがあり、非常にstableです。 Npmjs.orgにはパッケージを評価するメカニズムがありません 。これにより、ほぼ同じことを実行するパッケージが急増し、その大部分は維持されなくなりました。
ネストされたコールバック地獄。 （もちろん 20種類のソリューション があります...）
増え続けるパッケージのプールにより、1つのNodeJSプロジェクトが表示されます根本的に異なる次から。膨大な数のオプションが利用できるため、実装には多様性があります（例：Express/ Sails.js / Meteor / Derby ）。これにより、新しい開発者がNodeプロジェクトに飛び込むことが難しくなる場合があります。これとは対照的に、既存のプロジェクトに参加する開発者Railsは、すべてのRailsアプリでを使用することをお勧めしているため、アプリにかなり早く慣れるはずです。同様の構造。
ファイルを扱うのは少し面倒です。テキストファイルから行を読み込むなど、他の言語では些細なことは Node.jsで行うには奇妙な 80以上のアップ投票でStackOverflowの質問があることです。 CSVファイルから一度に1つのレコードを読み取る簡単な方法はありません です。等。
私はNodeJSが大好きで、速くてワイルドで楽しいですが、証明可能正しさにはほとんど関心がありません。最終的に両方の長所を融合できることを期待しましょう。将来的にNodeを置き換えるものを楽しみにしています... :)
短くするには：
Node.jsは、多数の同時接続があり、イベントのループ（他のすべてのクライアントとの）が関数の実行中にブロックされるため、各要求が非常に少ないCPUサイクルしか必要としないアプリケーションに最適です。
Node.jsのイベントループに関する良い記事は Mixuの技術ブログ：node.jsイベントループの理解 です。
Node.jsを使用した実際の例が1つあります。私が働いている会社には、単純な静的HTML Webサイトを望んでいるクライアントが1人いました。このウェブサイトは Paypal を使って一つの商品を販売するためのものであり、クライアントは販売された商品の数を示すカウンターを持っていたかったのです。このウェブサイトへの訪問者は膨大な数になると予想されます。私はNode.jsと Express.js フレームワークを使ってカウンターを作ることにしました。
Node.jsアプリケーションはシンプルでした。 Redis データベースから販売された商品の金額を取得し、商品が販売されたときにカウンターを増やし、 _ api _ を介してカウンター値をユーザーに提供します。
この場合Node.jsを使うことを選んだ理由
- とても軽量で速いです。このウェブサイトは3週間で20万回以上のアクセスがあり、最小限のサーバーリソースですべて処理できました。
- カウンターはリアルタイムであるために本当に作るのが簡単です。
- Node.jsは設定が簡単でした。
- 無料で利用できるモジュールがたくさんあります。たとえば、Paypal用のNode.jsモジュールを見つけました。
この場合、Node.jsは素晴らしい選択でした。
Nodeを使用して次のプロジェクトを開始する最も重要な理由...
- すべての最もクールな男はそれに入っている...だからそれは しなければならない 楽しいものにしてください。
- あなたはクーラーでたむろして自慢するべきたくさんのNode冒険を持つことができます。
- クラウドホスティングのコストになると、あなたは気の利いたピンチャーです。
- Railsでそれをやった
- あなたはIIS展開が嫌いです
- あなたの以前のITの仕事はかなり鈍くなっていて、あなたはあなたが光沢のある新しいスタートアップにいたことを願っています。
何を期待します ...
- Expressを使用すれば、サーバーの膨大なソフトウェアを必要とせずに安全で安心できます。
- ロケットのように走り、よくスケールする。
- あなたはそれを夢見ます。あなたはそれをインストールしました。ノードパッケージrepo npmjs.org は、世界最大のオープンソースライブラリのエコシステムです。
- あなたの脳は入れ子になったコールバックの土地で時間が経つでしょう...
- ...あなたが 約束を守ることを学ぶまで 。
- Sequelize および Passport は、あなたの新しいAPIフレンドです。
- ほとんど非同期コードをデバッグすると、umm ... おもしろい になります。
- すべてのNodesがマスターする時間 TypeScript 。
誰が使うの？
- ペイパル、Netflix、ウォルマート、LinkedIn、グルーポン、ユーバー、GoDaddy、Dow Jones
- これが、彼らが ノードに切り替えた理由です 。
Silver Bulletのようなものは何もありません。すべてにはそれに関連するいくらかのコストが伴います。それはあなたが油性食品を食べるのであれば、あなたはあなたの健康を危険にさらすだろうし、健康的な食品は油性食品のようなスパイスが付属していません。彼らが彼らの食物のように健康またはスパイスを望むかどうかは個人の選択です。同様に、Node.jsは特定のシナリオで使用されると見なされます。アプリがそのシナリオに合わない場合は、アプリ開発のために検討するべきではありません。私はちょうど私の考えを同じにしています。
Node.JSを使用する場合
- サーバー側のコードで必要なCPUサイクルが非常に少ない場合。他の世界ではあなたはノンブロッキング操作をしていて、CPUサイクルの多くを消費する重いアルゴリズム/ Jobを持っていません。
- あなたがJavascriptのバックグラウンドから来ていて、クライアントサイドのJSと同じようにシングルスレッドコードを書くのに慣れている場合。
Node.JSを使用しない場合
- サーバー要求は、CPUを大量に消費するアルゴリズム/ Jobに依存しています。
Node.JSでのスケーラビリティの考慮事項
- Node.JS自体は、基盤となるシステムのすべてのコアを利用するのではなく、デフォルトでシングルスレッドです。マルチコアプロセッサを利用してマルチスレッドにするには、独自にロジックを記述する必要があります。
Node.JSの代替案
Node.JSの代わりに使用する他のオプションがありますが、 Vert.x はかなり有望に思われ、polygotやより優れたスケーラビリティの考慮のような追加の機能がたくさんあります。
私が思うに Node.jsについて誰も言及していないことは、すばらしいコミュニティ、パッケージ管理システム（npm）、そして単にそれらをあなたのパッケージに含めることで含めることができるモジュールの量です。 .jsonファイル.
私の作品：nodejsは、アナリティクス、チャットアプリ、API、広告サーバーなどのリアルタイムシステムを作成するのに最適です。地獄、nodejsとsocket.ioを使用して2時間以内に最初のチャットアプリを作成しました。
編集
Nodejsを使い始めてから数年が経ち、静的ファイルサーバー、単純な分析、チャットアプリケーションなど、さまざまなものを作るためにそれを使用しました。これは私がnodejsを使用するときに取ることです
いつ使用するか
並行性とスピードを重視したシステムを作るとき。
- チャットアプリ、IRCアプリなどのソケット専用サーバー.
- 地理位置情報、ビデオストリーム、オーディオストリームなどのリアルタイムリソースを重視するソーシャルネットワーク.
- アナリティクスWebアプリケーションのように、小さなデータを非常に高速に処理できます。
- RESTのみapiを公開しています。
使わないとき
その非常に用途の広いWebサーバなので、どこでも好きなところで使用できますが、おそらくこれらの場所では使用できません。
- 簡単なブログと静的サイト。
- 静的ファイルサーバーと同じです。
私はただ痴漢しているだけだということを心に留めておいてください。静的ファイルサーバーの場合、Apacheは広く利用可能であるという理由で主に優れています。 nodejsコミュニティは何年にもわたって大きく成長し、成熟してきました。ホスティングを自分で選択すれば、nodejsをほぼあらゆる場所で使用できると言っても安全です。
それはどこでも使用することができます
- 非常にイベント駆動型で、I/Oに強く依存しているアプリケーション
- 他のシステムへの多数の接続を処理するアプリケーション
- リアルタイムアプリケーション（Node.jsはリアルタイムで使いやすくなるようにゼロから設計されました。）
- 他のソースとの間で送受信される大量の情報をジャグリングするアプリケーション
- 高トラフィック、スケーラブルなアプリケーション
- 多くのデータ分析を行うことなく、プラットフォームのAPIおよびデータベースと通信する必要があるモバイルアプリ
- ネットワークアプリケーションを構築する
- バックエンドと頻繁に会話する必要があるアプリケーション
モバイルの面では、プライムタイム企業はモバイルソリューションをNode.jsに頼ってきました。 その理由を調べてください。
LinkedIn は著名なユーザーです。それらのモバイルスタック全体はNode.js上に構築されています。各物理マシンに15のインスタンスを持つ15のサーバーを実行していたのが4つのインスタンスになりました。これで2倍のトラフィックを処理できます。
eBay はHTTP API用のWebクエリ言語であるql.ioを起動しました。これはランタイムスタックとしてNode.jsを使用します。彼らは1つのnode.jsプロセスあたり120,000以上のアクティブな接続を処理するために、通常の開発者品質のUbuntuワークステーションを調整することができました。
Walmart はNode.jsを使用するようにモバイルアプリを再設計し、JavaScript処理をサーバーにプッシュしました。
で詳細を読む： http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/
それでは、ストーリーから始めましょう。過去2年間、私はJavaScriptの開発とWebフロントエンドの開発をしていて、楽しんでいます。バックエンドの人たちは私たちにJavaやpythonで書かれたAPIを提供しています（私たちは気にしません）。そして単に[AJAX呼び出しを書いてデータを取得して何を推測します！これで終わりです。しかし、実際にはそれほど簡単ではありません。取得しているデータが正しくない場合、またはサーバーエラーが発生している場合は、メールやチャットでバックエンドの担当者に連絡する必要があります（whatsAppもあります）。かっこよくないです。 APIをJavaScriptで記述し、それらのAPIをフロントエンドから呼び出すとどうなりますか。はい、APIで問題が発生した場合はそれを調べることができるので、かなりクールです。何だと思う ！あなたは今これをすることができます、どうですか？ - ノードはあなたのためにあります。
OkはあなたがあなたのAPIをJavaScriptで書くことができることに同意しました、しかしもし私が上の問題で大丈夫ならばどうでしょうか。 rest APIにnodeを使用する他の理由はありますか？
これが魔法の始まりです。はい、私たちのAPIにnodeを使う理由は他にもあります。
ブロッキング操作またはスレッド化のいずれかに基づく、従来の残りのAPIシステムに戻りましょう。 2つの同時要求が発生すると（r1とr2）、それぞれデータベース操作が必要になります。だから伝統的なシステムでは何が起こるでしょう：
1.待機中の方法： 私たちのサーバーはr1リクエストの処理を開始し、クエリの応答を待ちます。 r1の完了後、サーバーはr2の提供を開始し、それを同じ方法で実行します。それほど時間がないので、待つのはお勧めできません。
2.スレッディング方法： 私達のサーバーはリクエストr1とr2の両方のために二つのスレッドを作成し、データベースに問い合わせた後それらの目的を果たすのでとても速く冷却します。両方の要求が同じデータを照会しているときに増加する場合は、デッドロックのような問題に対処する必要があります。だから待っているよりはましだが、それでも問題はある。
今ここに、ノードがそれをする方法があります：
3. Nodeway： nodeで同じ同時リクエストが来た場合、そのコールバックにイベントを登録して先に進み、特定のリクエストに対するクエリの応答を待ちません。したがって、r1リクエストが来たらノードのイベントループ（はい、この目的にかなうノードにイベントループがあります。）イベントをそのコールバック関数に登録し、r2要求を処理するために先に進み、同様にそのイベントをそのコールバックに登録します。クエリが終了するたびに、対応するイベントがトリガされ、中断されることなくコールバックが完了するまで実行されます。
それで、待つことも、スレッドを作ることも、メモリを消費することもありません - はい、これは残りのAPIを提供するためのノードウェイです。
私の もう一つの理由 新しいプロジェクトにNode.jsを選ぶ理由は：
純粋なクラウドベースの開発ができる
私は Cloud9 IDE をしばらく使ってきましたが、今はそれなしでは想像できませんが、すべての開発ライフサイクルを網羅しています。必要なのはブラウザだけで、いつでもどこでもどんなデバイスでもコーディングできます。自宅のように1台のコンピュータでコードをチェックインしてから（職場のように）別のコンピュータでチェックアウトする必要はありません。
もちろん、他の言語やプラットフォーム用にクラウドベースのIDEがあるかもしれません（Cloud 9 IDEは他の言語のサポートも追加しています）、私にとって本当に素晴らしい経験です。
Nodeが提供するもう1つのことは、ノードの子プロセス（ childProcess.fork（） docごとに10mbのメモリを必要とする）を使用してノードのv8インスタンスを複数作成できることです。 。そのため、大きなサーバー負荷を必要とするバックグラウンドジョブをオフロードするのは簡単ではなく、必要に応じていつでも簡単に削除できます。
私は頻繁にノードを使用しており、私たちが構築するほとんどのアプリでは、同時にサーバー接続を必要としているため、ネットワークトラフィックが非常に多くなっています。 Express.js や新しい Koajs （コールバック地獄を削除した）のようなフレームワークはノードでの作業をさらに簡単にしました。
アスベストのロングジョンズを...
昨日、Packt Publicationsでの私のタイトル JavaScriptによるリアクティブプログラミング 。これは実際にはNode.js中心のタイトルではありません。初期の章は理論をカバーすることを意図しており、後のコードが重い章は実践をカバーしています。読者にウェブサーバーを提供するのに失敗することは本当に適切だとは思わなかったので、Node.jsははるかに明らかな選択。ケースは開かれる前に閉じられました。
Node.jsでの私の経験について非常にバラ色の見方をすることができました。代わりに、私が遭遇した良い点と悪い点について正直でした。
ここに関連するいくつかの引用を含めてみましょう。
警告：Node.jsとそのエコシステムはhot-あなたをひどく火傷させるほど熱い！
私が数学の教師のアシスタントだったとき、私が言われた非自明な提案の一つは、何かを「簡単」だと生徒に言わないことでした。問題を解決する方法が得られないだけでなく、理解できないほど愚かな問題は簡単なものであるため、解決策が（さらに）愚かに感じるかもしれません！
Python/Djangoから来ている人を困らせるだけでなく、何かを変更するとすぐにソースがリロードされるという落とし穴があります。 Node.jsのデフォルトの動作では、1つの変更を行うと、時間の終わりまで、またはサーバーを手動で停止して再起動するまで、古いバージョンが引き続きアクティブになります。この不適切な動作は、Pythonistaを悩ますだけではありません。また、さまざまな回避策を提供するネイティブNode.jsユーザーを苛立たせます。 StackOverflowの質問「Node.jsでのファイルの自動リロード」には、この記事の執筆時点で200を超える賛成票と19の回答があります。編集により、ユーザーは http://tinyurl.com/reactjs-node-supervisor にあるホームページで、nannyスクリプトのnode-supervisorに誘導されます。この問題は、新しいユーザーが問題を修正したと思ったために愚かさを感じる絶好の機会を与えますが、古いバグのある動作は完全に変更されていません。また、サーバーをバウンスすることを忘れがちです。私は何度もそうしました。そして、私が伝えたいメッセージは、「いいえ、あなたは愚かではありません。Node.jsのこの振る舞いがあなたの背中をかみます。 Node.jsの設計者がここで適切な動作を提供する理由を見つけられなかったというだけです。おそらくノードスーパーバイザーや他のソリューションから少し助けを借りてそれに対処しようとしますが、あなたが愚かだと感じて立ち去らないでください。あなたは問題を抱えている人ではありません。問題はNode.jsのデフォルトの動作にあります。」
このセクションは、「簡単だ」という印象を与えたくないという理由で、議論の末に残されました。仕事をする間、何度も手を切って、困難を乗り越えたくありません。 Node.jsとそのエコシステムを適切に機能させることは簡単なことであると信じるように設定します。それがあなたにとっても簡単でない場合は、何をしているのかわかりません。 Node.jsを使用して不快な問題に遭遇しない場合、それは素晴らしいことです。もしそうなら、「私は愚かだ-私には何か間違っているに違いない」と感じて、あなたが逃げないことを願っています。あなたじゃない！ Node.jsとそのエコシステムです！
最後の章でのクレッシェンドの上昇と結論の後に私が本当に欲しくない付録は、生態系で私が見つけることができたものについて語り、モロニックなリテラルの回避策を提供しました：
完全に適合しているように思われ、まだ引き換え可能な可能性のある別のデータベースは、HTML5キー値ストアのサーバー側の実装です。このアプローチには、ほとんどの優秀なフロントエンド開発者が十分に理解しているAPIの基本的な利点があります。さらに言えば、それはあまり良くないフロントエンド開発者が十分に理解しているAPIでもあります。ただし、node-localstorageパッケージでは、辞書構文アクセスは提供されませんが（localStorage [key]ではなくlocalStorage.setItem（key、value）またはlocalStorage.getItem（key）を使用したい）、完全なlocalStorageセマンティクスが実装されます、デフォルトの5MBクォータを含む—WHY？サーバー側のJavaScript開発者は自分から保護する必要がありますか？
クライアント側のデータベース機能の場合、Webサイトごとに5MBのクォータは、開発者がそれを操作できるようにするための非常に寛大で便利な余裕のあるスペースです。はるかに低いクォータを設定しても、Cookieの管理とともに、リンピングよりもはるかに大きな改善を開発者に提供できます。 5MBの制限は、ビッグデータのクライアント側の処理にはあまり適していませんが、リソースの豊富な開発者が多くのことを行うために使用できる非常に寛大な余裕があります。しかし、一方で、5MBは最近購入されたほとんどのディスクの特に大きな部分ではありません。つまり、あなたとWebサイトがディスクスペースの合理的な使用法について意見が合わない場合、または一部のサイトが単純にぎこちない場合、実際にはコストがかかりませんハードドライブが既にいっぱいになっていない限り、ハードドライブが圧迫される危険はありません。バランスが少々または少々多ければ良いかもしれませんが、全体としては、クライアント側のコンテキストに内在する緊張に対処するための適切なソリューションです。
ただし、サーバーのコードを記述しているのは、データベースを許容可能な5 MBを超えるサイズにすることから保護を追加する必要はないということです。ほとんどの開発者は、乳母として機能するツールを必要とせず、5MBを超えるサーバー側データの保存からツールを保護しません。また、クライアント側でのゴールデンバランスの行為である5MBのクォータは、Node.jsサーバーではかなりばかげています。 （そして、この付録に記載されているような複数のユーザー向けのデータベースについては、ユーザーアカウントごとにディスク上に個別のデータベースを作成しない限り、ユーザーアカウントごとに5MBではなく、5MBすべてのユーザーアカウントをまとめます。painfulあなたがバイラルになったら！）ドキュメントにはクォータがカスタマイズ可能であると記載されていますが、同じ質問をするStackOverflowの質問でした。私が見つけることができた唯一の答えは、Github CoffeeScriptソースにあり、コンストラクターのオプションの2番目の整数引数としてリストされています。そのため、これは非常に簡単で、ディスクまたはパーティションサイズに等しいクォータを指定できます。しかし、意味のない機能の移植に加えて、ツールの作成者は、整数が何らかのリソース使用の最大制限を指定する変数または関数の「無制限」を意味する0を解釈するという非常に標準的な慣習に従わなかった。この誤機能を解決する最善の方法は、クォータがInfinityであることを指定することです。
if (typeof localStorage === 'undefined' || localStorage === null)
{
var LocalStorage = require('node-localstorage').LocalStorage;
localStorage = new LocalStorage(__dirname + '/localStorage',
Infinity);
}
2つのコメントを順番に入れ替える：
人々はJavaScriptを全体として絶えず足で撃ちました。JavaScriptが立派な言語になっているのは、ダグラス・クロックフォードが本質的に言ったものです。「言語としてのJavaScriptには、本当に良い部分と悪い部分があります。ここに良い部分があります。おそらく、熱いNode.jsエコシステムは、そのown「Douglas Crockford」を成長させるでしょう。 .jsエコシステムはコーディングワイルドウェストですが、いくつかの実際の宝石が見つかります。これがロードマップです。ほぼすべてのコストで回避すべき領域を以下に示します。これは、あらゆる言語や環境で見られる最も豊かなペイダートのあるエリアです。」
おそらく他の誰かがこれらの言葉を挑戦として受け止め、Crockfordのリードに従って、Node.jsとそのエコシステムの「良い部分」や「良い部分」を書き上げることができます。コピーを買います！
そして、すべてのプロジェクトに対する熱意と純粋な労働時間を考えると、この執筆時点で行われた未熟な生態系についての発言を鋭く抑えるために、1、2、3年で保証されるかもしれません。 5年後には、「2015 Node.jsエコシステムにはいくつかの地雷原がありました。 2020 Node.jsエコシステムには複数の楽園があります。」
あなたのアプリケーションが主にWeb APIや他のIOチャンネルを繋いでいる場合、ユーザインタフェースを提供したり取ったりするなら、node.jsはあなたにとっては最適な選択かもしれません。 javascript（またはある種のjavascript transpilers）です。マイクロサービスを構築する場合は、node.jsでも構いません。 Node.jsは、小規模または単純なプロジェクトにも適しています。
その主なセールスポイントは、フロントエンドが典型的な格差ではなくバックエンドのものを担当できるようにすることです。もう1つの正当なセールスポイントは、あなたの従業員が最初からJavaScript指向のものであるかどうかです。
ただし、ある点を超えて、モジュール性、読みやすさ、およびフロー制御を強制するためのひどいハックがなければ、コードを拡張することはできません。しかし、これらのハックを好む人もいますが、特にイベント駆動型のJavaScriptの背景から来たもので、慣れ親しんでいる、または許しがたいようです。
特に、アプリケーションで同期フローを実行する必要がある場合は、開発プロセスの面でかなり時間がかかるハーフベイクソリューションを使用しています。アプリケーションに計算集約的な部分がある場合は、慎重にnode.jsを選択してください。多分 http://koajs.com/ または他の目新しさが、もともとnode.jsを使用したか、またはこれを書いたときと比較して、もともと厄介な側面を軽減します。