SlideShare a Scribd company logo
1 of 99
Download to read offline
サーバサイドNodeの使い道
自己紹介
名前 :pospome
ブログ:http://d.hatena.ne.jp/pospome/
職種 :サーバサイドエンジニア
最近 node を触ってます
なぜ node を使ってみようと思ったのか?
使い道が分からなかったから
Scala, Go のような PHP, Rubyに
代わる技術なのか?
socket-io によるリアルタイム通信が有名だけど
それだけの用途なのか?
ということで、「何に使えるのか」を説明します
といっても、2 ~ 3ヶ月しか触ってないので
正しい保証はないです
間違っていたらゴメンナサイ
その前に
Node はサーバサイドだけの技術というわけではない
用途1
Task Runner
ex. gulp, grunt
用途2
Desktop Application
ex. Atom Editor, Slack, VisualStudio Code
用途3
組み込み(IoT)
ex. Edison, Galileo
用途が広いという点がNodeの魅力の1つです
今回は「サーバサイドNode」について説明します
目次
・Nodeとは?
・Nodeの懸念点
・知っておくと便利なモジュール
・他言語との比較
・サーバサイドNodeの使い道
Nodeとは?
Nodeの特徴を知らないと使い道は分かりません
特徴を知りましょう
高速でスケーラブルな
ネットワークアプリケーションを簡単に構築できる
プラットフォーム
https://nodejs.org
スケーラブル(スケーラビリティ)とは?
利用者や仕事の増大に適応できる能力・度合いのこと。
一種の拡張性である。
https://ja.wikipedia.org/wiki/スケーラビリティ
Nodeは
同時接続数が多くなっても処理能力が落ちずに
高速で動作する
C10K問題を解決できる処理能力が特徴
その処理能力を支えるのが
イベントループ
+
ノンブロッキングI/O
イベントループの前に
イベントループと対になるスレッドモデルについて
説明します
イベントループと対になるのがスレッドモデル
スレッドモデルは接続数が増加すると
スレッドを増やして対応する
スレッドを増やす = サーバリソースの消費(C10K)
thread
thread
thread
イベントループは接続数が増加しても
1つのスレッドで順番に処理する
(キューにリクエストを格納するイメージ)
スレッドを増やさない = サーバリソースを消費しない
Req ReqReq
ただ、リクエストを順番に処理するので
1つでも時間がかかるリクエストがあると
処理が止まってしまう
リクエストが詰まらないようにする必要がある
確認してみましょう
Req ReqReq
サーバリソースの消費を避ければ大量接続に耐えられる
↓
イベントループがよさそう
↓
採用したいけど
時間のかかるリクエストを受けた時点で
他のリクエストを処理できなくなる
↓
「時間のかかるリクエスト」を解決したい
そもそもプログラム上の時間のかかる処理って?
I/O処理
ex. ディスク、ネットワーク
I/O処理は遅い
DBアクセス 外部APIアクセス演算 演算 DBアクセス
処理の流れ
I/O処理が発生しても処理を詰まらせないようにすれば
イベントループでもリクエストを処理できそう
そこで採用されたのが
ノンブロッキングI/O
ノンブロッキングI/Oを採用することによって
I/Oボトルネックが他のリクエストに影響することはない
ノンブロッキングI/Oの仕組み
内部的にワーカースレッドを複数持っていて、
I/O処理が発生すると
ワーカースレッドに丸投げし、
I/O処理が終わったらメインスレッドに結果を返す
確認してみましょう
Req ReqReq
Worker
Worker
Worker
I/O処理
ワーカースレッドの処理能力を超えたI/O処理が
発生した場合はI/O処理が詰まってしまう
のでパフォーマンスが下がる
ノンブロッキングI/Oだからといって、
無限にI/O処理をさばけるわけではなく、
限界はある
ワーカースレッドの数は以下で設定できる
UV_THREADPOOL_SIZE
設定可能な値は 1 ~ 128 だが、
大体はデフォルト値で問題ないらしい
ちゃんと試したことないので
最適な値は分かりません
http://arthur-notes.youramaryllis.com/2014/12/nodejs-event-loop-and-io-threads.html
http://stackoverflow.com/questions/22644328/when-is-the-thread-pool-used
http://www.future-processing.pl/blog/on-problems-with-threads-in-node-js/
ノンブロッキングI/Oが解決するのは
I/O処理だけです。
CPUに依存した時間のかかるリクエストは
どうしようもない
ex. 画像加工、高度な演算
これがNode(イベントループ)の弱点です
Nodeとは?
イベントループ + ノンブロッキングI/O の採用によって
大量の同時接続数に耐えられる
ただし、イベントループなので
CPUに依存した時間のかかる処理には向かない
Nodeの懸念点
Nodeの特徴が
実装するアプリケーションの仕様に合っているとしても
実際に採用するかは別問題
個人的なNodeに対する懸念点
1. 実際に使われているのか?
2. 動作が不安定な印象がある
3. 言語がJavaScript
4. コールバック地獄による可読性の低さ
5. DB, memcache, Redis とか使えるのか?
1. 実際に使われているのか?
採用企業
・GROUPON
・PayPal
・Walmart
・AWS Lambda
・Cyber Agent
Node.js Foundation の設立
Node.jsの開発を推進する中立的な団体
【参加企業】
IBM, Microsoft, PayPal, Fidelity,
SAP, Linux Foundation
結構実績あるし、
学んで損はないっぽい
2. 動作が不安定な印象がある
比較的新しい技術なので
既存の枯れた技術と比べると不安定かもしれない
ただ、採用事例も増えているので
最新の安定バージョンであれば
実用に耐えられる品質ではあると思う
↑
Nodeをプロダクトレベルで運用したことないので
何とも言えませんが・・・
3. 言語がJavaScript
今のJavaScriptには
クラス、インターフェースなど
他の言語に備わっている機能が存在しない
それっぽい書き方は可能だが、
JavaScriptの知識がないと
サーバサイドのドメインモデルを表現するのは難しい
ES2015でクラス構文が追加されたように
今後は進化していくと思います
そこでAltJSという選択肢
AltJS とは?
JavaScriptの代替となる言語
ex. CoffeeScript, TypeScript, babel, FlowType
AltJSで書く
↓
トランスパイルする
↓
JSコードが生成される
↓
生成されたJSコードをnodeで実行する
実際に確認してみましょう
AltJSを利用することによって
JavaScriptでは表現しづらい設計が可能
JavaScriptが得意ではない人でも
Nodeを書ける
当然ながらデメリットはある
デメリット
・トランスパイルされたJSが正しい保証はない
・実行されるのはトランスパイルされたJSなので、
 アプリケーションコードをAltJS上で
 チューニングするのは困難
