javascript - 複数 - Node.jsの使用方法を決定する方法




nodejs 定数ファイル (12)

私はこの種のものを初めて使っていますが、最近はNode.js良さについて多くのことを聞いてきました。 jQueryとJavaScriptの一般的な使い方をどれだけ愛しているかを考えてみると、Node.jsをいつ使うべきかを決める方法はわかりません。 私が念頭に置いているWebアプリケーションは、 Bitlyようなものです。コンテンツを取り込んでアーカイブします。

ここ数日で私がやってきたすべての宿題から、私は以下の情報を得ました。 Node.js

  • は、通常のWebサーバーとして実行できるコマンドラインツールで、JavaScriptプログラムを実行できます
  • 偉大なV8 JavaScriptエンジンを利用する
  • あなたが同時にいくつかのことをする必要があるときはとても良いです
  • イベントベースなので、素晴らしいAjaxようなものはすべてサーバー側で実行できます
  • ブラウザとバックエンドの間でコードを共有できます
  • 私たちはMySQLと話すことができます

私が出会った情報源には次のものがあります:

AmazonのEC2インスタンスでNode.jsをほぼすぐに使用できることを考慮して、 PHPPythonRubyような巨大な王たちの代わりにNode.jsが必要な問題の種類を理解しようとしています。 私はそれが本当に言語に関する専門知識に依存していることを理解していますが、私の質問は一般的なカテゴリーになります。特定のフレームワークを使用するタイミングと、それに適したタイプのタイプ


  1. ノードは素早いプロトタイプのためには素晴らしいですが、私は何か複雑なものに使うことはありません。私はコンパイラとの関係を開発するのに20年を費やしました。

  2. ノードは、あなたがしばらく訪問していないコードを維持するのに特に苦痛です。型情報とコンパイル時エラー検出は良いものです。なぜそれをすべて投げ捨てるのですか?何のために? とダング、何かが南に行くとスタックトレースは非常にしばしば完全に役に立たない。


Node.jsは、オンラインゲーム、コラボレーションツール、チャットルームなど、リアルタイムアプリケーションに最も適していると信じています。アプリケーションを使用しているユーザ(またはロボットやセンサ)が他のユーザに直ちに見られる必要がある場所、ページをリフレッシュせずに。

また、Socket.IOとNode.jsを組み合わせると、長いポーリングで可能なものよりもリアルタイムの待ち時間が短縮されることにも言及しておく必要があります。 Socket.IOは、最悪の場合のシナリオとして長いポーリングに戻り、代わりにWebソケットやFlashが利用可能であれば使用します。

しかし、スレッドによってコードがブロックされる可能性がある状況については、Node.jsでより適切に対処できます。 アプリケーションをイベント駆動型にする必要がある場合

また、Ryan Dahl氏は、Node.jsのベンチマークではNginxによく似た、古いHTTPリクエストがあると話していました。 したがって、Node.jsを使用して構築すれば、通常のリソースを非常に効果的に提供することができます。イベント駆動型のものが必要な場合は、それを処理する準備が整いました。

それは常にJavaScriptです。 リンガフランカ全体のスタック。


NodeJSを使用する理由:

  • Javascriptを実行するので、サーバーとクライアントで同じ言語を使用できます。フォーム間のコードを共有することもできます(フォームの検証や両端のビューのレンダリングなど)。

  • single-threadedイベントドリブンシステムは、従来のマルチスレッドJavaまたはRORフレームワークと比べて、一度に多くの要求を処理する場合でもfastであり、シンプルでもあります。

  • NPM介してアクセス可能な 、クライアントおよびサーバー側のライブラリ/モジュール、Web開発用のコマンドラインツールなど、 packages盛りだくさんになっています。 これらのほとんどは便利なgithubでホストされています。時には問題を報告し、数時間以内に修正されることがあります。 標準化された問題の報告と簡単なフォークを含めて、すべてを屋根の下に置くことはいいことです。

  • Javascript関連のツールや、タスクランナー、ミニファイア、美化器、リンター、プリプロセッサ、バンドル、アナリティクスプロセッサなどのWeb 関連のツールを実行するための標準的な環境となっています。

  • プロトタイピング、アジャイル開発、 迅速な製品反復には適しているようです。

