Node.jsの仕組みや内部の動き、なぜそうなるのか?などをわかりやすく説明している書籍です。
特に非同期処理に集中して説明が書かれています。
但し、Node.jpを初めて覚えようとした場合は問題があります。
一番最初の最も簡単なサンプルの覚え書きに「アロー関数に関しては付録を読んで下さい」と飛ばされ
10ページほどの付録にECMAScript5の簡単な違いが書かれていて、それを読み始めると今度は「詳しくは初めてのJavaScript 第3版を読む必要があります」と出てきます。
使用するソースコードは必要最小限のもので説明が行われ、わかりにくい箇所は図で説明されています。
Javascript ECMAScript5を理解している人向けのNode.js書籍です。
分厚い割りには内容を詰め込んだ感じでは無く読みやすくなっています。
プライム無料体験をお試しいただけます
プライム無料体験で、この注文から無料配送特典をご利用いただけます。
非会員 | プライム会員 | |
---|---|---|
通常配送 | ¥410 - ¥450* | 無料 |
お急ぎ便 | ¥510 - ¥550 | |
お届け日時指定便 | ¥510 - ¥650 |
*Amazon.co.jp発送商品の注文額 ¥2,000以上は非会員も無料
無料体験はいつでもキャンセルできます。30日のプライム無料体験をぜひお試しください。
新品:
¥4,620¥4,620 税込
ポイント: 139pt
(3%)
無料お届け日:
3月31日 日曜日
発送元: Amazon.co.jp 販売者: Amazon.co.jp
新品:
¥4,620¥4,620 税込
ポイント: 139pt
(3%)
無料お届け日:
3月31日 日曜日
発送元: Amazon.co.jp
販売者: Amazon.co.jp
中古品: ¥2,380
中古品:
¥2,380

無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません。
ウェブ版Kindleなら、お使いのブラウザですぐにお読みいただけます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
Node.jsデザインパターン 第2版 単行本(ソフトカバー) – 2019/5/18
{"desktop_buybox_group_1":[{"displayPrice":"¥4,620","priceAmount":4620.00,"currencySymbol":"¥","integerValue":"4,620","decimalSeparator":null,"fractionalValue":null,"symbolPosition":"left","hasSpace":false,"showFractionalPartIfEmpty":true,"offerListingId":"3y5JcH7eBtxTOCUs93mgdgzsRbzmOkXfffX93wJI5isiKOUyhFMRX3afYw89k046OOQPjmuyXEhTD8GV0K5Y%2FJFA8hNu0hrn8m9%2FeTM%2FZjv6t4Ol6KcDljmhvLwXsDYBlmJLNtgtB%2BE%3D","locale":"ja-JP","buyingOptionType":"NEW","aapiBuyingOptionIndex":0}, {"displayPrice":"¥2,380","priceAmount":2380.00,"currencySymbol":"¥","integerValue":"2,380","decimalSeparator":null,"fractionalValue":null,"symbolPosition":"left","hasSpace":false,"showFractionalPartIfEmpty":true,"offerListingId":"3y5JcH7eBtxTOCUs93mgdgzsRbzmOkXfBBUp%2F6ZxUs%2FbFX1KW89A0iL5wv1h1T0OA2oHD01HMz8SMj0pIgbvwU9jdMpVfbusxkSBjqWBd29iC%2Fr7lqh2VByzp4iTA4Yn9kTF44tFx9Wr3NzcKCNY8%2FyF%2Bz3dIKbuXVMSfw1%2BYNxc%2FQ9nUl2E%2Bg%3D%3D","locale":"ja-JP","buyingOptionType":"USED","aapiBuyingOptionIndex":1}]}
購入オプションとあわせ買い
Node/JavaScriptアプリの設計技法を、実際に手を動かしながら学ぶハンズオン形式の解説書。
本書では最初に、JavaScriptの大きな特徴でありながら多くの開発者にとって馴染みの薄い非同期処理(コールバックを用いた処理)についてその仕組みを詳しく説明するとともに主なデザインパターンを説明し、Node.jsの基礎を押さえます。
次に、ストリームや一般的なデザインパターンのNode.jsでの実装、Node.js専用のデザインパターンといった事柄を解説します。
最後に、ユニバーサルJavaScript、スケーラビリティ、Node.jsを使ったエンタープライズアプリの開発といったより高度なトピックを扱います。
中級以上のウェブ開発者を対象としています。バージョン11対応。
本書では最初に、JavaScriptの大きな特徴でありながら多くの開発者にとって馴染みの薄い非同期処理(コールバックを用いた処理)についてその仕組みを詳しく説明するとともに主なデザインパターンを説明し、Node.jsの基礎を押さえます。
次に、ストリームや一般的なデザインパターンのNode.jsでの実装、Node.js専用のデザインパターンといった事柄を解説します。
最後に、ユニバーサルJavaScript、スケーラビリティ、Node.jsを使ったエンタープライズアプリの開発といったより高度なトピックを扱います。
中級以上のウェブ開発者を対象としています。バージョン11対応。
- 本の長さ464ページ
- 言語日本語
- 出版社オライリージャパン
- 発売日2019/5/18
- 寸法24 x 19 x 2.5 cm
- ISBN-104873118735
- ISBN-13978-4873118734
よく一緒に購入されている商品