結局トレードオフなので
考えて選択する必要はありますが、
ある程度はハードルが下がると思います
4. コールバック地獄による可読性の低さ
NodeはノンブロッキングI/Oによって
提供されるAPIのほとんどが非同期に実行されて
コールバックに結果を返す
ファイルの読み込み
fs.readFile('file.txt', function (err, data) {
console.log(data); //ファイルの中身を出力
});
以下は擬似コードですが、同期的だと以下のようになる。
var data = fs.readFile('file.txt');
Console.log(data);
ファイルを読み込んで、
その結果によって次の処理を進める場合
fs.readFile('file.txt', function (err, data) {
console.log(data); //ファイルの中身を出力
fs.readFile(data.fileName, function (err, data) {
console.log(data); //ファイルの中身を出力
//このようにどんどんネストが深くなっていく
});
});
これがコールバック地獄
nodeには同期的なAPIも存在あるが、
I/O処理をブロッキングして
パフォーマンスを下げてしまうので
好ましいとは言えない
コールバックはモジュールを使って解決できます
自分に合ったものを選択しよう
*ただし、最初は「見た目」に抵抗あると思います
・bluebird
・async.js
・Q
・co
5. DB, Redis とか使えるのか?
MySQL, Redis, Memcache は問題ありません
フレームワークもあります
Nodeはモジュールが充実しているので
既存のサーバサイドでできることは
ほぼできると考えていいのではないでしょうか
NPM : 約160000パッケージ
RubyGem : 約100000パッケージ
でも、事前に調べたほうがいいです
懸念点の説明は終わりです
少しでもNode導入のハードルが下がれば嬉しいです
知っておくと便利なモジュール
cluster
・シングルスレッドであるnodeは
 CPUがマルチコアだった場合は
 効率的に使い切れない