NodeJSを使用しない理由:

  • Javascriptを実行しますが、コンパイル時の型チェックはありません。 大規模で複雑な安全性が重要なシステムや、異なる組織間の共同作業を含むプロジェクトでは、 契約インタフェースを奨励し、 静的な型チェックを提供する言語は、長期的にはデバッグ時間(および爆発 )を節約します。 (JVMはnullで固まっていnull 、原子炉にはHaskellを使用してください)。

  • これに加えて、NPMのパッケージの多くは未加工で、まだまだ急速に発展しています。 古いフレームワーク用のライブラリの中には、10年にわたるテストとバグ修正が行われており、現在では非常に安定しています。 Npmjs.orgにはパッケージを評価する仕組みがないため、多かれ少なかれ同じことをしているパッケージが増えており、その中で大きな割合はもはや維持されていません。

  • ネストされたコールバック地獄。 (もちろん、これには20種類の解決策があります...)

  • ますます増え続けるパッケージのプールは、1つのNodeJSプロジェクトを次のプロジェクトとは根本的に異なるよう見せることができます。 利用可能なオプションが非常に多いため(例:Express / Sails.js / Meteor / Derby )、実装には大きな多様性があります。 これにより、新しい開発者がNodeプロジェクトに参入するのが難しくなることがあります。 既存のプロジェクトに加わっているRails開発者とは対照です。すべてのRailsアプリケーションが同様の構造を使用するように勧められているので、彼はこのアプリをかなり素早く知ることができます。

  • ファイルを扱うことはちょっと苦しいことがあります。 テキストファイルから行を読み込むような、他の言語では簡単なことは、Node.jsに 80以上のupvotesを持つの質問があるのには奇妙です。 CSVファイルから一度に1つのレコードを読み込む簡単な方法はありません 。 等。

私はNodeJSが大好きですが、速くて野生で楽しいですが、証明可能な正確性にはほとんど関心がないと心配しています。 最終的に両方の世界のベストを融合させることを望みましょう。 私は将来どのようなNodeを置き換えるかを見たいと思っています:)


同時リクエスト処理に最適なノード -

だから、話を始めましょう。 私は過去2年間、JavaScriptとWebフロントエンドの開発に取り組んでおり、私はそれを楽しんでいます。 バックエンドの人は私たちのAPIをJava、Python(私たちは気にしない)で書いており、単にAJAX呼び出しを記述し、データを取得して何を推測するのですか? 私たちは完了です。 しかし実際にはそれは簡単ではありません。データが正しくない場合やサーバーエラーがある場合、私たちは立ち往生し、メールやチャットでバックエンドの人たちに連絡しなければなりません。クールではない。 APIでJavaScriptを記述し、そのAPIをフロントエンドから呼び出すとどうなりますか? はい、それはかなりクールです。なぜなら、APIの問題に直面したら、それを調べることができるからです。 何だと思う ! あなたは今これを行うことができます、どのように? - あなたのためのノードがあります。

OKはあなたのAPIをJavaScriptで書くことに同意しましたが、もし私が上記の問題で大丈夫ならばどうしますか? あなたは休憩APIのためのノードを使用する他の理由がありますか?

ここで魔法が始まります。 はい、私は私たちのAPIのためのノードを使用する他の理由があります。

ブロッキング操作またはスレッディングのいずれかに基づいた従来の残りのAPIシステムに戻りましょう。 2つの同時要求(r1とr2)が発生し、それぞれにデータベース操作が必要であるとします。 だから伝統的なシステムで何が起こるか:

1.ウェイティング・ウェイ:私たちのサーバーはr1リクエストの提供を開始し、クエリ応答を待ちます。 r1完了後、サーバはr2を提供し始め、同じ方法でそれを行います。 だから私たちはあまり時間がないので、待っていることは良い考えではありません。

2. Threading Way:私たちのサーバは、リクエストr1r2両方に2つのスレッドを作成し、データベースをクエリした後にその目的を果たします。その結果、両方のリクエストがクエリしているときに2つのスレッドを開始することがわかります。同じデータでは、デッドロックの問題に対処する必要があります。 だから待っているよりも良いが、それでも問題はある。

ここでは、ノードがどのようにそれを行うのですか?

3. Nodeway:同じ並行要求がノードに来ると、そのコールバックにイベントを登録し、特定の要求に対するクエリ応答を待つことはありません。したがって、 r1要求が来たらノードのイベントループ(はい、イベントがあります)この目的を果たすノード内のループ)。そのコールバック関数でイベントを登録し、 r2要求を処理するために先に進み、そのイベントをそのコールバックに同様に登録する。 クエリが終了するたびに、対応するイベントがトリガされ、中断されることなくそのコールバックを完了まで実行します。

待ち時間なし、スレッディングなし、メモリ消費なし - これは残りのAPIを提供するためのノードウェイです。


アスベストロングジョーンズを寄付する...

昨日のPackt Publicationsの私のタイトル、JavaScriptによる反応的プログラミング 。 これはNode.js中心のタイトルではありません。 初期の章は理論をカバーすることを意図しており、後にコードが重い章は実践をカバーしています。 読者にウェブサーバーを提供しないことが妥当ではないと私は本当に考えなかったので、Node.jsははるかに明らかな選択肢でした。 事件は開かれる前に閉鎖されていた。

私はNode.jsで私の経験を非常にバラ色に見せてくれました。 代わりに、私は遭遇した良い点と悪い点について正直でした。

ここで関連するいくつかの引用符を含めてみましょう:

警告:Node.jsとそのエコシステムは熱くなっています。

私が教師の助手だったとき、私が聞かれた非自明な提案の1つは、学生に何かが「簡単」であると言うことではありませんでした。彼らは問題を解決する方法を得られないだけでなく、彼らが理解するにはあまりにも愚かな問題は簡単なものなので、解決策が(さらに)愚かな感じに終わるかもしれません!

Python / Djangoから来ている人々に迷惑をかけるだけでなく、何かを変更した場合にソースを直ちに読み込んでしまうような問題があります。 Node.jsでは、デフォルトの動作として、1回の変更を行った場合、古いバージョンは、時間の終了時まで、またはサーバーを手動で停止して再起動するまで、引き続きアクティブになります。 この不適切な振る舞いは、Pythonistasを悩ますだけではありません。 また、さまざまな回避策を提供するネイティブNode.jsユーザーを苛立たせます。 の質問 "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を扱う厄介な驚きを経験するなら、あなたはばかげているわけではありません。 それはあなたではありません! それはNode.jsとそのエコシステムです!

最後の章で上昇するクレッシェンドと結論の後に私が本当に望んでいなかった付録は、私が生態系で見つけたことについて話し、馬鹿なリテラリズムの回避策を提供しました:

完璧にフィットしていて、まだ償還可能なデータベースは、HTML5のKey-Valueストアのサーバーサイド実装です。 このアプローチは、大部分の優れたフロントエンド開発者が十分に理解しているAPIの重要な利点を持っています。 その点では、フロントエンドの開発者にとってはあまりよくないことを理解しているAPIのほとんどです。 しかし、node-localstorageパッケージでは、辞書構文アクセスが提供されていない(localStorage [key]ではなく)localStorage.setItem(key、value)またはlocalStorage.getItem(key)を使用したいが、完全なlocalStorageセマンティクスが実装されているデフォルトの5MBのクォータを含む サーバー側のJavaScript開発者は、自分自身から保護する必要がありますか?