対象商品: Node.jsデザインパターン 第2版
¥4,620¥4,620
最短で3月31日 日曜日のお届け予定です
残り4点(入荷予定あり)
総額:
当社の価格を見るには、これら商品をカートに追加してください。
ポイントの合計:
pt
もう一度お試しください
追加されました
一緒に購入する商品を選択してください。
この商品をチェックした人はこんな商品もチェックしています
ページ 1 以下のうち 1 最初から観るページ 1 以下のうち 1
商品の説明
著者について
Mario Casciaro(マリオ・カッシャーロ):ソフトウェアエンジニア兼企業家。テクノロジーやサイエンス、オープンソースが大好き。ソフトウェア工学の修士号を取得後、IBMに入社。IBMではTivoli Endpoint Manager、Cognos Insight、SalesConnectなどの企業向け製品の開発に携わる。その後、注目のSaaS企業D4H Technologiesに移り、リアルタイムで緊急な運用が求められる、最先端技術を駆使した新製品の開発を率いた。現在は、自らが共同設立者でもあるSponsorama.comのCEOを務めている(Sponsorama.comは、企業スポンサーからオンラインで資金を調達するプラットフォーム)。本書の初版はMario Casciaroの単著。第2版はLuciano Mamminoとの共著。
Luciano Mammino(ルチアーノ・マンミーノ):1987年生まれのソフトウェアエンジニア(1987年は任天堂の『スーパーマリオブラザーズ』がヨーロッパでリリースされた年。偶然にも『スーパーマリオブラザーズ』はお気に入りのテレビゲームのひとつ)。父親が所有していた、DOSオペレーティングシステムとqBasicインタプリタしかない古いx386マシンで、12歳のときにプログラミングを始めた。計算機科学の修士号を取得後、イタリアを中心に企業やスタートアップでフリーの開発者として働きながらウェブ開発のプログラミングスキルを磨く。Sbaam.comの共同設立者およびCTOとして3年間イタリアとアイルランドでスタートアップに勤務したあと、アイルランドの首都ダブリンに移り、Smartboxで上級PHPエンジニアとして働くことに決めた。オープンソースのライブラリ開発やSymfonyやExpressといったフレームワークを使った開発がお気に入り。JavaScriptの名声はまだ始まったばかりであり、ウェブおよびモバイル関連のテクノロジーの未来に今後JavaScriptがとても大きな衝撃を与えると確信している。そのため、今でも自由時間のほとんどを使ってJavaScriptとNodeの知識の向上に努めている。
Luciano Mammino(ルチアーノ・マンミーノ):1987年生まれのソフトウェアエンジニア(1987年は任天堂の『スーパーマリオブラザーズ』がヨーロッパでリリースされた年。偶然にも『スーパーマリオブラザーズ』はお気に入りのテレビゲームのひとつ)。父親が所有していた、DOSオペレーティングシステムとqBasicインタプリタしかない古いx386マシンで、12歳のときにプログラミングを始めた。計算機科学の修士号を取得後、イタリアを中心に企業やスタートアップでフリーの開発者として働きながらウェブ開発のプログラミングスキルを磨く。Sbaam.comの共同設立者およびCTOとして3年間イタリアとアイルランドでスタートアップに勤務したあと、アイルランドの首都ダブリンに移り、Smartboxで上級PHPエンジニアとして働くことに決めた。オープンソースのライブラリ開発やSymfonyやExpressといったフレームワークを使った開発がお気に入り。JavaScriptの名声はまだ始まったばかりであり、ウェブおよびモバイル関連のテクノロジーの未来に今後JavaScriptがとても大きな衝撃を与えると確信している。そのため、今でも自由時間のほとんどを使ってJavaScriptとNodeの知識の向上に努めている。
登録情報
- 出版社 : オライリージャパン; 第2版 (2019/5/18)
- 発売日 : 2019/5/18
- 言語 : 日本語
- 単行本(ソフトカバー) : 464ページ
- ISBN-10 : 4873118735
- ISBN-13 : 978-4873118734
- 寸法 : 24 x 19 x 2.5 cm
- Amazon 売れ筋ランキング: - 172,720位本 (本の売れ筋ランキングを見る)
- - 204位Webプログラミング
- カスタマーレビュー:
著者について
著者をフォローして、新作のアップデートや改善されたおすすめを入手してください。