・それを解決するモジュール
・指定した数のプロセスを立ち上げて
 バランシングしてくれるので
 CPUを効率よく利用できる
・ただし、アプリケーションコードに記述が必要。
  http://nodejs.jp/nodejs.org_ja/api/cluster.html#cluster_cluster
pm2
・nodeのプロセス管理モジュール
・起動オプションをファイル管理できる
・ダウンタイムなしでrestartできる(graceful)
・clusterを内蔵しているので、
 指定した数のプロセスを立ち上げることが可能
・ちょっとしたモニタリング機能もある
 (恐らく使わないと思うけど・・・)
Log4js-node
・デバッグログ、エラーログなど
 種類毎に別ファイルに出力できる
logのローテーションは logrotate でやってます
WebGUIもあるので、
運用に関わるモジュールもある程度揃っています
他言語との比較
Nodeは大量の同時接続数があっても
パフォーマンスを落とさずに処理することができる
他の言語では無理なのか?
無理じゃない
Node, Scala, Go のベンチマークがネットにあります
結果はまちまちでしたが、
Go > Scala > Node
みたいな印象を受けました
同時接続数が多い場合はNodeが適しています
↑
別にNodeじゃなくてもよかった
Scala, Go でもいい
サーバサイドNodeの使い道
Nodeを採用する際のポイント
・CPU負荷の高い処理がない
・JSが得意な人が多い
・I/O処理が大きなボトルネックになるかもしれない
・socket-io を利用したい
・仕様が複雑ではない小規模のアプリケーション
フロントサーバとして利用する
・SPAでもサーバサイドレンダリングが可能
・isomorphic/universal によるコードの共通化
・フロントエンドとサーバのデプロイを分離
PHPNodeブラウザ
APIサーバとして利用する
・バックエンドのAPIを呼ぶだけのサーバ
・LBではできないコードでの柔軟なAPIコール
・クライアントAPIの入り口を1つにできる
・マイクロサービスとの相性もいい
・サーバはnodeにjsonを返すだけ。
Scala
Node Go
PHP
ブラウザ
&
アプリ
スモールスタートのアプリケーション
・最初はNodeでバックエンドを実装
・規模が大きくなった際に生じる機能追加は
 別のバックエンドサーバに実装する
・Nodeはバックエンド&APIサーバとして振る舞う
Node
Go
機能追加があった場合
ブラウザ
&
アプリ
大規模なアプリケーションにはあまり向かないので
既存のサーバサイド言語とは毛色が違う
例を3つ挙げましたが、
フロントエンドとバックエンドの間に置く
というのがポイントに思える
PHPNode
ブラウザ
&
アプリ
バックエンドから返されるjsonを
Nodeで画面用のデータに加工することで
バックエンドは画面をあまり意識せずに
ドメインモデルに注力したAPIを実装できる
PHPNode
ブラウザ
&
アプリ
例
アプリのマイページで表示する情報が欲しい
・ユーザーの名前、コイン数
・カードの種類
バックエンドが用意するAPIは2つ
・ユーザー情報取得用
 /user/id=xxx&field=name,coin
・カード情報取得用
 /card/id=xxx&field=type