クライアント側のデータベース機能では、ウェブサイトあたり5MBのクォータが、実際には開発者が作業できるようにするための息をのむほどの息遣いです。 はるかに低いクォータを設定することができ、クッキー管理と一緒にやりとりすることより、計り知れない改善を開発者に提供することができます。 5MBの制限は、ビッグデータのクライアント側の処理には非常に迅速には向いていませんが、人手を必要とする開発者が多くのことを行うためにはかなり寛大です。 しかし一方で、5MBは最近購入されたほとんどのディスクの中で特に大きな部分ではありません。つまり、あなたとウェブサイトがディスクスペースの合理的な使用について何か意見が違う場合、またはサイトが単純に大雑把なものであれば、あなたのハードドライブがすでに満杯になっていない限り、あなたはあまりにも多くのハードドライブの危険にさらされていません。 残高が多かれ少なかれ少なければ、より良い結果が得られるかもしれませんが、全体的には、クライアント側の文脈に対する本質的な緊張に対処するためのまともな解決策です。

しかし、サーバー用のコードを書くときには、データベースを5MB以上の容量にするという追加の保護は必要ありません。 ほとんどの開発者は、乳母のように機能するツールを必要とせず、5MBを超えるサーバー側のデータを保存しないようにするツールも必要としません。 そして、クライアントサイドでのゴールデンバランシング行為である5MBのクォータは、Node.jsサーバではちょっとばかげています。 (そして、この付録で扱うような複数のユーザー用のデータベースでは、各ユーザーアカウントごとにディスク上にデータベースを作成しない限り、ユーザーアカウントごとに5MBではなく、若干痛いことが指摘されるかもしれません。すべてのユーザアカウントが一緒になっている場合はウィルスになる可能性があります)。ドキュメントにはクォータがカスタマイズ可能であると書かれていますが、一週間前にクォータを変更する方法を尋ねる電子メールは、の質問。 私が見つけることができた唯一の答えは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の部分は、ダグラス・クロックフォード(Douglas Crockford)という言葉で言いました。「JavaScriptは本当に良い部分と本当に悪い部分があります。 ここに良い部分があります。 おそらくホットなNode.jsエコシステムは独自の 「Douglas Crockford」を成長させるでしょう。「Node.jsエコシステムはコードワイルドウエストですが、見つかる本当の宝石がいくつかあります。 ここにロードマップがあります。 ほとんどの費用を避けるべき分野は次のとおりです。 ここでは、あらゆる言語や環境で最も豊かなペイダートの領域があります。

多分、他の誰かがその言葉を挑戦として取り上げ、Crockfordのリードに続き、Node.jsとそのエコシステムの「良い部分」や「より良い部分」を書くことができます。 私はコピーを買うだろう!

すべてのプロジェクトの熱意と勤勉さの度合いを考えれば、この文書の執筆時点で未成熟の生態系についての発言を大幅に緩和するには、1年、2〜3年で保証されるかもしれません。5年後には、「2015年のNode.jsエコシステムにはいくつかの地雷がありました。2020年のNode.jsエコシステムには複数のパラダイムがあります。


あなたはNode.jsについて素晴らしいことを要約する素晴らしい仕事をしました。 私の感想は、Node.jsは、ブラウザからサーバーへの永続的な接続を維持したいアプリケーションに特に適しているということです。 "long-polling"と呼ばれる手法を使用すると、ユーザーに更新情報をリアルタイムで送信するアプリケーションを作成できます。 Ruby on RailsDjangoようなWebの巨人の多くで長いポーリングを行うと、各アクティブなクライアントが1つのサーバプロセスを食べるため、サーバに膨大な負荷がかかります。 この状況は、 tarpit攻撃になります。 Node.jsのようなものを使用すると、サーバーは開いている接続ごとに別々のスレッドを維持する必要はありません。

つまり、Node.jsにブラウザベースのチャットアプリケーションを作成して、非常に多くのクライアントにサービスするシステムリソースをほとんど必要としないようにすることができます。 このような長いポーリングをしたいときはいつでも、Node.jsは素晴らしいオプションです。