ソフトウェア開発者兼翻訳家。マーリンアームズ株式会社(www.marlin-arms.co.jp)代表取締役。国際基督教大学、山梨大学大学院、リソースシェアリング株式会社、オハイオ州立大学大学院、カーネギーメロン大学客員研究員等を経て、東京工業大学大学院博士後期課程修了。マーリンアームズ株式会社代表取締役。主に自然言語処理関連ソフトウェアの開発、ソフトウェア関連を中心とした翻訳、プログラミング教育、辞書サイト「辞遊人」(www.dictjuggler.net)の運営などを手がける。
-
トップレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
2019年6月9日に日本でレビュー済み
Node.jsのシングルスレッド、ノンブロッキングI/Oによる独自のアーキテクチャを踏まえた実装における細かなコーディング作法からデザインパターンまでを学ぶことができる。
大規模開発のための整備されたコード設計、関数設計、クラス設計、さらには分散スケール環境でのアーキテクチャのデザインパターンまでを紹介してくれている。node.jsはv11.9.0に対応。
gitからソースコードを取得できるが、著書に記載されているソースコードだけでも処理の概要を把握できるよう配慮されているのがありがたい。
基本的に各チャプターごとにプロジェクトファイルが用意されpackage.jsonで必要関連ライブラリをバージョン指定されているので、フォルダ内でnpm install の一発で環境が揃うのはありがたい配慮だ。著書では、ライブラリの個別インストールのコマンドが表記されているが、上記を実行していれば特に必要はない。
※一部でグローバルインストールが別途必要なものあり
※redis, rabbitMQなどミドルウェアは、別途構築する必要あり
コードを追いながら、高度なアーキテクチャの技術を身に付けたい人向け。
Node.jsの中上級者向けに響く著作だと感じた。
-------------------
#注意点
8章 webpackをグローバルインストールする記載がされている> P255
バージョンを指定しないと最新版がインストールされ、著書と挙動が異なって検証ができ
なくなるので、以下のバージョンでインストールすること。(package.jsonにも記されているので確認できる。)
npm install webpack@1.12.14 -g
※package.jsonのwebpackと合わせる
他のnpmでグローバルインストールしているものは、package.jsonのバージョンに合わせたほうがいい
8章:sample12,13,14
P285 に実行コマンドにnode serverと記載されているが、コードに記載されたJSXを変換実行する必要があるので、babel-nodeまたは、babel-cliをかましてスクリプトを実行する必要がある。
例:./node_modules/babel-cli/bin/babel-node.js server
9章以降:
node-gyp系リビルド処理でpython2.7系が必要なケースもあり。
nvmで異なるnodeのバージョンが必要になるケースもあり
macで検証している場合は xcode, xcode toolを最新版にしておくこと
--------------------
#以下、内容メモ
1章:Node.jsの世界へようこそ
モジュールは小さく設計すべき
・コードを少なく
・機能を最小限
npmによってモジュールの依存地獄から解放
->パッケージが個別に依存モジュールを定義できる
ブロッキングI/O:
I/O処理は時間がかかる→サーバがブロッキングI/Oの場合、複数リクエストの場合は新たにスレッドを起こす必要がある。消費するメモリや、コンテキストスイッチのコストを考えると、効率は良くない。
ノンブロッキングI/O:
データの書き込み完了をまたずに一旦終了できる。
同一スレッドで、複数リソースを扱えるようになる。
イベントループでビジーウェイトせずに複数のI/Oを処理
並行性の扱いが単純になる。スレッドの競合、同期を考慮しなくて良い
・リアクタパターン
I/Oタスクのそれぞれにハンドラ(コールバック関数)を対応させるもの
コールバック関数を使用して、すべてのリソース処理を後回しにするようなプログラミン
グスタイル。
Node.jsのアーキテクチャ
libuv:node.jsのCライブラリで、OSに依存せず同じ手法でブロッキングI/Oを使える。
v8:GoogleによりChromeブラウザのために作られら高速効率的メモリ管理のJavaScriptエンジン
バインディング:libuvmやその他の低レベルの機能をラップし、JavaScriptで利用できる
ようにするための抽象化レイヤー
node-core:ハイレベルなNode APIを実装したJavaScriptライブラリ
2章:Node.jsの基本パターン
・コールバックパターン
同期プログラミングにおけるreturn文に相当。非同期プログラミングでは必須。
JavaScriptのクロージャを使うことで、コールバック関数内にその関数で生成された環境
を参照することができる。
関数によって同期、非同期で呼ばれるかの違いによって呼び出し元の実装も変わる。
関数内で分岐判定処理によって同期や非同期で値が返る仕様は思わぬバグを産む。
->どちらかに明示的に仕様を決める。
process.nextTick() イベントループで次まで関数の実行を遅延(先延ばし)してくれる。登録されたI/Oイベントの前に実行->nextTIck()の再帰呼び出しはI/O starvationに陥るケースがあるので注意。
setImmediate():登録されたI/Oイベントの後に実行
try catchでキャッチされない例外の補足方法
process.on('uncaughtException',(err)=>{ //todo process.exit(1); }):
依存解決の仕組み:ロード元によて異なるモジュールのバージョンをロードする機能
循環参照の注意点:読み込む順番によって初期化されるモジュールが異なる問題が起きる
・モジュール定義におけるパターン
オブジェクト、コンストラクタ、関数のエクスポート
インスタンスのエクスポート
・オブザーバパターン
EventEmitterをつかって複数のオブザーバに対して通知を行う。
on, emit, return emitter P62
複数イベントを扱う、イベントの発生回数が予測できない場合に向いている。
コールバックと、EventEmitterを組み合わせた関数
glon(pattern, [option], callback).on('match', match => console.log(`${match}`))
コールバックは結果データを返すが、EventEmitter(`match`)で中間処理情報を通知する仕組み
3章:コールバックを用いた非同期パターン
コールバックのネストが幾つも重なる=コールバック地獄 p51
視認性が悪く、クロージャを解放し忘れるとメモリリークの原因にもなる
・クロージャを乱用しない
・if文にelseをかかず、returnでなるべく早く抜ける:ネストレベルを下げる
・コールバックを独立した関数で定義し、クロージャを使わない。
・一つの関数にネストしたコールバックを書かず、複数の関数に分割する
※クロージャ:自分を囲むスコープにある変数を参照できる関数:関数の内側の関数
逐次処理におけるコールバックの伝播
並行処理におけるコールバックの伝播
・並行処理:非同期でイベントループ内で並列数分インタリーブされ処理される。
マルチスレッドでないので特別な技術は必要ない。Nodeの強み。
完全に競合状態がないわけではない。複数タスク新しいファイルだった場合ファイル読み込み処理するケースで、複数タスクが同時に新しいファイルだと判定して、同じ処理をしてしまう場合がある。
同時実行数制限をした並行処理
キューを使った同時実行数制御
委譲:delegate
asyncライブラリを使用した逐次、並行処理、同時実行数を制御した並行処理
series:非同期逐次実行
eachSeries:配列要素を捜査して非同期逐次実行
each:並行eachSeriesからの移行に便利
eachLimit,mapLimit,parallelLimit,queue,cargo:同時実行数を制限した並行処理
前半の並行処理実装は、asyncライブラリで簡潔に置き換えられる
4章:ES2015以降の機能を使った非同期パターン
Promise:コールバックの欠点を補うために考案された。非同期処理の結果を表現するオブジェクト。callbackなどの橋渡しスタイルからの変更
Generator:functionの後ろに*を付加して宣言すれば、yieldにより処理を中断できる。
非同期の制御フローを簡単に記述(yield, next()を活用)し、関数を一旦抜けたり、そこから再開できるようにする
coライブラリを利用したジェネレータベースの制御フロー
async/awaitを使用した制御フローでGeneratorを使用することで複雑化した実装をシンプルにする。
5章:ストリーム
ストリームとバッファの違い
バッファ:データが全て揃ってからコールバック通知
ストリーム:データを受け取った時点で途中でもコールバック通知可能
巨大なデータも少ないリソースでやりとりできる。
ファイル転送後の解凍処理もチャンク単位で圧縮して転送し解凍することができる。
バイナリモード:チャンクの形でストリーム化する
オブジェクトモード:オブジェクトとしてデータを処理
・Readable:ソースを表現
non-flowingモード:readableイベントにアタッチ、read()でバッファが空になるまで読み込む
flowingモード:dataイベントにアタッチ、データがリスナーにプッシュされる
Readableストリームの実装:_read()は継承したReadable内部で呼ばれる
・Writable:データの行き先
writable.write でチャンク書き込み
writable.end で最後のチャンク書き込み
バックプレッシャ:データが消費されるよりも速く書き込まれてしまう場合の対処
Writableストリームの実装:_write()は継承したWritable内部で呼ばれる
・Duplex:ReadableかつWritableなストリーム、双方を継承しread(),write()を行う
・Transform:データ変換用 write -> read
・パイプを使ったストリームの接続
unixでは、次のプログラムの入力として簡単に接続できる
echo Hello World! | sed s/World/Node.js/g
node.js -> pipe()で行う
・パイプ処理パターン
Combinedストリーム:ストリームの合併
ストリームのフォーク
ストリームのマージ
マルチプレクシングとでマルチプレクシング
6章:オブジェクト指向デザインパターンのNode.jsへの適用
・ファクトリ:
p152 模擬オブジェクトを返す(start:function{}, end:function{})
合成可能ファクトリ:ファイプラリstampit
・公開コンストラクタ
・プロキシ
データ妥当性検討、権限チェック、キャ種保存、遅延初期化など
応用:配列の仮想化
・デコレータ
・アダプタ
・ストラテジー
・ステート
コンテクストの状態によって変化するストラテジーとして見れる
・テンプレート
具象クラスが定義された瞬時にアルゴリズムが決定される。ストラテジとの違いは、ストラテジは動的に変更が可能、テンプレートはクラスが定義された瞬間にアルゴリズムが決定する。
・ミドルウェア
玉ねぎの皮のようにミドルウェアの層をつくり、順に層を呼び出し中心のアプリケーションのコアに到達させる。
・コマンド
7章:モジュールの接続
・シングルトンとしてモジュールを利用するパターン
modele.exportsを活用
require()関数呼び出し時にキャッシュされ、以降はキャッシュを返すため
->落とし穴がある。パッケージごとに異なるnode_modulesのパッケージを参照してしまう恐れあり:global変数で対応できるが、この方法は避けるべき。
・モジュール接続のためのパターン
require()でステートを持ったインスタンスへの依存をハードコードすることによる制限
DI(依存性注入)のケース:Factoryパターンを活用して後からモジュールを指定する
->利点:dependencyから分離し再利用しやすくなる
欠点:依存関係の把握が増加複雑化すると管理が大変
サービスロケータ:DI同様、コンポーネント間の把握が難しくなる
DIコンテナ:依存するもの以外の余計なサービスにモジュールを依存させなくできる
・プラグインの接続
require()するだけで、プラグイン機能を付加できる実装:関数を変数に格納する手法とデコレータパターンを駆使して行う
サービスロケータ、DIコンテナをつかった公開方法
8章:ユニバーサルJavaScript
サーバサイドとフロントエンドでのコード共有
Reactを使用したSPA(Single-Page-Application)の作成
・モジュールの共有
UMDパターン:定型的なコードを沢山書かなければならない
ES2015モジュール:サポートされていないブラウザに注意
・Webpackの導入
node用に作成したモジュールをブラウザ用に書き直してくれる
ES2015で提供される機能を実装していても変換してくれる
・クロスプラットフォーム開発の基礎
実行時コード分岐
ビルド時コード分岐:Webpackの例
ビルド時にモジュール置換:Webpackの例
クロスプラットフォーム開発向けのデザインパターン
・ストラテジー、テンプレート:用途によって切り替え処理ができる
・アダプター:互換性を持たすようにアダプターで置換する
・プロキシ:サーバ側のモジュールをリモートプロキシで呼び出す
・オブザーバ:イベントを発生、受け取りのコンポーネントを抽象化
・DIとサービスロケータ:依存性注入時にモジュール入れ替えする
・React
サーバ内とクライアントでほぼ同じコードでのビューのレンダリングができる
Nodeサーバでビューをレンダリングしてブラウザが受け取り表示可能=SPAを作成できる。
JSX:HTMLとDOMツリー表現の中間フォーマット的な位置付け
expressのstaticを利用してwebpackしたモジュールを読み込めるようにして、1度目はサーバでレンダリングし、以降はブラウザで再描画する仕組み
babel-cliでサーバサイドでJSX記述を残したまま、実行時変換起動させる方法
Webサーバ(プロキシとして活用)、APIサーバとスケーラブルな構成のパターン
9章;特殊な問題を解決するためのパターン
・非同期に初期化されるもモジュールのrequire
ステートパターンを利用し実行リクエストをキューにため、非同期実行が完了してからキューのリクエストを実行する堅牢な作りの紹介
・非同期のバッチ処理とキャッシュの利用
・CPUバウンドなタスクの実行
setImmediateによるインタリーブ:cpuバウンドの処理のステップが完了するたびにイベントループに制御を戻す
マルチプロセスの利用:子プロセスへ移譲
10章:スケーラビリティとアーキテクチャ
複数プロセス利用、複数サーバ利用にしてスケールする
下記3つの観点でのスケールを考える。
クローニング:アプリをn回クローニングして各インスタンスに1/nの処理をさせる
サービスと機能による分割;機能、サービス、ユースケースで分割
データパーティションによる分割:データの一部を各インスタンスが分担して担当
水平分割、シャーディング
・クローニングと負荷分散
モジュールcluster
・バージョン0.11.2以降からラウンドロビン方式の振り分け
・障害時の再起動(zero-downtime restart)の実装
・負荷分散
ステートフルにしたいデータの共有問題
・共有メモリを利用した認証データの保存
・スティッキーな負荷分散(値判定で特定ノードへ割り振る)による特定なインスタンスへのマッピング
->問題点あり:インスタンスの代替が効かなくなる問題
リバースプロキシによるスケーリング
・ロードバランサとして機能するリバースプロキシ
・URLリライト、キャッシング、SSLターミネーション
・nginxをロードバランサとしてバックエンドにnodeのwebサーバを稼働させたパターン
サービスレジストリを活用し、最新の稼働サーバ情報を登録し、ロードバランサがその内容を参照するパターン
・nodeでの負荷分散装置の実装
ピアツーピア負荷分散:ロードバランサの処理量に依存させない方法:その分、接続方法は複雑になる
・サービスと機能の分割
マイクロサービスアーキテクチャのパターン
各サービスにデータ所有権があることがマイクロサービスアーキテクチャの特徴
正しいレベルの分離を独立維持するために、データベースも分割する
データベースを分割した分、システム全体の一貫性を維持するために、互いのデータを参照更新する多くの通信が必要になる。
クラッシュ、バグ、互換性を破る変更をシステム全体に波及させないようにする。
利点:
・再利用性向上
・スケールは、複数マシンに負荷分散。独立してスケール可能
難点:
・管理すべきノードが増えると、統合、デプロイ、コード共有が複雑になる。
・APIオーケストレーション層で複数のマイクロサービスのAPIを実行し、データを集約、処理する。
・メッセージブローかを使ったケース;フロントエンドのリクエストを受け取ったマイクロサービスが、関連するマイクロサービスにメッセージブローカを通して処理を行う
11章;メッセージ通信と統合
分散アプリケーションを統合する手段
・共有ストレージを中央の調整器兼情報の保持器として使う。
・メッセージを使ってデータ、胃炎と、コマンドを各ノードに行き渡らせる
メッセージ通信
・非同期メッセージと送信キュー:SMSのようなもの
・ピアツーピアメッセージ通信
・ブローカを使ったメッセージ通信:プロトコル間のブリッジにも利用できる、ブローカ
が単一障害になるデメリットはある。
パブリッシュ/サブスクライブ(pub/sub)パターン
分散オブザーバーパターンでもある
・ピアツーピア型Pub/Sub
・ブローカ型Pub/Sub
メッセージブローカにredisを適用したチャットサーバの分散スケール
ZeroMQを使ったピアツーピア型PubSubで分散処理するチャットサーバ
サブスクライバに障害が起きても確実にメッセージを送信できるような永続サブスクライバの実現
・多くのメッセージキューシステムが採用しているプロトコル:AMQP
ラビットMQを使用したAMQPによるチャットサーバ
パイプラインとタスク分散パターン
・ZeroMQのファンアウト/ファンインパターン
ハッシュサムを総当たりでしてアルファベットの考えられるすべての組み合わせを照合
するシステムで実践
ベンチレータ->ワーカー->シンク
・パイプラインとAMQPの競合コンシューマ
競合コンシューマ;複数のコンシューマが同じキューをリッスンし、メッセージをファ
ンアウト分散する
リクエスト/リプライ・パターン
・相関識別子を使用した、リクエストとリプライの紐付けで、リクエスト順序に影響しない
実装方法
付録A:ES2015以降のJavaScriptの主要機能
let, const:変数定義
アロー関数:=> コールバック関数を簡潔化記述できる
class構文
オブジェクトリテラルの改善
MapとSet
WeakMapとWeakSet
テンプレートリテラル
etc...
以上。
大規模開発のための整備されたコード設計、関数設計、クラス設計、さらには分散スケール環境でのアーキテクチャのデザインパターンまでを紹介してくれている。node.jsはv11.9.0に対応。
gitからソースコードを取得できるが、著書に記載されているソースコードだけでも処理の概要を把握できるよう配慮されているのがありがたい。
基本的に各チャプターごとにプロジェクトファイルが用意されpackage.jsonで必要関連ライブラリをバージョン指定されているので、フォルダ内でnpm install の一発で環境が揃うのはありがたい配慮だ。著書では、ライブラリの個別インストールのコマンドが表記されているが、上記を実行していれば特に必要はない。
※一部でグローバルインストールが別途必要なものあり
※redis, rabbitMQなどミドルウェアは、別途構築する必要あり
コードを追いながら、高度なアーキテクチャの技術を身に付けたい人向け。
Node.jsの中上級者向けに響く著作だと感じた。
-------------------
#注意点
8章 webpackをグローバルインストールする記載がされている> P255
バージョンを指定しないと最新版がインストールされ、著書と挙動が異なって検証ができ
なくなるので、以下のバージョンでインストールすること。(package.jsonにも記されているので確認できる。)
npm install webpack@1.12.14 -g
※package.jsonのwebpackと合わせる
他のnpmでグローバルインストールしているものは、package.jsonのバージョンに合わせたほうがいい
8章:sample12,13,14
P285 に実行コマンドにnode serverと記載されているが、コードに記載されたJSXを変換実行する必要があるので、babel-nodeまたは、babel-cliをかましてスクリプトを実行する必要がある。
例:./node_modules/babel-cli/bin/babel-node.js server
9章以降:
node-gyp系リビルド処理でpython2.7系が必要なケースもあり。
nvmで異なるnodeのバージョンが必要になるケースもあり
macで検証している場合は xcode, xcode toolを最新版にしておくこと
--------------------
#以下、内容メモ
1章:Node.jsの世界へようこそ
モジュールは小さく設計すべき
・コードを少なく
・機能を最小限
npmによってモジュールの依存地獄から解放
->パッケージが個別に依存モジュールを定義できる
ブロッキングI/O:
I/O処理は時間がかかる→サーバがブロッキングI/Oの場合、複数リクエストの場合は新たにスレッドを起こす必要がある。消費するメモリや、コンテキストスイッチのコストを考えると、効率は良くない。
ノンブロッキングI/O:
データの書き込み完了をまたずに一旦終了できる。
同一スレッドで、複数リソースを扱えるようになる。
イベントループでビジーウェイトせずに複数のI/Oを処理
並行性の扱いが単純になる。スレッドの競合、同期を考慮しなくて良い
・リアクタパターン
I/Oタスクのそれぞれにハンドラ(コールバック関数)を対応させるもの
コールバック関数を使用して、すべてのリソース処理を後回しにするようなプログラミン
グスタイル。
Node.jsのアーキテクチャ
libuv:node.jsのCライブラリで、OSに依存せず同じ手法でブロッキングI/Oを使える。
v8:GoogleによりChromeブラウザのために作られら高速効率的メモリ管理のJavaScriptエンジン
バインディング:libuvmやその他の低レベルの機能をラップし、JavaScriptで利用できる
ようにするための抽象化レイヤー
node-core:ハイレベルなNode APIを実装したJavaScriptライブラリ
2章:Node.jsの基本パターン
・コールバックパターン
同期プログラミングにおけるreturn文に相当。非同期プログラミングでは必須。
JavaScriptのクロージャを使うことで、コールバック関数内にその関数で生成された環境
を参照することができる。
関数によって同期、非同期で呼ばれるかの違いによって呼び出し元の実装も変わる。
関数内で分岐判定処理によって同期や非同期で値が返る仕様は思わぬバグを産む。
->どちらかに明示的に仕様を決める。
process.nextTick() イベントループで次まで関数の実行を遅延(先延ばし)してくれる。登録されたI/Oイベントの前に実行->nextTIck()の再帰呼び出しはI/O starvationに陥るケースがあるので注意。
setImmediate():登録されたI/Oイベントの後に実行
try catchでキャッチされない例外の補足方法
process.on('uncaughtException',(err)=>{ //todo process.exit(1); }):
依存解決の仕組み:ロード元によて異なるモジュールのバージョンをロードする機能
循環参照の注意点:読み込む順番によって初期化されるモジュールが異なる問題が起きる
・モジュール定義におけるパターン
オブジェクト、コンストラクタ、関数のエクスポート
インスタンスのエクスポート
・オブザーバパターン
EventEmitterをつかって複数のオブザーバに対して通知を行う。
on, emit, return emitter P62
複数イベントを扱う、イベントの発生回数が予測できない場合に向いている。
コールバックと、EventEmitterを組み合わせた関数
glon(pattern, [option], callback).on('match', match => console.log(`${match}`))
コールバックは結果データを返すが、EventEmitter(`match`)で中間処理情報を通知する仕組み
3章:コールバックを用いた非同期パターン
コールバックのネストが幾つも重なる=コールバック地獄 p51
視認性が悪く、クロージャを解放し忘れるとメモリリークの原因にもなる
・クロージャを乱用しない
・if文にelseをかかず、returnでなるべく早く抜ける:ネストレベルを下げる
・コールバックを独立した関数で定義し、クロージャを使わない。
・一つの関数にネストしたコールバックを書かず、複数の関数に分割する
※クロージャ:自分を囲むスコープにある変数を参照できる関数:関数の内側の関数
逐次処理におけるコールバックの伝播
並行処理におけるコールバックの伝播
・並行処理:非同期でイベントループ内で並列数分インタリーブされ処理される。
マルチスレッドでないので特別な技術は必要ない。Nodeの強み。
完全に競合状態がないわけではない。複数タスク新しいファイルだった場合ファイル読み込み処理するケースで、複数タスクが同時に新しいファイルだと判定して、同じ処理をしてしまう場合がある。
同時実行数制限をした並行処理
キューを使った同時実行数制御
委譲:delegate
asyncライブラリを使用した逐次、並行処理、同時実行数を制御した並行処理
series:非同期逐次実行
eachSeries:配列要素を捜査して非同期逐次実行
each:並行eachSeriesからの移行に便利
eachLimit,mapLimit,parallelLimit,queue,cargo:同時実行数を制限した並行処理
前半の並行処理実装は、asyncライブラリで簡潔に置き換えられる
4章:ES2015以降の機能を使った非同期パターン
Promise:コールバックの欠点を補うために考案された。非同期処理の結果を表現するオブジェクト。callbackなどの橋渡しスタイルからの変更
Generator:functionの後ろに*を付加して宣言すれば、yieldにより処理を中断できる。
非同期の制御フローを簡単に記述(yield, next()を活用)し、関数を一旦抜けたり、そこから再開できるようにする
coライブラリを利用したジェネレータベースの制御フロー
async/awaitを使用した制御フローでGeneratorを使用することで複雑化した実装をシンプルにする。
5章:ストリーム
ストリームとバッファの違い
バッファ:データが全て揃ってからコールバック通知
ストリーム:データを受け取った時点で途中でもコールバック通知可能
巨大なデータも少ないリソースでやりとりできる。
ファイル転送後の解凍処理もチャンク単位で圧縮して転送し解凍することができる。
バイナリモード:チャンクの形でストリーム化する
オブジェクトモード:オブジェクトとしてデータを処理
・Readable:ソースを表現
non-flowingモード:readableイベントにアタッチ、read()でバッファが空になるまで読み込む
flowingモード:dataイベントにアタッチ、データがリスナーにプッシュされる
Readableストリームの実装:_read()は継承したReadable内部で呼ばれる
・Writable:データの行き先
writable.write でチャンク書き込み
writable.end で最後のチャンク書き込み
バックプレッシャ:データが消費されるよりも速く書き込まれてしまう場合の対処
Writableストリームの実装:_write()は継承したWritable内部で呼ばれる
・Duplex:ReadableかつWritableなストリーム、双方を継承しread(),write()を行う
・Transform:データ変換用 write -> read
・パイプを使ったストリームの接続
unixでは、次のプログラムの入力として簡単に接続できる
echo Hello World! | sed s/World/Node.js/g
node.js -> pipe()で行う
・パイプ処理パターン
Combinedストリーム:ストリームの合併
ストリームのフォーク
ストリームのマージ
マルチプレクシングとでマルチプレクシング
6章:オブジェクト指向デザインパターンのNode.jsへの適用
・ファクトリ:
p152 模擬オブジェクトを返す(start:function{}, end:function{})
合成可能ファクトリ:ファイプラリstampit
・公開コンストラクタ
・プロキシ
データ妥当性検討、権限チェック、キャ種保存、遅延初期化など
応用:配列の仮想化
・デコレータ
・アダプタ
・ストラテジー
・ステート
コンテクストの状態によって変化するストラテジーとして見れる
・テンプレート
具象クラスが定義された瞬時にアルゴリズムが決定される。ストラテジとの違いは、ストラテジは動的に変更が可能、テンプレートはクラスが定義された瞬間にアルゴリズムが決定する。
・ミドルウェア
玉ねぎの皮のようにミドルウェアの層をつくり、順に層を呼び出し中心のアプリケーションのコアに到達させる。
・コマンド
7章:モジュールの接続
・シングルトンとしてモジュールを利用するパターン
modele.exportsを活用
require()関数呼び出し時にキャッシュされ、以降はキャッシュを返すため
->落とし穴がある。パッケージごとに異なるnode_modulesのパッケージを参照してしまう恐れあり:global変数で対応できるが、この方法は避けるべき。
・モジュール接続のためのパターン
require()でステートを持ったインスタンスへの依存をハードコードすることによる制限
DI(依存性注入)のケース:Factoryパターンを活用して後からモジュールを指定する
->利点:dependencyから分離し再利用しやすくなる
欠点:依存関係の把握が増加複雑化すると管理が大変
サービスロケータ:DI同様、コンポーネント間の把握が難しくなる
DIコンテナ:依存するもの以外の余計なサービスにモジュールを依存させなくできる
・プラグインの接続
require()するだけで、プラグイン機能を付加できる実装:関数を変数に格納する手法とデコレータパターンを駆使して行う
サービスロケータ、DIコンテナをつかった公開方法
8章:ユニバーサルJavaScript
サーバサイドとフロントエンドでのコード共有
Reactを使用したSPA(Single-Page-Application)の作成
・モジュールの共有
UMDパターン:定型的なコードを沢山書かなければならない
ES2015モジュール:サポートされていないブラウザに注意
・Webpackの導入
node用に作成したモジュールをブラウザ用に書き直してくれる
ES2015で提供される機能を実装していても変換してくれる
・クロスプラットフォーム開発の基礎
実行時コード分岐
ビルド時コード分岐:Webpackの例
ビルド時にモジュール置換:Webpackの例
クロスプラットフォーム開発向けのデザインパターン
・ストラテジー、テンプレート:用途によって切り替え処理ができる
・アダプター:互換性を持たすようにアダプターで置換する
・プロキシ:サーバ側のモジュールをリモートプロキシで呼び出す
・オブザーバ:イベントを発生、受け取りのコンポーネントを抽象化
・DIとサービスロケータ:依存性注入時にモジュール入れ替えする
・React
サーバ内とクライアントでほぼ同じコードでのビューのレンダリングができる
Nodeサーバでビューをレンダリングしてブラウザが受け取り表示可能=SPAを作成できる。
JSX:HTMLとDOMツリー表現の中間フォーマット的な位置付け
expressのstaticを利用してwebpackしたモジュールを読み込めるようにして、1度目はサーバでレンダリングし、以降はブラウザで再描画する仕組み
babel-cliでサーバサイドでJSX記述を残したまま、実行時変換起動させる方法
Webサーバ(プロキシとして活用)、APIサーバとスケーラブルな構成のパターン
9章;特殊な問題を解決するためのパターン
・非同期に初期化されるもモジュールのrequire
ステートパターンを利用し実行リクエストをキューにため、非同期実行が完了してからキューのリクエストを実行する堅牢な作りの紹介
・非同期のバッチ処理とキャッシュの利用
・CPUバウンドなタスクの実行
setImmediateによるインタリーブ:cpuバウンドの処理のステップが完了するたびにイベントループに制御を戻す
マルチプロセスの利用:子プロセスへ移譲
10章:スケーラビリティとアーキテクチャ
複数プロセス利用、複数サーバ利用にしてスケールする
下記3つの観点でのスケールを考える。
クローニング:アプリをn回クローニングして各インスタンスに1/nの処理をさせる
サービスと機能による分割;機能、サービス、ユースケースで分割
データパーティションによる分割:データの一部を各インスタンスが分担して担当
水平分割、シャーディング
・クローニングと負荷分散
モジュールcluster
・バージョン0.11.2以降からラウンドロビン方式の振り分け
・障害時の再起動(zero-downtime restart)の実装
・負荷分散
ステートフルにしたいデータの共有問題
・共有メモリを利用した認証データの保存
・スティッキーな負荷分散(値判定で特定ノードへ割り振る)による特定なインスタンスへのマッピング
->問題点あり:インスタンスの代替が効かなくなる問題
リバースプロキシによるスケーリング
・ロードバランサとして機能するリバースプロキシ
・URLリライト、キャッシング、SSLターミネーション
・nginxをロードバランサとしてバックエンドにnodeのwebサーバを稼働させたパターン
サービスレジストリを活用し、最新の稼働サーバ情報を登録し、ロードバランサがその内容を参照するパターン
・nodeでの負荷分散装置の実装
ピアツーピア負荷分散:ロードバランサの処理量に依存させない方法:その分、接続方法は複雑になる
・サービスと機能の分割
マイクロサービスアーキテクチャのパターン
各サービスにデータ所有権があることがマイクロサービスアーキテクチャの特徴
正しいレベルの分離を独立維持するために、データベースも分割する
データベースを分割した分、システム全体の一貫性を維持するために、互いのデータを参照更新する多くの通信が必要になる。
クラッシュ、バグ、互換性を破る変更をシステム全体に波及させないようにする。
利点:
・再利用性向上
・スケールは、複数マシンに負荷分散。独立してスケール可能
難点:
・管理すべきノードが増えると、統合、デプロイ、コード共有が複雑になる。
・APIオーケストレーション層で複数のマイクロサービスのAPIを実行し、データを集約、処理する。
・メッセージブローかを使ったケース;フロントエンドのリクエストを受け取ったマイクロサービスが、関連するマイクロサービスにメッセージブローカを通して処理を行う
11章;メッセージ通信と統合
分散アプリケーションを統合する手段
・共有ストレージを中央の調整器兼情報の保持器として使う。
・メッセージを使ってデータ、胃炎と、コマンドを各ノードに行き渡らせる
メッセージ通信
・非同期メッセージと送信キュー:SMSのようなもの
・ピアツーピアメッセージ通信
・ブローカを使ったメッセージ通信:プロトコル間のブリッジにも利用できる、ブローカ
が単一障害になるデメリットはある。
パブリッシュ/サブスクライブ(pub/sub)パターン
分散オブザーバーパターンでもある
・ピアツーピア型Pub/Sub
・ブローカ型Pub/Sub
メッセージブローカにredisを適用したチャットサーバの分散スケール
ZeroMQを使ったピアツーピア型PubSubで分散処理するチャットサーバ
サブスクライバに障害が起きても確実にメッセージを送信できるような永続サブスクライバの実現
・多くのメッセージキューシステムが採用しているプロトコル:AMQP
ラビットMQを使用したAMQPによるチャットサーバ
パイプラインとタスク分散パターン
・ZeroMQのファンアウト/ファンインパターン
ハッシュサムを総当たりでしてアルファベットの考えられるすべての組み合わせを照合
するシステムで実践
ベンチレータ->ワーカー->シンク
・パイプラインとAMQPの競合コンシューマ
競合コンシューマ;複数のコンシューマが同じキューをリッスンし、メッセージをファ
ンアウト分散する
リクエスト/リプライ・パターン
・相関識別子を使用した、リクエストとリプライの紐付けで、リクエスト順序に影響しない
実装方法
付録A:ES2015以降のJavaScriptの主要機能
let, const:変数定義
アロー関数:=> コールバック関数を簡潔化記述できる
class構文
オブジェクトリテラルの改善
MapとSet
WeakMapとWeakSet
テンプレートリテラル
etc...
以上。
2020年1月12日に日本でレビュー済み
40代のプログラマーです。
ここ何年かはデータ分析のシステムの開発、運用に携わってきました。
ごく小さい、スピード重視のWebの開発、運用において、
GCP Firebase, AWS AmplifyなどmBaaSと呼ばれるサービスを採用した
案件が、まだまだ少ないもののじわじわ増えています。
それぞれのクラウドで提供しているサービス群をまとめて利用できる、
そのクラウドごとに囲い込まれたWebフレームワークというもののようです。
自分は、ここ何年かは、Webよりもバックエンドのビッグデータばかり関わってましたが、
自分が今いるチームのひとたちがFirebaseを使っているのを見て興味がでました。
mBaaSは、認証まわりは楽で、データベースまわりはつらいといった印象です。
Webでなくても、Visual Studio Codeのように、
UIの開発には、HTML + CSS + JavaScriptを使うという流れがあることもあり、
JavaScriptについては、UIの開発では必須というのはわかります。
しかし、サーバの開発はそんなにあるのか?と思っています。
ところが、mBaasでは、JavaScriptというかNode.jsでの開発、運用になるとのことで、
そちらの知識、経験がないので、まわりくどく要素技術の勉強からということで、
本書を手に取りました。
読んでみると、本書は、とにかく深いです。
1, 2章で基本を紹介して、続く残りの章で、それらの話題を
これでもかと深く説明しています。
Node.jsでの非同期については、
章が変わり、話題が変わったところで、何度も触れられています。
非同期だけでも、いくつもパターンがあります。
npmのパッケージ管理を使うと、(というか、どのプログラミング言語でもそうですが、)
依存する大量のライブラリがロードされて、
はじめぎょっとして、繰り返すうちにうんざりしますが、
このモジュールの仕組みついても、けっこう踏み込んだ説明があります。
ストリームについては、
大量のひとつづきのデータが絶え間なく次々というイメージだったので、
そんなのNode.js向きなのか?と思ったのですが、そうでもないらしい。
Webというのは、CPUバウンドではなく、IOバウンドであり、
Node.jsはもちろんIOバウンド向け。
おもえば、たしかに、今の職場の別チームが、
ログを取集する受け口のサーバとしてNode.jsをつかっていました。
なるほど。
ほかにも、なつかしのGoFのデザインパターンを使った例や、
運用面でのスケーラビリティのはなしもあり、
深さにも関わらず、幅広い話題について述べられています。
ただ、まー、オライリーの本らしい、わかりづらさもあります。
書いてある内容は緻密で興味深い。
しかし、自分が経験不足なことを気づかせてくれるものの、
体験させてくれるわけではない。
トラブルも含めて、何百時間か経験を積んで、断片的な知識も蓄えていると、
価値が跳ね上がる本だと思います。
自分は、まだまだ経験が足りませんが、
Node.jsの経験が多めのひとには、
よりおもしろく読める本ではないかと思います。
2022/09 追記
クラウドのサーバーレスのWebサーバの言語としては
現時点ではNode.jsよりpythonのほうが多くなったらしい。
Node.jsの価値がゆらぐわけではないけど、マジか。
ここ何年かはデータ分析のシステムの開発、運用に携わってきました。
ごく小さい、スピード重視のWebの開発、運用において、
GCP Firebase, AWS AmplifyなどmBaaSと呼ばれるサービスを採用した
案件が、まだまだ少ないもののじわじわ増えています。
それぞれのクラウドで提供しているサービス群をまとめて利用できる、
そのクラウドごとに囲い込まれたWebフレームワークというもののようです。
自分は、ここ何年かは、Webよりもバックエンドのビッグデータばかり関わってましたが、
自分が今いるチームのひとたちがFirebaseを使っているのを見て興味がでました。
mBaaSは、認証まわりは楽で、データベースまわりはつらいといった印象です。
Webでなくても、Visual Studio Codeのように、
UIの開発には、HTML + CSS + JavaScriptを使うという流れがあることもあり、
JavaScriptについては、UIの開発では必須というのはわかります。
しかし、サーバの開発はそんなにあるのか?と思っています。
ところが、mBaasでは、JavaScriptというかNode.jsでの開発、運用になるとのことで、
そちらの知識、経験がないので、まわりくどく要素技術の勉強からということで、
本書を手に取りました。
読んでみると、本書は、とにかく深いです。
1, 2章で基本を紹介して、続く残りの章で、それらの話題を
これでもかと深く説明しています。
Node.jsでの非同期については、
章が変わり、話題が変わったところで、何度も触れられています。
非同期だけでも、いくつもパターンがあります。
npmのパッケージ管理を使うと、(というか、どのプログラミング言語でもそうですが、)
依存する大量のライブラリがロードされて、
はじめぎょっとして、繰り返すうちにうんざりしますが、
このモジュールの仕組みついても、けっこう踏み込んだ説明があります。
ストリームについては、
大量のひとつづきのデータが絶え間なく次々というイメージだったので、
そんなのNode.js向きなのか?と思ったのですが、そうでもないらしい。
Webというのは、CPUバウンドではなく、IOバウンドであり、
Node.jsはもちろんIOバウンド向け。
おもえば、たしかに、今の職場の別チームが、
ログを取集する受け口のサーバとしてNode.jsをつかっていました。
なるほど。
ほかにも、なつかしのGoFのデザインパターンを使った例や、
運用面でのスケーラビリティのはなしもあり、
深さにも関わらず、幅広い話題について述べられています。
ただ、まー、オライリーの本らしい、わかりづらさもあります。
書いてある内容は緻密で興味深い。
しかし、自分が経験不足なことを気づかせてくれるものの、
体験させてくれるわけではない。
トラブルも含めて、何百時間か経験を積んで、断片的な知識も蓄えていると、
価値が跳ね上がる本だと思います。
自分は、まだまだ経験が足りませんが、
Node.jsの経験が多めのひとには、
よりおもしろく読める本ではないかと思います。
2022/09 追記
クラウドのサーバーレスのWebサーバの言語としては
現時点ではNode.jsよりpythonのほうが多くなったらしい。
Node.jsの価値がゆらぐわけではないけど、マジか。