Node.jsの問題点、デメリットと解決方法まとめ

引用元:

http://qiita.com/hshimo/items/156249ec8e6dbf75205a

• hshimoが2013/11/03にKobitoから投稿(2015/06/06に編集)
 
• 編集履歴(11)

技術選定のためや、俺が問題解決するぜっ!的な人向け。

順次解決されると思うので、順次更新します。
以下に上げたものも、解決策があるものが多いです。

はじめてのNode.js (2013年3月26日初版)

• どこか1か所CPUリソースを多く消費するような重い処理が入ると、全体のパフォーマンスが低下する
• マルチコア/マルチCPU環境を十分に生かすことができない 
• コールバックを多用するためにコードが複雑になる

merittyの記事 (2012年12年23日)

Node.jsのメリットとデメリット | meritty [メリッティ]

• JavaScriptの限界、オブジェクト指向が不完全
• マルチコアサーバで性能を十分に発揮できない
• 文法エラーが、サーバーの停止を引き起こす
• あるリクエストに問題があると、他のリクエストをブロックする

ZEALOT社員の方 (2012年10月29日)

引用: Node.jsについて個人的なまとめ | Z BLOG | ZEALOT社員ブログ

• まだ商用で使うには不安定な部分がある。
• 開発者が少ない。 : JavaScript開発者がNode.jsの開発者ではない。
• メジャーでもない。
• 非同期処理なのでエラーハンドリングが難しい。
• 基本的にシングルプロセスなのでどこかでシステムエラーが発生するとサーバダウン。
• Hot deployができない。

GREE CTO藤本さん (2012年8月)

引用: GREEが悩むNode.jsの問題を考えるヒント - ぼちぼち日記

1. ひたすらすごい勢いでバージョンアップしているので安定しない。コストを払ってついていく覚悟を持って取り組んでいる。
2. メモリリークがあるので、サーバを起動しっぱなしにするとメモリが食いつぶされる。
3. コードをデプロイしても再起動しないと読み込まれない。

解決策は、上記リンク先に書いてあります。

IIJ

node-v0.6からはクラスターモジュールが導入され、Node.jsがマルチプロセスで動作するようになりましたが、マルチプロセスを意識してプログラミングの設計をする必要があります。

玉石混淆のユーザモジュール

注目のサーバサイドJavaScript実行環境「Node.js」 | 最新の技術動向 | IIJ

デブサミ (2012年2月)

ソーシャルアプリのインフラはNode.jsが主役になるか～デブサミまとめレポート（ソーシャル＆インフラ編） - ＠IT

例えばNode.jsはI/Oや大量データ処理には強いものの、シングルスレッドでCPUパワーを使うようなタスクには弱い。そこで、結果はできるだけキャッシュするなどしてCPUリソースを節約する工夫が必要になる。HTMLのテンプレートやレンダリングなどはCPUリソースを消費するので、クライアントに処理を委譲してしまう対策も有効だという。 

データアクセスに関しては、Node.jsの処理は非常に高速だが、その分リクエスト回数が増えてDBに負荷を掛けることになる。そこで、制約をアプリケーションレベルで保持することによってDBの処理を低減しているという。

逆にNode.jsは、数値解析などプロセッサ処理が中心的となるような処理に対しては不適切

定期的に発生するV8エンジンのGC（ガベージコレクション

ブログ記事 (2011年2月20日)

node.jsは普及しそうに無い: ニュースの社会科学的な裏側

1. イベントループ・モデルで処理を直列化しているので、あるリクエストの処理に時間がかかる場合、他の全てのリクエストをブロックする可能性がある。
2. イベントループ・モデルで平行処理を行わないため、複数コアを持つCPU/MPU、複数のCPUを使うSMPでパフォーマンスの上昇が、JavaScriptのコード部分は期待できない。
3. JavaScriptのプログラミング言語としての限界が影響する。つまり、オブジェクト指向が不完全であること、動的型付けでJavaやC#に対して速度面に限界があること等が、大規模で複雑なアプリケーションには影響を及ぼす可能性がある。 4.あるページを表示するためのサーバー側のJavaScriptの文法エラーが、サーバーの停止を引き起こす。簡単なプログラム・ミスが、アプリケーションの非クリティカルな部分に発生したとしても、システム全体がダウンする結果となる。
4. 非同期化によるパフォーマンス向上がイベントループ・モデルに依存するため、イベントを受けるコールバック関数が多くなり（単純なファイル操作でも3回コールバックが発生する）、ソースコードの見通しが悪くなる。
5. 利用可能ライブラリが限定的であり、開発支援ツールが無い。Apacheモジュールも種類や用途が多いし、JavaやPHPにも覚えきれないほどのフレームワーク製品群とライブラリがある。これらに依存しない用途にしか、現状では利用できない。

