【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/04/11(月) 16:28:34.52

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&;lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 3【io.js】(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1419673207/
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

**デフォルトの名無しさん** · 2017/06/04(日) 18:39:31.69

>>628
これ。typescript使ってるから正直どうでもいい。

**デフォルトの名無しさん** · 2017/06/04(日) 22:48:20.08

>>629
ts2.1でtarget es5でも使えるようになったしな

**デフォルトの名無しさん** · 2017/06/05(月) 21:13:25.69

nodeって起動するだけでメモリ相当食うから、バージョンアップでさらに増えてないかが気になる
安いプランのVPSだとメモリ1Gとかだから

**デフォルトの名無しさん** · 2017/06/05(月) 22:36:15.71

>>631
node起動するだけなら7MBしか食ってなかったぞ？

**デフォルトの名無しさん** · 2017/06/06(火) 09:07:00.80

>>632
v8が起動するんだからそんな少ないわけないだろw

**デフォルトの名無しさん** · 2017/06/06(火) 09:39:06.61

>>633
こんな感じのようだが？

http://qiita.com/shouta-dev/items/09d7055329710684d9c7

> process.memoryUsage()
{ rss: 9019392,
heapTotal: 5115392,
heapUsed: 2658096 }

**デフォルトの名無しさん** · 2017/06/06(火) 12:19:41.83

そりゃnode.js内のメモリ消費量でねーの
ランタイム内のプロセスと実行環境自体のプロセスを混同させるような>>634もアレだがな
だからWeb屋は

**デフォルトの名無しさん** · 2017/06/06(火) 13:46:28.87

ちょっとしたサービス作って待ち受けするだけで普通に数百MBは食うぞ

**デフォルトの名無しさん** · 2017/06/06(火) 13:56:30.47

ちょっとしたサービスなら200MB台で済んでる気が

**デフォルトの名無しさん** · 2017/06/06(火) 13:59:17.60

>>637
うん、実際そんなもんだよ
サービスによりけりだけど単位は百MBにはなるね

**デフォルトの名無しさん** · 2017/06/06(火) 15:37:19.98

えメモリ500MBのvpsじゃキツいのかよ!

**デフォルトの名無しさん** · 2017/06/06(火) 16:38:33.57

>>639
nodeやるなら512は実用的じゃないと思う
ssdならスワップ早いからなんとかいけるかもしれんが最低でも1GBは欲しい

**デフォルトの名無しさん** · 2017/06/06(火) 17:48:28.25

>>640
node起動するだけなら7MBしか食ってなかったぞ？

**デフォルトの名無しさん** · 2017/06/06(火) 17:53:37.43

nodeは依存関係の関係でアホみたいにモジュールロードあるからね

**デフォルトの名無しさん** · 2017/06/06(火) 22:49:25.44

>>641
条件は「nodeを起動するだけ」なんだからその程度だろうね。

>>642
そりゃexpressとか動かせばその分のメモリ食うさ
でもそれはrailsとかでも同じなわけで、なんのモジュールをロードするかとか
言ってない上、nodeを起動するだけのメモリ使用量しかわかるわけがない

**デフォルトの名無しさん** · 2017/06/06(火) 23:48:02.40

>>643
バカは黙ってた方がいいとおもう

**デフォルトの名無しさん** · 2017/06/06(火) 23:52:26.78

>>644
何も言い返せないなら黙っていたほうが良い

**デフォルトの名無しさん** · 2017/06/07(水) 00:17:35.99

7MB君ってほんとうにおめでたい脳味噌してるんだな

**デフォルトの名無しさん** · 2017/06/07(水) 00:20:57.96

>>643
socket.ioのみの簡単なサービスですら200M越えるんだが？
君はどうやって使用メモリを調べてるのかな？ん？
linuxコマンドでも書いてごらん

**デフォルトの名無しさん** · 2017/06/07(水) 00:22:10.32

>>631の文脈からして何らかのサーバー立てるんだからnode単体の話をするのは空気読めてないよね

**デフォルトの名無しさん** · 2017/06/07(水) 00:27:56.94

>>648
おまえはVPS借りてnode動かすのに何のサーバーもたてないつもりかな？んー？
で？
検証用のコードと7MBの確認コマンド公開まだかな？

**デフォルトの名無しさん** · 2017/06/07(水) 00:31:58.18

649はレス相手間違えた
この期に及んでnode単体という屁理屈で逃げてるやつは回答まだかな？

**デフォルトの名無しさん** · 2017/06/07(水) 00:32:13.23

>>647
たった5行でWebサーバーが書ける
http://engineer.recruit-lifestyle.co.jp/techblog/2015-06-22-node1/

httpモジュールを使っている分、nodeだけのメモリ使用量ではないが、
ps uのRSSの値は26000KB、つまり26MBだが？

**デフォルトの名無しさん** · 2017/06/07(水) 00:33:21.79

>>649
> おまえはVPS借りてnode動かすのに何のサーバーもたてないつもりかな？んー？

サーバーたてなくてもコマンド実行するという使い方もあるだろ？

**デフォルトの名無しさん** · 2017/06/07(水) 00:46:45.23

> nodeって起動するだけでメモリ相当食うから、バージョンアップでさらに増えてないかが気になる
> 安いプランのVPSだとメモリ1Gとかだから

>>631の文脈から言って、メモリを相当食う何かを動かしているのだろう。
だがそれはnodeの使用量ではなく、モジュールの使用量がほとんど。
nodeのバージョンアップでメモリ使用量が増えたとしても
大部分のモジュールの使用量は変わらないので、気にするレベルにはならない。

**デフォルトの名無しさん** · 2017/06/07(水) 01:45:14.18

メモリの使用量を抑えようと思ったら何を使うのが一番いいんだろうな。
やっぱgoとか？

**デフォルトの名無しさん** · 2017/06/07(水) 05:15:29.36

**デフォルトの名無しさん** · 2017/06/07(水) 14:14:41.23

Cは現実的じゃない
Goでおｋ
それかRust

**デフォルトの名無しさん** · 2017/06/07(水) 18:49:24.55

間を取ってobjc

**デフォルトの名無しさん** · 2017/06/07(水) 18:51:47.29

v8ってandroidでも動くようにしてるんだよね。新しいバージョンのほうが省メモリの可能性ないかな。

android goとか出してるわけだし

**デフォルトの名無しさん** · 2017/06/07(水) 21:06:02.29

v8のignitionは省メモリ、スモールフットプリントのためだから可能性は十分よ

**デフォルトの名無しさん** · 2017/06/07(水) 22:03:21.25

結局逃げちまってたかｗ

**デフォルトの名無しさん** · 2017/06/07(水) 22:28:48.05

v8がiosで動けばな

**デフォルトの名無しさん** · 2017/06/08(木) 13:07:07.77

久々に延びてるから良い話題期待したもれが間違ってたし

**デフォルトの名無しさん** · 2017/06/10(土) 23:18:03.35

>>661
v8じゃないけどnode.jsなら
http://www.janeasystems.com/blog/node-js-meets-ios/

**デフォルトの名無しさん** · 2017/06/13(火) 13:54:50.94

selenium使ってるんだけどnodeだとすんごい使いづらいな
他はpythonしか知らないけど

**デフォルトの名無しさん** · 2017/06/15(木) 14:45:14.68

中学生でもランサム作ってるんだから
それくらいがんがれ

**デフォルトの名無しさん** · 2017/06/21(水) 08:58:52.16

Windows10のユーザーフォルダでnpmにてnode-notifierと言うライブラリをインストールしたのですが
ユーザーフォルダ以外でnode-notifierを呼び出しても見つからずにエラーが出ます。

これを解決するにはWinの環境変数でPATHを通さないとダメなのでしょうか？
それとも呼び出し時に何か指定すれば良いのでしょうか？

**デフォルトの名無しさん** · 2017/06/21(水) 10:18:32.72

>>666
グローバルインストールっのがあるんじゃ？

**デフォルトの名無しさん** · 2017/06/23(金) 10:29:44.77

>>666
-g

**デフォルトの名無しさん** · 2017/06/28(水) 10:06:32.62

366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
https://twitter.com/yukihiro_matz/status/869061879389343744

367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/

372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな

376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
>>378>>379>>375
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。

**デフォルトの名無しさん** · 2017/06/28(水) 10:07:07.91

瑕疵担保責任（かしたんぽせきにん）

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しようその1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

**デフォルトの名無しさん** · 2017/06/28(水) 11:55:35.82

そのぶん金取るだけだよな
そんな主張もできない弱小は存在価値ないから他に吸収された方がいい

**デフォルトの名無しさん** · 2017/06/28(水) 16:29:31.80

>>671
マルチに反応するな

**デフォルトの名無しさん** · 2017/06/28(水) 21:25:29.27

>>670
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、有償で改修するだろう。

の間違いでは？
普通は不具合の修正に有償で対応する方を選ぶでしょ？

**デフォルトの名無しさん** · 2017/06/29(木) 03:44:27.70

app.jsみたいなフレームワーク固有のファイルって
どんな役割なのかもよくわからんし
何を書けばいいのかもわからないしすげえ苦手だ。
最低限何を書けば動くの?

**デフォルトの名無しさん** · 2017/06/29(木) 09:04:07.63

フレームワークのドキュメントに書いてあるんじゃないですかね…
書いてないなら使う価値がない(品質が水準に達していない)

**デフォルトの名無しさん** · 2017/07/08(土) 17:32:49.37

koa2ってどうよ？　使っているヤシ居る？

**デフォルトの名無しさん** · 2017/07/08(土) 21:12:14.30

触ろうと思ってサンプルプロジェクト作って中途半端に弄ってから半年経ったわ

**デフォルトの名無しさん** · 2017/07/09(日) 00:03:48.07

jQueryとかnode.jsとかデファクトスタンダードでみんなやってる感のやつはどうも食指が動かない
変わり者ですみません

**デフォルトの名無しさん** · 2017/07/09(日) 00:23:45.88

本当の変わり者は自分を変わり者とは言わない

**デフォルトの名無しさん** · 2017/07/09(日) 00:24:16.28

中二病やん

**デフォルトの名無しさん** · 2017/07/09(日) 00:29:34.35

nodeは一部の変態しかつかってないだろ？
スタンダードとかないわ

**デフォルトの名無しさん** · 2017/07/09(日) 00:36:10.71

>>678
それでは変わったことをやっている人が
みんなやってるものをやれば良いのでは？

**デフォルトの名無しさん** · 2017/07/09(日) 00:38:52.02

人と違うことが誇らしいお年頃～

**デフォルトの名無しさん** · 2017/07/09(日) 01:14:59.47

んなこと言ってるくせに変わったものなんか使ってないんだろどうせ

**デフォルトの名無しさん** · 2017/07/09(日) 02:41:44.02

自分から○○がやりたい！っていうのなら
それは前向きな意見であるが、

みんながやってるからやらない。
誰もやってないからそれをやるっていうのは
それをやりたいという意志がないので
後ろ向きな考え方だよ。やる気が無いといえる

**デフォルトの名無しさん** · 2017/07/09(日) 08:27:13.61

みんながやってるからやりたくない、はひねくれ者
気がついたらみんながやってることと違うことをやってた、てのが変わり者

**デフォルトの名無しさん** · 2017/07/09(日) 10:14:40.44

javascriptとかいうデファクトスタンダードの権化を使うのをまずやめるべきだね

**デフォルトの名無しさん** · 2017/07/09(日) 12:11:00.81

x86やARMも使ってはいけない

**デフォルトの名無しさん** · 2017/07/09(日) 12:43:30.36

インターネットを使ってるようじゃ変わり者ではない

**デフォルトの名無しさん** · 2017/07/09(日) 17:11:49.90

>>676
async await使ってるならむしろどんどん触るべきじゃないのか。
俺はgoでサーバサイド書いてるからあえて使ってないけど、
全部jsでやるならkoaかも

**デフォルトの名無しさん** · 2017/07/09(日) 18:30:24.07

express使ってても自分でミドルウェア書きまくるわけじゃないからな
標準のやらpassportやら使うだけだからasync/await使えて嬉しいことはほぼない
結局エコシステム揃ってる方を使う

**デフォルトの名無しさん** · 2017/07/10(月) 13:43:08.24

>>691
koaってexpressのミドルウェア使えたはず。
だからエコシステム的には問題ない。
とは言えasync-awaitもところどころ詰まるところはあるのは分かる
(例えばarrayのmapに渡す関数としては使えないとか。)

でも今から使うならkoaの方かな。

**デフォルトの名無しさん** · 2017/07/10(月) 13:46:50.96

expressのミドルウェア使うならexpressでええやん

**デフォルトの名無しさん** · 2017/07/10(月) 14:16:11.77

>>693
非同期処理を同期的にかける魅力には勝てない。

**デフォルトの名無しさん** · 2017/07/10(月) 14:57:56.02

691に戻る

**デフォルトの名無しさん** · 2017/07/10(月) 16:33:23.58

ｆ

**デフォルトの名無しさん** · 2017/07/10(月) 17:53:20.41

>>692
array.mapに非同期関数渡したいならrxjsで処理してtoPromiseすればおｋ

**デフォルトの名無しさん** · 2017/07/10(月) 18:48:24.41

>>697
いや。そもそもPromise.Allがmapと同義じゃんってわかったから
あえてrxjsは使わなくてもok

**デフォルトの名無しさん** · 2017/07/10(月) 19:17:56.48

まっ　CORE　ASP使っている身としては、koa2で十分なんだが、JadeからPugへの変更って必要だったのかえぇ～？　いまいちのような感じかする。
軽いCMSにkoa2は便利。　重いのもいけそうではあるが・・・

**デフォルトの名無しさん** · 2017/07/10(月) 19:26:02.76

>>699
jadeもpugも一緒だぞ
商標の問題で名前変えただけで

**デフォルトの名無しさん** · 2017/07/11(火) 16:15:40.20

koa2ってなに？koa.jsのこと？

**デフォルトの名無しさん** · 2017/07/11(火) 17:21:49.33

koe.js v2

**デフォルトの名無しさん** · 2017/07/11(火) 17:22:14.73

x koe.js v2
o koa.js v2

**デフォルトの名無しさん** · 2017/07/11(火) 23:24:55.50

あんましexpressもkoaも使ってるぜーって情報発信してる人いない気がする。
知らないうちにブロだクションで動いてるんかな

**デフォルトの名無しさん** · 2017/07/11(火) 23:54:59.61

expressってwebアプリケーションフレームワークって感じじゃないからな
rubyでいえばrack相当でrails相当じゃないから表に出ない

**デフォルトの名無しさん** · 2017/07/12(水) 00:05:15.88

expressはnode.js標準に付いていてもおかしくない程度の軽いフレームワークだしな

**デフォルトの名無しさん** · 2017/07/12(水) 01:08:53.04

ぶっちゃけ、express使うような案件だとphpでよくない？っておもっちゃう

**デフォルトの名無しさん** · 2017/07/12(水) 01:23:02.63

socket.ioとか使いたいからそれはないな

**デフォルトの名無しさん** · 2017/07/12(水) 03:27:41.84

>>708
おれもゲームサーバーでnode+socket.io使ってるけど、expressで配信するコンテンツってphpでよくね？ってパターン多い気がする
どうしても非同期じゃないと無理ってパターン以外は非同期のデメリットがでかすぎる
とくにDBがらみの単純な登録画面とかね
phpの数倍の開発コストかかるよ

**デフォルトの名無しさん** · 2017/07/12(水) 04:17:22.08

expressでdbアクセスなんてしてないな
bffとして使ってるから
node/expressの後ろのapi鯖はphpだったりrailsだったりjavaだったり

**デフォルトの名無しさん** · 2017/07/12(水) 04:21:26.67

>>710
ああ、そういう二段構えならokだね

**デフォルトの名無しさん** · 2017/07/12(水) 07:31:45.77

でもphpって1requestが1プロセスで高コストだから同時接続数を稼ごうと思ったらnode.jsの方が良いんじゃないの？dbがボトルネックだから気にする必要はない？

**デフォルトの名無しさん** · 2017/07/12(水) 07:33:23.93

それにasync awaitつかえば非同期処理はかなり自然に書けないかな？
学習コストは高くなるかもだけど

**デフォルトの名無しさん** · 2017/07/12(水) 08:32:57.14

async/await使いたいけど、LTSになるまで待ってって言われてる(´･ω･`)
TypeScriptはコンパイルしたくないって言われた、、、

**デフォルトの名無しさん** · 2017/07/12(水) 08:35:16.60

最終的にはアクセス増えたときのパフォーマンスの話になるんだろうけどそんなこと気にするレベルじゃない案件でわざわざ苦労してまでexpressでがんばる必要はないなと思う
必要な場面で局所的に使うのがnodeっていうイメージ

**デフォルトの名無しさん** · 2017/07/12(水) 11:37:51.18

phpだってさすがにスレッドぐらい使えるだろう

**デフォルトの名無しさん** · 2017/07/12(水) 14:22:08.20

非同期DB使えよ

**デフォルトの名無しさん** · 2017/07/12(水) 15:54:06.61

>>716
むっちゃしんどかった。
goを学習してgorutineで書き直したわ。

**デフォルトの名無しさん** · 2017/07/24(月) 09:12:28.43

express-resourceを使ってAPIサーバーを作りたいって考えているのですが
データベースへのアクセス手順を共通化したくなり、下記のようにしました。

class dbaccess {
　constructor(db) {
　　this.db = db
　}
　index(req, res, next) {
　　console.log(this) // undefined
　　this.db.find({}, (e,r)=>res.json(r))
　}
　// 以下略
}

app.use('users', new dbaccess(db))

1 APIクライアントからの GET /
-> this が undefined になっていてエラーになる

2 下記のコードからのindex()呼び出し
var dba = new dbaccess(db)
dba.index(null, null)
-> thisの内容が表示される

何か上手い解決策はないでしょうか。

**デフォルトの名無しさん** · 2017/07/24(月) 10:45:49.25

constructor内で
this.index.bind(this)でthisの束縛をすれば解決しませんか？

**デフォルトの名無しさん** · 2017/07/24(月) 15:05:38.54

うむ

**デフォルトの名無しさん** · 2017/07/24(月) 17:23:58.44

>>720
お答えいただきありがとうございます。
それを全部のメソッドにやるのも何かしっくりこないので、

下のようにクロージャにしてしまったら何とか期待する動作になりました。

function dbaccess(db) {
　let _db = db;
　return {
　　index(req, res) {
　　}
　　// 以下略
　}
}

クラスだと上手くいかないのがイマイチ納得できてませんけど。

**デフォルトの名無しさん** · 2017/07/25(火) 06:14:42.65

>>722
それが問題ならアロー関数をつかえば解決します。自動でthisを固定するんで。

**デフォルトの名無しさん** · 2017/07/25(火) 21:46:43.91

>>719
おいおい、変なことしないほうが良いぞ
もうちょっと調べるべきだろ？

他のプロジェクトでそんな書き方してるか？
昔やったきりで忘れたし今のやり方は変わってるかもしれないから
適切なアドバイスはできないがよ、他はもっと簡単な書き方してるだろ？

**デフォルトの名無しさん** · 2017/07/25(火) 22:27:51.60

>>724
http://qiita.com/kazusa-qooq/items/23926befcb87c0c7b26f
によると
req,res,nextの3引数を取る関数を作ればいいみたいね。
偶然にもクロージャーを使うというのは正解だけど
nextを省略してるってことは他のミドルウエアを後から追加したら
動かなくなる

こういうの見てるとtypescript使うべきって思う。
型でapp.useに渡すクロージャーを制約できるからこういう失敗がない。

**デフォルトの名無しさん** · 2017/07/25(火) 22:30:30.22

>>719
GCされてね？

**デフォルトの名無しさん** · 2017/07/26(水) 15:41:26.54

722です
一応、最小限っぽいコードを書いてみました。
http://www.dotup.org/uploda/www.dotup.org1319642.zip.html
users.jsからdbaccessを利用していますが、ここをtags.js, articles.jsと増やしていきたいって考えています。

>>724
本家のサンプルも利用者のblog記事なども一通り見たのですが、
見つかるは全部関数なので、そもそもクラスでの利用を想定していないのだろうと当たりを付けて
影響なさそうなクロージャにしてしまいました

>>725
ミドルウェアの追加は想定していない、クライアントコードなので特に支障はないと判断してます
本音を言うと、ただ書き忘れただけなのですけど。

**デフォルトの名無しさん** · 2017/07/26(水) 16:04:27.16

ちなみに、なんでクラスで書こうと思ったのかと言えば
クロージャとクラスのインスタンスが内部的には等価だと思っていたからです