RubyとPythonの両方には、このようなことを行うためのツール(それぞれeventmachinetwisted )がありますが、Node.jsは例外的にうまくやっています。 JavaScriptは、例外的にコールバックベースの並行処理モデルに適しており、ここでは優れています。 また、クライアントとサーバーの両方にJSONネイティブを使用してシリアライズしてデシリアライズすることもかなり面白いです。

私はここで他の答えを読むことを楽しみにしています、これは素晴らしい質問です。

Node.jsは、クライアント/サーバーのギャップを超えて多くのコードを再利用する状況にも適していることを指摘する価値があります。 Meteorのフレームワークはこれを本当に簡単にしてくれています。多くの人々が、これがWeb開発の未来の可能性を示唆しています。 経験から、Meteorでコードを記述するのは非常に面白いと言うことができます。その大部分は、データをどのように再構成するかを考える時間が少なくて済むので、ブラウザで実行されるコードは簡単に実行できますそれを操作して戻してください。

ここにピラミッドとロングポーリングの記事があります。これは、geentの小さな助けを借りてセットアップが非常に簡単であることが判明しました: TicTacToeとLong Polling with Pyramid


それを短くするには:

Node.jsは、多数の同時接続を持つアプリケーションに適しており、イベントループ(他のすべてのクライアント)は関数の実行中にブロックされるため、各要求に必要なCPUサイクルはわずかです。

Node.jsのイベントループについての良い記事は、 Mixuの技術ブログ、node.jsイベントループの理解です。


シルバーブレットのようなものはありません。 すべてには、それに関連した費用がかかります。 それはあなたが油性食品を食べるようなものです、あなたの健康を傷つけ、健康食品は油性食品のような香辛料が付いていません。 彼らが自分の食物のように健康やスパイスを必要とするかどうかは、個人の選択です。 特定のシナリオでNode.jsが使用されるのと同じ方法です。 あなたのアプリがそのシナリオに適合しない場合は、あなたのアプリ開発のためにそれを考慮すべきではありません。 私は同じ考えをしているだけです。

Node.JSを使用する場合

  1. あなたのサーバー側のコードが非常に少ないCPUサイクルを必要とする場合。 他の世界では、非ブロッキング操作をしており、CPUサイクルを大量に消費する重いアルゴリズム/ジョブはありません。
  2. Javascriptのバックグラウンドで、クライアント側のJSと同様にSingle Threadedコードを書くのが快適であれば。

Node.JSを使用しない場合

  1. サーバー要求は、CPU使用量の多いアルゴリズム/ジョブに依存します。

Node.JSによるスケーラビリティの考慮

  1. Node.JS自体は、基礎となるシステムのすべてのコアを利用せず、デフォルトではシングルスレッドであるため、独自にロジックを記述してマルチコアプロセッサを利用しマルチスレッド化する必要があります。

Node.JSの代替

Node.JSの代わりに他のオプションを使用することもできますが、 Vert.xはかなり有望で、ポリゴットやスケーラビリティの考慮事項などの追加機能がたくさんあります。


ノードを使用して次のプロジェクトを開始する最も重要な理由...

  • すべての最もクールな人たちがそれに入っているので、それ楽しいはずです。
  • あなたはクーラーでハングアウトを楽しむことができ、多くのノードの冒険で自慢できます。
  • ホスティングコストをクラウドにするには、ペニーピンジャーです。
  • そこではRailsを使って
  • IIS展開を嫌う
  • あなたの古いIT仕事はむしろ鈍っていて、あなたは輝く新しいスタートアップにいたいと思っています。