Nodeでそれら2つのAPIを叩いて、
必要な情報をまとめて返すAPIを提供する
/mypage_info/id=xxx
アプリ側はこれを利用する
画面仕様が変更になって
ユーザーのscoreも欲しくなったら・・・
画面仕様に近いフロント側のエンジニアが
Node側を修正すればいい
バックエンドに作業は発生しない
・ユーザー情報取得用
 /user/id=xxx&field=name,coin,score
・カード情報取得用
 /card/id=xxx&field=type
Nodeを利用することで
アプリ、ブラウザが利用するAPIを1つにできる
バックエンドと画面仕様を切り分けて実装できる
ただし・・・・
フロントエンドとバックエンドの間に
Nodeを挟むことで
ネットワークのボトルネックは生じます
(どの程度かは環境に依存しますが)
クライアント側で
複数のAPIを利用してもらえるのであれば
不要かもしれません
切り分けても画面仕様に引っ張られることは
十分に考えられます
画面仕様と切り離した実装によって
複数のAPIを呼ぶよりも、
画面仕様に寄せた1つのAPIを呼ぶ方が
パフォーマンスは良い
万能ではない
ちなみに・・・
Nodeにはsocket-ioがありますが、
ソーシャルゲームのリアルタイム通信は
Photon, TNetを使うのがいいと思います
C# + VisualStudio は強力です
 反面、カジュアルなリアルタイム通信であれば
Nodeでいいと思います
Nodeはちょっとクセがある印象です
適切なケースで採用しましょう
Nodeを学ぶにあたって
フロントエンドDivの方に色々と教えていただきました
自分で学ぶより専門家に聞いたほうが早いこともある
コミュニケーションは大事
引用・参考
https://nodejs.org
http://satoshi.blogs.com/life/2012/10/closure.html
http://d.hatena.ne.jp/badatmath/20101020/1287587240
http://d.hatena.ne.jp/badatmath/20101022/1287701281
http://readwrite.jp/archives/2539
https://www.joyent.com/about/press/joyent-moves-to-establish-nodejs-
foundation
http://krdlab.hatenablog.com/entry/20110418/1303065920
http://stackoverflow.com/questions/22644328/when-is-the-thread-poo
l-used
http://stackoverflow.com/questions/30844537/what-happens-if-all-nod
e-jss-worker-threads-are-busy
http://www.modulecounts.com
おわり

More Related Content

What's hot

Dockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクルDockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクルMasahito Zembutsu
 
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装tnoho
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD増田 亨
 
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Takayuki Shimizukawa
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NETterurou
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)Koichiro Matsuoka
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAkihiro Kuwano
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?Teppei Sato
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知るShuhei Fujita
 
async/await のしくみ
async/await のしくみasync/await のしくみ
async/await のしくみ信之 岩永
 
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方Recruit Lifestyle Co., Ltd.
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?takezoe
 
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache FlinkIoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache FlinkTakanori Suzuki
 
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜Tomohisa Kusukawa
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計増田 亨
 

What's hot (20)

Dockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクルDockerイメージの理解とコンテナのライフサイクル
Dockerイメージの理解とコンテナのライフサイクル
 
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装
WebRTCを利用した遠隔リアルタイム映像処理フレームワークの実装
 
Marp Tutorial
Marp TutorialMarp Tutorial
Marp Tutorial
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
 
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
MQTTとAMQPと.NET
MQTTとAMQPと.NETMQTTとAMQPと.NET
MQTTとAMQPと.NET
 
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?君はyarn.lockをコミットしているか?
君はyarn.lockをコミットしているか?
 
イベント・ソーシングを知る
イベント・ソーシングを知るイベント・ソーシングを知る
イベント・ソーシングを知る
 
async/await のしくみ
async/await のしくみasync/await のしくみ
async/await のしくみ
 