上記、解決策は上記引用元や以下でも指摘があります。
Node.jsについてのよくある誤解 - 自分の感受性くらい

解決策

開発時の再起動問題

以下のモジュールを利用して、ファイル変更を検知して再起動する

• nodemon
  remy/nodemon
• supervisor
  isaacs/node-supervisor
• node-dev
  fgnass/node-dev
• hotnode
  saschagehlich/hotnode
• always
  edwardhotchkiss/always
• Qilin (麒麟? 作者は日本人の方)
  atsuya/qilin

本番サーバでのホットデプロイ問題

• forever, up, pm2

コールバック地獄問題

• future, promise, delay 並列処理のデザインパターンを使う future - Wikipedia
• 定番の async.js を使う
• yield を使う (Node.js version 0.12以降)

重い処理で処理が待たされる

• child_process.fork(filepath)

node.jsでCPUを使う重い処理のlibrary (child process使い) を1 fileで作る - c4se記：さっちゃんですよ☆

• fugue, Spark2, cluster
• process.nextTick() (v.0.10.xまで?ループで一回処理ならこちら)
• ループでn回の処理が必要なCPUヘビーな処理の場合、 setImmediate() 

マルチスレッド

Node.js でマルチスレッド対応のネイティブモジュールを作成する - 凹みTips

文法エラーで止まっちゃう問題

• 事前対策
  • 例外をキャッチする
  • Event: uncaughtException のリスナを登録
  • JSLint, JSHint等をコミットフックやデプロイ時に仕掛ける
  • ユニットテストを行う
• 事後対策
  • 監視して再起動する

エラーハンドリング問題

調査が甘いので、偉い人教えて下さい。

• 非同期コードの例外をキャッチする独自モジュール（node-gree）

メモリーリーク問題

• node-v0.10.22 のファイルハンドラのメモリーリーク修正で解決? (コメントより。 thx shigeki@github)

時が解決する問題

• 頻繁なバージョンアップ
• 安定性問題 
• Node.js 技術者が少ない
• ドキュメントが少ない問題

偉い人が解決してくれるだろう問題

• JavaScript の言語仕様の問題
  • オブジェクト指向

解決されていない問題

• 玉石混淆のユーザモジュール
• npm 上の評価システムの実装

•  この記事は以下の記事からリンクされています
• AngularJSのはじめの一歩(詳細)からリンク2年以上前
• Node.js良記事まとめ(随時更新)からリンク1年以上前
• Node.jsについて調べてみたからリンク2ヶ月前

 編集リクエストを送る

PR 社内メールでの情報共有をなくそう - Qiita:Team

hshimo

5827Contribution

人気の投稿

•  プログラマが独立・起業する時によくするミスと対策 まとめ
•  Node.jsの問題点、デメリットと解決方法まとめ
•  Node.js を5分で大雑把に理解する
•  猿でも分かる! Dependency Injection: 依存性の注入
•  PHPコーディング規約まとめ

• © 2016 Increments Inc.
 
• 利用規約
 
• プライバシー
 
• ヘルプ
 
• お問い合わせ

• Qiitaとは
 
• ブログ
 
• API
 
• Team
 
• Kobito
 
• Career
 
•  ご意見 

---
コメント：JavaScriptが不完全なオブジェクト指向で限界がある点は、
TypeScriptを使う事で解決できるので御座います。

私がTypeScriptについて勘違いしていたこと、そしてその理由

参考URL：
http://postd.cc/i-was-wrong-about-typescript-here-is-why/
以下は、一部引用。
「TypeScriptの背景には、大きな犠牲なしに利点を得る方法を知る人々による偉大な考えがあった」ことに気付いたかを説明しようと思います。

以下は、参考までに
生まれたての新プログラム言語「Nim」と言うのもまだ実験運用段階ですが、
面白いですよ！
「Nim」は、Pythonの様な構文とC言語並みの処理スピードを併せ持つサラブレッドです。

イケてないのに人気がある golang vs イケてるのに人気がない Nim

http://wolfbash.hateblo.jp/entry/2017/10/02/163017
一部引用しました。
 Nim は Python に強い影響を受けていて文法は Python そっくりです。そのためスッキリ書けて非常に見やすいです。Python をブラッシュアップして、秘伝の悪魔のタレをかけたような感じです。