何を期待します ...

  • あなたが必要としていないサーバーの膨大な機能がなくても、Expressを使用すると安全で安全です。
  • ロケットのように走り、よく伸びます。
  • あなたはそれを夢見る。 あなたはそれをインストールしました。 ノードパッケージリポジトリpackagesは、世界のオープンソースライブラリの中で最大のエコシステムです。
  • あなたの脳は、ネストされたコールバックの土地で時間を浪費します...
  • あなたのPromisesを守ることを学ぶまで。
  • SequelizePassportはあなたの新しいAPIの友人です。
  • ほとんどの非同期コードをデバッグすると興味深いものが得られます。
  • すべてのNodersがTypescriptをマスターする時間。

誰がそれを使用しますか?

  • PayPal、Netflix、Walmart、LinkedIn、Groupon、Uber、GoDaddy、ダウ・ジョーンズ
  • ここで彼らはノード切り替えたのです。

新しいプロジェクトでNode.jsを選択するもう一つの理由は次のとおりです。

純粋なクラウドベースの開発を行うことができる

私はCloud9 IDEをしばらく使用しましたが、今ではそれがなくても想像がつきません。すべての開発ライフサイクルを網羅しています。 必要なのはブラウザだけで、いつでもどこでもどのデバイスでもコーディングできます。 あるコンピュータ(自宅など)でコードをチェックインする必要はなく、別のコンピュータ(職場など)でチェックアウトする必要はありません。

もちろん、他の言語やプラットフォーム用のクラウドベースのIDE(クラウド9 IDEにも他の言語のサポートが追加されています)がありますが、クラウド9を使用してNode.jsの開発を行うのは本当に素晴らしい経験です。


私は、ノードjをどこで使用するのかを、いくつの点で分かち合うことができます。

  1. チャット、共同編集などのリアルタイムアプリケーションの場合は、nodejsをイベントベースとして使用し、サーバーからクライアントにイベントやデータを送信します。
  2. ほとんどの人がアイデアを持っているjavascriptベースであるため、シンプルでわかりやすい。
  3. 現在のWebアプリケーションのほとんどは、jsonとバックボーンに向かっています。ノードでは、両方ともjsonデータを使用するため、クライアント側のコードと対話するのは簡単です。
  4. 多くのプラグインを利用できます。

欠点: -

  1. Nodeはほとんどのデータベースをサポートしますが、複雑な結合などをサポートしないmongodbが最適です。
  2. コンパイルエラー...開発者は、エラーアコーディオンアプリケーションが動作しなくなった場合には、他のすべての例外を処理しなければなりません。

結論: - Nodejsは、シンプルでリアルタイムのアプリケーションに最適です。ビジネスロジックが非常に大きく、複雑な機能を持っていればnodejを使用しない方がいいでしょう。チャットやその他の共同作業機能とともにアプリケーションを構築したい場合は、ノードを特定の部分で使用することができます。


あなたのアプリケーションが主にウェブAPIや他のioチャンネルをつなぎ、ユーザーインターフェースを提供したり受けたりする場合、特にスケーラビリティを絞りたい場合はnode.jsが適しているかもしれません。 javascript(またはjavascriptの種類のソフトウェア)です。マイクロサービスを構築する場合、node.jsも大丈夫です。Node.jsは、小さくて単純なプロジェクトにも適しています。

その主なセールスポイントは、フロントエンドが、典型的な分割ではなく、バックエンドのものに責任を負うことができるということです。もう一つの正当なセールスポイントは、あなたの労働力がjavascript指向のものであるかどうかです。

しかし、ある点を越えて、モジュール性、可読性、およびフロー制御を強制するためのひどいハックなしにコードを拡張することはできません。これらのハックを好む人もいれば、特にイベント主導のjavascriptのバックグラウンドから来ている人は、よく知っているか許しがたいようです。

特に、アプリケーションが同期フローを実行する必要がある場合、ハーフベークされたソリューションよりも出血が始まり、開発プロセスの面でかなり遅くなります。アプリケーションに計算集中的な部品がある場合は、node.jsを慎重に選んで歩いてください。おそらく、最初にnode.jsを使用したときや、これを書いたときと比べて、Koajsやその他のノベルティは、元々厄介なものを軽減してくれます。







web-applications