分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方分散トレーシングAWS:X-Rayとの上手い付き合い方
分散トレーシングAWS:X-Rayとの上手い付き合い方
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
 
【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発
 
Lispマシン・シミュレータの紹介
Lispマシン・シミュレータの紹介Lispマシン・シミュレータの紹介
Lispマシン・シミュレータの紹介
 
IoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache FlinkIoT時代におけるストリームデータ処理と急成長の Apache Flink
IoT時代におけるストリームデータ処理と急成長の Apache Flink
 
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜工数把握のすすめ 〜WorkTimeプラグインの使い方〜
工数把握のすすめ 〜WorkTimeプラグインの使い方〜
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
 

Similar to サーバサイドNodeの使い道

Node.js Tutorial at Hiroshima
Node.js Tutorial at HiroshimaNode.js Tutorial at Hiroshima
Node.js Tutorial at HiroshimaYoshihiro Iwanaga
 
Nodeにしましょう
NodeにしましょうNodeにしましょう
NodeにしましょうYuzo Hebishima
 
Node-RED TIPS:functionノード間で関数を共有する方法
Node-RED TIPS:functionノード間で関数を共有する方法Node-RED TIPS:functionノード間で関数を共有する方法
Node-RED TIPS:functionノード間で関数を共有する方法Kazuki Saito
 
Node-red 10本ノック(visual recognition apiを絡めて)
Node-red 10本ノック(visual recognition apiを絡めて)Node-red 10本ノック(visual recognition apiを絡めて)
Node-red 10本ノック(visual recognition apiを絡めて)岡田 裕行
 
Node-REDでプロジェクト管理を始めてみよう!
Node-REDでプロジェクト管理を始めてみよう!Node-REDでプロジェクト管理を始めてみよう!
Node-REDでプロジェクト管理を始めてみよう!Koji FUNATSU,
 
Tokyo ruby kaigi 10 (sogabe)
Tokyo ruby kaigi 10 (sogabe)Tokyo ruby kaigi 10 (sogabe)
Tokyo ruby kaigi 10 (sogabe)Takashi Sogabe
 
Node.js を選ぶとき 選ばないとき
Node.js を選ぶとき 選ばないときNode.js を選ぶとき 選ばないとき
Node.js を選ぶとき 選ばないときRyunosuke SATO
 
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちました
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちましたゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちました
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちましたNaotaka Saito
 
Node.js×mongo dbで3年間サービス運用してみた話
Node.js×mongo dbで3年間サービス運用してみた話Node.js×mongo dbで3年間サービス運用してみた話
Node.js×mongo dbで3年間サービス運用してみた話leverages_event
 
Hokuriku.net 2013 01-26 node.js
Hokuriku.net 2013 01-26 node.jsHokuriku.net 2013 01-26 node.js
Hokuriku.net 2013 01-26 node.jsTadahiro Ishisaka
 
Node redをはじめてみよう
Node redをはじめてみようNode redをはじめてみよう
Node redをはじめてみようrina0521
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールdcubeio
 
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Takashi Sogabe
 
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?Makoto SAKAI
 
worker_threadsを使った実装の勘所
worker_threadsを使った実装の勘所worker_threadsを使った実装の勘所
worker_threadsを使った実装の勘所yo_waka
 
Xcode で gulp を使うお話
Xcode で gulp を使うお話Xcode で gulp を使うお話
Xcode で gulp を使うお話Yoichiro Sakurai
 

Similar to サーバサイドNodeの使い道 (20)

Node.js Tutorial at Hiroshima
Node.js Tutorial at HiroshimaNode.js Tutorial at Hiroshima
Node.js Tutorial at Hiroshima
 
Nodeにしましょう
NodeにしましょうNodeにしましょう
Nodeにしましょう
 
Node-RED TIPS:functionノード間で関数を共有する方法
Node-RED TIPS:functionノード間で関数を共有する方法Node-RED TIPS:functionノード間で関数を共有する方法
Node-RED TIPS:functionノード間で関数を共有する方法
 
Node-red 10本ノック(visual recognition apiを絡めて)
Node-red 10本ノック(visual recognition apiを絡めて)Node-red 10本ノック(visual recognition apiを絡めて)
Node-red 10本ノック(visual recognition apiを絡めて)
 
Node-REDでプロジェクト管理を始めてみよう!
Node-REDでプロジェクト管理を始めてみよう!Node-REDでプロジェクト管理を始めてみよう!
Node-REDでプロジェクト管理を始めてみよう!
 
Node js 入門
Node js 入門Node js 入門
Node js 入門
 
Tokyo ruby kaigi 10 (sogabe)
Tokyo ruby kaigi 10 (sogabe)Tokyo ruby kaigi 10 (sogabe)
Tokyo ruby kaigi 10 (sogabe)
 
Node.js を選ぶとき 選ばないとき
Node.js を選ぶとき 選ばないときNode.js を選ぶとき 選ばないとき
Node.js を選ぶとき 選ばないとき
 
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちました
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちましたゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちました
ゲートウェイにNode-REDを入れたIoTのシステムを運用して一年以上経ちました
 
Node.js×mongo dbで3年間サービス運用してみた話
Node.js×mongo dbで3年間サービス運用してみた話Node.js×mongo dbで3年間サービス運用してみた話
Node.js×mongo dbで3年間サービス運用してみた話
 
Hokuriku.net 2013 01-26 node.js
Hokuriku.net 2013 01-26 node.jsHokuriku.net 2013 01-26 node.js
Hokuriku.net 2013 01-26 node.js
 
Node redをはじめてみよう
Node redをはじめてみようNode redをはじめてみよう
Node redをはじめてみよう
 
Node.js Hands-On
Node.js Hands-OnNode.js Hands-On
Node.js Hands-On
 
Bp study39 nodejs
Bp study39 nodejsBp study39 nodejs
Bp study39 nodejs
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
 
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
 
Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介
 
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?
 
worker_threadsを使った実装の勘所
worker_threadsを使った実装の勘所worker_threadsを使った実装の勘所
worker_threadsを使った実装の勘所
 
Xcode で gulp を使うお話
Xcode で gulp を使うお話Xcode で gulp を使うお話
Xcode で gulp を使うお話
 

More from pospome

トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめトランザクションスクリプトのすすめ
トランザクションスクリプトのすすめpospome
 
MicroServices & APIs
MicroServices & APIsMicroServices & APIs
MicroServices & APIspospome
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるpospome
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?pospome
 
アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考えるアプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考えるpospome
 
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについてDatastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについてpospome
 
Goのシンプルさについて
GoのシンプルさについてGoのシンプルさについて
Goのシンプルさについてpospome
 
パッケージの循環参照
パッケージの循環参照パッケージの循環参照
パッケージの循環参照pospome
 
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについてControllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについてpospome
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツpospome
 

More from pospome (10)

トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめトランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
 
MicroServices & APIs
MicroServices & APIsMicroServices & APIs
MicroServices & APIs
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
 
どこに何を書くのか?
どこに何を書くのか?どこに何を書くのか?
どこに何を書くのか?
 
アプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考えるアプリケーションコードにおける技術的負債について考える
アプリケーションコードにおける技術的負債について考える
 
Datastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについてDatastore/Go のデータ設計と struct の振る舞いについて
Datastore/Go のデータ設計と struct の振る舞いについて
 
Goのシンプルさについて
GoのシンプルさについてGoのシンプルさについて
Goのシンプルさについて
 
パッケージの循環参照
パッケージの循環参照パッケージの循環参照
パッケージの循環参照
 
Controllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについてControllerのbefore_actionにおける インスタンス変数セットについて
Controllerのbefore_actionにおける インスタンス変数セットについて
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
 

サーバサイドNodeの使い道