トップ 最新 追記

2018-09-10 [長年日記]

_ 超今さらExpress触ってみた - その1 Expressって生々しすぎない? -

Express - Node.js web application framework

背景

  • これまでサーバサイド Node.js は callback 地獄に耐えられなさそうで避けてきてて、サーバサイドは基本 Rails 、インフラはフルマネージドに持っていくようにしてる
  • Webサーバと Rails と PHP はまぁそれなりに使える、JavaScript そのものを書くのは別にそんな困らないけど、Node.js 独自の事情はよく知らない
  • Google BigQuery の導入に向けて Google Cloud の Storage と Functions を使っていく作戦
    • Cloud Functions は調べ始めた段階で Node.js 6 のみ対応*1
    • HTTP-triggered Function は Express の req, res オブジェクトが渡ってくる

ということで Node.js 6 ベースで Express.js を書くというのが当面の目標で、最終的には Functions で動くようにしつつテストコードも書きたい、というところを目指していく。

以下は Express のドキュメントはほとんど読んでなくてあり合わせの知識で作業をしてたので変なことしてたら教えてほしいです。(こういうの書いててリアクションあったことほぼないんだけど)

まず普通に動かす

これはまぁ簡単。特に書くこともないけど、Node.js 6 前提なので、npm ではなく yarn で入れてみた。くらいかな。npm 5 が bundle されるのは Node.js 8 から、らしいので。

The npm Blog — npm@5 is now `npm@latest`

びっくりしたのはサーバの起動メッセージも何も出ないんですね…。

routingはアプリの中の事情であって環境の事情とは分けたい

サーバのセットアップとアプリの設定は分けたかったので、server.js と app.js に分けてみる。

app.js

const express = require('express')

const app = express()

app.get('/', (req, res) => {
  res.send('Hello Express')
})

module.exports = app

server.js

const app = require('./app')

app.listen(3000, () => {
  console.log('Starting server localhost:3000 ...')
})

これを

node server.js

で起動する。

なにもかもねぇのでmiddlewareを足す、が、

少なくとも Rails の development 環境にはあった

  1. request ごとのログ*2が自動的に出力される
  2. 変更に追随してコードを自動的にリロード

機能がない。これは割と致命的に不便。

ということで以下を追加。

ここで困った。と言うのも上で server.js と app.js を分けていたんだけど、middleware の記述はどっちかというとアプリそのものというよりは環境に近いので server.js に分けたい。ところが

const morgan = require('morgan')
const app    = require('./app')

app.use(morgan('combined'))

app.listen(3000, () => {
..

とは書けない。

どうも、

routing の後に middleware を追加しようとするのはダメっぽい。

はーなるほど。まぁ分からなくもないんだけど、そういうの、記述順に依存せずに動くような、Sinatra で言う configure block みたいなやつを用意してほしいなぁと思う。`Unopiniated` に反するのかもしれないけど。

ということで express の初期化を server.js 側でやって、routing を行う app.js に投げる形にした。

server.js

const express = require('express')
const morgan  = require('morgan')

let app = express()
app.use(morgan('combined'))

app = require('./app')(app)

app.listen(3000, () => {
  console.log('Starting server localhost:3000 ...')
})

app.js

module.exports = (app) => {
  app.get('/', (req, res) => {
    res.send('Hello Express')
  })

  return app
}

これを

nodemon server.js

で立ち上げると reload できるし、普通にログを吐く!

ちなみにNodemonについて

以下の記事を参考にした。

StrongLoop - Comparison: Tools to Automate Restarting Node.js Server After Code Changes

ちょっと古いけど、たぶんそう困らないんじゃないかな。

つづき

超今さらExpress触ってみた - その2 Routerと実際のRequest Handlerを分けたい - - あーありがち(2018-09-11)

*1 2018-07-24 段階で Node.js 8 と Python 3.7 が beta サポートされた

*2 logger で手動で吐くやつじゃなくて


2018-09-11 [長年日記]

_ 超今さらExpress触ってみた - その2 Routerと実際のRequest Handlerを分けたい -

超今さらExpress触ってみた - その1 Expressって生々しすぎない? の続き。

今回は routing と実際の request を処理する function を分離します。

Request Handlerをroutingから独立させる

前回のコードの中のアプリの部分は

app.js

module.exports = (app) => {
  app.get('/', (req, res) => {
    res.send('Hello Express')
  })

  return app
}

このようによくある routing に closure をそのまま渡す形のまま終わっていますが、これを router.js, index.js に分けます。(なぜ handler.js じゃないかは次回明らかになります。)

app.js 改め router.js

const IndexHandler = require('./index')

module.exports = (app) => {
  app.get('/', IndexHandler)

  return app
}

request handler には function reference を与えておくと、引数は勝手にいい具合に渡ってきます。

index.js

module.exports = (req, res) => {
  res.send('Hello Express')
}

ちなみに server.js はこんな感じ。

const express = require('express')
const morgan  = require('morgan')

let app = express()
app.use(morgan('combined'))

app = require('./router')(app)

app.listen(3000, () => {
  console.log('Starting server localhost:3000 ...')
})

app.js じゃなくて router.js を require してます、ってだけ。

これをやって何が嬉しいのか

Google Cloud Functions の HTTP Function は以下のような形をしています。

exports.helloGET = (req, res) => {
  res.send('Hello World!');
};

そうです。

HTTP Tutorial  |  Cloud Functions Documentation  |  Google Cloud

上の Handler だけを取り出したうえで名前付き exports になった形なのです。

ということで、残りは

  • handler を名前付き exports にする
  • そのうえでテストコードを書く

とやれば少なくとも ExpressJS のテスト周りの知見を Function の開発に活かせる、とまぁこういう寸法です。

つづき

超今さらExpress触ってみた - その3 Cloud Functions Emulatorでも動くようにする - あーありがち(2018-09-12)


2018-09-12 [長年日記]

_ 超今さらExpress触ってみた - その3 Cloud Functions Emulatorでも動くようにする

超今さらExpress触ってみた - その2 Routerと実際のRequest Handlerを分けたい - の続き。

Request Handlerを名前付きexportsにする

index.js

module.exports = (req, res) => {
  res.send('Hello Express')
}

が、こうなる。

module.exports.hello = (req, res) => {
  res.send('Hello Express')
}

あわせて router.js がこう。

const {hello: IndexHandler} = require('./index')

module.exports = (app) => {
  app.get('/', IndexHandler)

  return app
}

これで Express アプリ側は今まで通りに動く。

ES Moduleのimport asはObject Destructuringで

上の

const {hello: IndexHandler} = require(

は見慣れない書き方ですが、

  • module.exports は単なる Object Reference であり、named exports は単なる key-value の定義
  • (key を合わせて)そのまま { } で受け取れば名前の付け替えは自由
  • const { name } の書き方は単なる property shorthands

ということのようです。

ただし、さらっと書いたけど

Node.js ES2015/ES6, ES2016 and ES2017 support

によると Object Destructuring は Node 6 以降の機能っぽいので、Node 4 LTS では使えないかも。まぁ Node 4 LTS はすでに EOL を迎えちゃってるので、いまこいつを気にしなきゃいけない環境はまずいんですが。

nodejs/Release: Node.js Foundation Release Working Group

名前付きexportsをCloud Functions Emulatorにdeploy

Google Cloud Functions Emulator動かしてみた - あーありがち(2018-06-04)

を参考に、

functions-emulator start
functions-emulator deploy hello --trigger-http

すればできあがり。

これで Cloud Functions Emulator 側でもアプリを serve できている状態になる。

Request Handlerがindex.jsだったわけ

前回までで作った Express アプリですが、

index.js Request Handler
server.jsNode.js が立ち上げる Express アプリ環境
router.js上記以外の routing だけを担う

のような構造になっています。

LAMP 構成に慣れている人からすると node コマンドの引数に index.js を持ってきそうな感じがしますが、

gcloud と functions-emulator で共通に利用できる request handler のファイル名は index.js であり、かつ node コマンドに与えるファイル名は自由に変えられる

ので、あえて function を index.js に割り当てています。

ということで、ここまでで一応 Google Cloud Functions へ deploy 可能な Express アプリを作る型ができました。

つづき

超今さらExpress触ってみた - その4 やっとテスト書けるよ - - あーありがち(2018-09-13)


2018-09-13 [長年日記]

_ 超今さらExpress触ってみた - その4 やっとテスト書けるよ -

超今さらExpress触ってみた - その3 Cloud Functions Emulatorでも動くようにする - の続き。

Request Handlerを直接テストする

今回の目的は express アプリの end-to-end テストじゃないので、Request Handler である以下のコードだけをテストする。

module.exports.hello = (req, res) => {
  res.send('Hello Express')
}

さて道具立てはいつもの mocha, power-assert に加えて

howardabrams/node-mocks-http: Mock 'http' objects for testing Express routing functions

を使うことにする。

今回面倒くさいのは、単なる function のテストなのに function は何も return してくれなくて、引数に与えた res が変化するのでそれを見ろ、というところ。基本的に callback 地獄を避けてきたので、この辺のテストの知見がない。素直に function は return してくれとは思うが、そうもいかないので上のライブラリを利用する。

こんな感じ。

test/index.spec.js

const httpMocks = require('node-mocks-http')
const assert    = require('power-assert')

const {hello: IndexHandler} = require('../index')

describe('IndexHandler', () => {
  it('can handle request', () => {
    const req = httpMocks.createRequest({url: '/'})
    const res = httpMocks.createResponse()

    IndexHandler(req, res)

    assert.equal(200, res._getStatusCode())
  })
})

httpMocks.createResponse() で得られるオブジェクトは Express の response とは構造はだいぶ違うけれども、status や body など、欲しい情報を取得してテストを書くには十分機能してくれる感じがする。

似た機能を持つライブラリは実はたくさんあるんだけど、あまりダウンロード数がなくて作った本人とごく一部の人しか使っていないのでは?と思われたり、 Sinon に寄せすぎて素直にデータを取り出すことができなかったりするので、これくらいのものでよしとすることにした。

ということで、ここまででやっかいな Request Handler に対してテストを書けるようになった。あとは Google Cloud API を使わない部分に関しては普通の class や function と同じようにやればよいはず。

つまり、テスト書けるようになった!

Googleのユニットテストのドキュメントと比較

テストと CI/CD | Cloud Functions のドキュメント | Google Cloud

これを読むと Google さんは全部 Sinon の Mock で処理しろと書いてるんだけど、Mock って使いすぎると結局中の動作を別な形で書き換えただけになりかねなくて重い*1ので、できれば request と response の対応を、インターフェイスをテストする形にしておきたいので、上のような方法を選んだ。(こうしておけば中の処理が変わっても大丈夫。)

参考

Unit testing Express route handlers | Shesh's blog

*1 動作として重いということでなく、だいぶホワイトボックステスト寄りになって変更に弱くなってしまうので、存在として、資産というか負債というか、とにかく重い


2018-09-15 [長年日記]

_ 超今さらExpress触ってみた - その5 Loggerを改善する -

超今さらExpress触ってみた - その4 やっとテスト書けるよ - の続き。

背景

超今さらExpress触ってみた - その1 Expressって生々しすぎない? - で express の middleware として morgan という logger を導入したけど、これは HTTP request に応じて自動で吐くやつ。

expressjs/morgan: HTTP request logger middleware for node.js

今回は手動の方の話。

winstonにしてみる

今回の Express アプリの目的はあくまで Cloud Functions なので、log は Stackdriver Logging に送られることになる。

Stackdriver - ハイブリッド モニタリング | Stackdriver | Google Cloud

Stackdriver Logging に Node.js からログを送るライブラリとしてオフィシャルに紹介されているのは

Bunyan または Winston プラグインを使用するか、Node.js 用 Stackdriver Logging クラウド クライアント ライブラリを直接使用して、Node.js アプリケーションから Stackdriver Logging にログを書き込むことができます。

https://cloud.google.com/logging/docs/setup/nodejs

にあるように、

の二つ。

シンプルなのは bunyan の方だと思うのだが、winston は transport レイヤーをカスタムすることができ、logger から例えば Webhook や Mail で送信するといったことを手軽に実現できる機能がある。

今回はこれを期待して winston を採用してみようと思う。

組み合わせて試したのは以下のバージョン。

  • winston 3.1
  • logging-winston 0.9

実は、上の組み合わせは

undefined is a legacy winston transport. ...

と ERROR が起きてしまう。ただし、実際には動作する。という状態なので、安心したい場合は winston@2 系列と組み合わせるのがよいと思う。

最近のアップデートで 0.10.x 系で winston 3 対応している様子は分かるんだけど、中の依存で Node 6 がたぶん意図せず弾かれたり、ややこしい感じなので慌てない方がよさそう。

winstonを入れてみる

というわけで改めて必要なのはこれ。

winstonjs/winston: A logger for just about everything.

winston で logger を作る際の超基本的な構造はこんな感じになります。

logger.js

const winston = require('winston')
const logger  = winston.createLogger({
  level,
  format,
  transports
})

module.exports = logger

もうちょっと具体的に書くと、以下のようにしておけばとりあえず動く。

const winston = require('winston')
const logger  = winston.createLogger({
  level: 'info',
  format: new winston.format.simple(),
  transports: [new winston.transports.Console()]
})

module.exports = logger

で、index.js(function 側)では

const logger = require('./logger')

module.exports.test = (req, res) => {
  logger.info('ok')
  res.send('200 ok')
}

のように logger を呼び出して叩く。これで少なくとも functions-emulator では問題なく console に出力される。

この logger は morgan のような express middleware ではないので、function のコードで require していきなり使えます。

Cloud Functions用にlogging-winstonを追加

googleapis/nodejs-logging-winston: Node.js client integration between Stackdriver Logging and Winston.

Google Cloud Functions からは console が STDOUT だから自動的にログが Stackdriver Logging に流れてくれる、ようなことはない*1。そこで winston に Stackdriver Logging 用の transport を追加する。

const winton           = require('winston')
const {LoggingWinston} = require('@google-cloud/logging-winston')
..
snip)
..
const transports = [
  new winston.transports.Console(),
  new LoggingWinston()
]
..
snip)
..
const logger = winston.createLogger({
  level: 'info',
  format: winston.format.simple(),
  transports
})

module.exports = logger

てな感じ。

IAM Roleを足す

念のため、メモ。実際に Stackdriver Logging へログを送るには以下の permission ( Role )

logging.logEntries.create ( Logs Writer )

が要ります。ただ、Function に限って言えば Function の実行権限を持っていれば Logging への write 権限も普通はあると思います。

何が嬉しいのか

これで何が嬉しいかというと、とりあえず log level の記述が Stackdriver Logging の期待するものとだいたい一致するところ。

なんでここが気になるかというと、

ログを書き込む

Cloud Function からログラインを得るには、console.log か console.error を使います。

snip)

  • console.log() コマンドには INFO ログレベルがあります。
  • console.error() コマンドには ERROR ログレベルがあります。
  • 内部システム メッセージには DEBUG ログレベルがあります。

https://cloud.google.com/functions/docs/monitoring/logging

あれー、Warning とかどうすんだー? というのが気になったから。

もう一つ大事なのは format. 例えば timestamp を自動で入れることもできるし、すべての backtrace を入れた JSON ログ*2を作ることもできる。そのうえで Stackdriver Monitoring と組み合わせると、ログ → 監視 → 通知 → 対応(修正)をスムーズに行うことができるようになる。はず。

そのうち

Cloud Functions の外からでもこの組み合わせだけであれこれ ( Project ID とか ) 設定すればイケるんじゃないかと思っているので、今度試す。

*1 GAE とかはそうなってるはず

*2 Stackdriver Logging 用語では protoPayload


2018-09-24 [長年日記]

_ Node.jsのStreamのpipeの練習

(他の言語での成り立ちなど)Streamの概念的な話ではなく、とりあえず Node.js の Stream を使ったコードが動くまでが分かりにくかったので練習したよ、ってだけの話。*1

特に、例題として上がりやすいのはファイルを読み込みながらファイルの書き出しや HTTP レスポンスを返すとかそういうやつなんだけど、その説明は Node.js のよくある用途的には分からなくはないけど、自分の場合はそういうことよりもメモリの中身と stdout の方が分かりやすかったのでそれでやってみて、自分なりにまとめてみた。

※ 分かりやすさを重視してコードを触っていましたが、やはりダメでした。続きは StreamをEventHandlerを使ってPromiseに変換して成否を待ったり途中で止めたりする で。

Streamのメリット

大きなデータを小分けに扱うことができるので、Node.js の特徴であるシングルスレッド、イベントドリブン、ノンブロッキングI/Oの特徴を活かしやすい。

もちろんメモリ消費も抑えることができる。

Streamの種類

Stream には種類があり、以下の3つが基本。(Duplex はあえて省略。)

  • Readable
  • Writable
  • Transform
基本的な使い方と罠

誇張や嘘はあるかもしれないが、以下のように割り切っておくと分かりやすい。

  • Node.js では Stream は結局のところ EventEmitter である
  • Read Event が発生しないと次に処理が進まない

つまり、なんらかの出力を行いたい場合は最低でも Readable Stream と Writable Stream をワンセットで使う必要がある。

※ 出力を行わない場合は Readable Stream で渡ってくる chunk を淡々と処理するのでもよいが、今回はそれは扱わない。

メモリの内容をstdoutにstreamしてみる

最低限必要な準備はこんな感じ。

const {Readable} = require('stream')

const readable = new Readable()
readable.pipe(process.stdout)

これで「Readable Stream にデータが渡ってきたら STDOUT に出力するよー」という意味になる。

実は Node.js では process.stdin が Readable Stream で process.stdout が Writable Stream なので、Unix パイプを awk っぽく扱うのに向いている。ただし process.stdin を process.stdout に pipe するだけだと Node.js 要らないじゃんて感じになるので、あくまで Node.js の中のメモリの情報を stdout に出力してみることとする。

というわけで Readable Stream にデータを送ってやる。

readable.push("Hello World\n")
readable.push(null)

これでできあがり。無事に STDOUT に Hello World と表示される。

全体像は以下のようになる。

const {Readable} = require('stream')

// stream の構築
const readable = new Readable()
readable.pipe(process.stdout)

// stream にデータを流す
readable.push("Hello World\n")
readable.push(null)

もうちょっと本格的にメモリの内容をReadable Streamにする

実際には Readable Stream にわざわざ push しなきゃいけないシーンはないというか、こういう書き方は書く順番に依存しすぎてるし、おまじないじみててよろしくないので、実際にやる場合はもうちょっとなんとかした方がよい。

そこで以下を追加する。(似たような npm はいくつもあるが、これが人気っぽい)

memory-streams - npm

実際のコードはこんな感じになる。

const streams = require('memory-streams')

(new streams.ReadableStream(
  JSON.stringify({
    foo: 'bar'
  }) + "\n"))
  .pipe(WritableStream)

これで Writable Stream しか用意されていない pkgcloud/pkgcloud の Storage のようなものにもメモリから直接書き込むコードを分かりやすく書くことができるようになる。

ただし、メモリの内容を Stream で扱う際に注意しなければいけないのは、Stream は小分けに順番に処理するためのものなので、Array や String など順番が決まっているものしか扱えないということ。そのため上の例では Object を JSON に変換しているが、もし元の Object そのものが巨大な場合はその部分で小分けにするのは不可能である。

※ JSONStream という package もあるが、これはあくまで巨大なデータに対する JSON.parse を Stream ベースで行うためのものと割り切った方がよさそう。JSON.stringify を効率的に行うにはいずれにせよ Array を基本に置く必要がある。

参考

ついでにブラウザ周りも

ブラウザーは Fetch や XHR などの操作を完了前に中止させることができる AbortController および AbortSignal インターフェイス(つまり Abort API)に実験的に対応し始めています。詳しくはインターフェイスのページを参照してください。

2018-09-24 確認時点で

IE は非対応、Firefox は Stream には一部設定で対応、という状況らしい。

こういう微妙な差異をすべて開発者でフォローするのは大変つらい。

*1 例によって3, 4年遅れの話なんだけど、まぁ避け続けてた Node.js でこの程度の遅れならだいぶマシな気がしている。


2018-09-25 [長年日記]

_ Node6のテストコードでasync/await

先日からの続きで Node6 でコードを書いてるわけだけど、どうしてもテストの際には同期的に処理されてほしい before, after な辺りがあるわけですよ。

追加したもの

yortus/asyncawait: Callback heaven for Node.js with async/await

他にもいくつか似たようなライブラリはあるが、これを選んだ理由は

async () => {}

const {async} = require('asyncawait')

async(() => {})

と書けて、字面的に構文としての async/await に対していちばん違和感が少ないため。

これで

desribe('..', () => {
  beforeEach(async(() => {
    ..
  }))

  it('..', async(() => {
    ..
  }))
})

のように書ける。

除外したもの

eslint では test/ 以下を対象としないようにしておく。

eslint-plugin-node を使って async/await がコードに混入しないようにしている場合、ライブラリで追加した async/await も弾かれてしまうため。

テストコードに lint ... 要らないよね? ダメすか。

しかしこれ

同期的に処理されてほしいから async/await が欲しいと考えてるわけで、async とは?


2018-09-29 [長年日記]

_ StreamをEvent Handlerを使ってPromiseに変換して成否を待ったり途中で止めたりする

先日 Stream の練習をして分かった気になっていましたが、ダメでした。何がダメだったか。(そもそも普段 Node.js を書いていないのがダメなんだけど。)

  1. 「結局 EventEmitter」って自分で書いといて結果を同期的に「待って」いた*1
  2. Stream が Node.js 標準 Stream の Event Emitter を実装しているとは限らない

1 については今回は例によって Promise によって解決します。

2 は具体例を挙げておしまいです。ちゃんと調べろ、に尽きます。

StreamのEvent Listenerでエラーを取得する

Node.js Streams: Everything you need to know – freeCodeCamp.org

ここによくまとまっていて、

Stream#on('error', fn)

で書けそうなことが分かる。

(new Reable())
.pipe(new Writable())
.on('error', () => {
  ..
})

で書ける。ただし、取得して中に処理を書けるだけで返せない。ということは外から処理を与える callback 地獄だ。これは困る。

StreamをPromiseにしてエラー処理のクチを外に出す

イベントと callback が困るなら解決策は Promise になる。たぶん雰囲気はこんな感じだ。

stream2promise(data) {
  return new Promise((resolve, reject) => {
    (new Reable())
    .pipe(new Writable())
    .on('error', (err) => {
      return reject(err)
    })
    .on('finish', () => {
      resolve()
    })
  })
}

うん、なんかイケそう。

ところが実際にはすべての Stream でエラーは起きるし、'error' event そのものは stream 上を伝播したりしないし、'error' event が emit されても処理が止まるわけではないので、これでは不十分。

Stream | Node.js v10.12.0 Documentation

The stream is not closed when the 'error' event is emitted.

具体的には Reable Stream で 'error' が起きた場合でも stream 自体を cancel する人がいなければ Writable Stream の 'finish' event は emit されてしまう。ということは 'error' が起きようが何しようが resolve() が呼ばれる、つまり正常終了してしまうということだ。「'error' event は起きているが正常終了する。」これは期待する動作ではない。

Streamをちゃんと止める

そのためには各 Stream に対してきちんとエラー処理が必要ということになる。

ということでできあがりは以下のようになる。

stream2promise(data) {
  return new Promise((resolve, reject) => {
    const reable   = new Reable()
    const writable = new Writable()

    reable.pipe(writable)

    reable.on('error', (err) {
      reable.unpipe()     // 以降の Stream で余計な event が emit されないように
      return reject(err)  // 起きたエラーを reject に渡す
    })

    writable.on('error', (err) {
      return reject(err)
    })

    writable.on('finish', () => {
      resolve()  // ここに何を渡すかは思案のしどころ
    })

    reable.push(data)
    reable.push(null) // これは標準の Stream の API に従うとこうなる
  })
}

こんな感じ。

うーん、Promise は呼ぶ側はまだ比較的マシだけど、中身はアレな感じになりやすいねぇ。まー何はともあれ、これで以下のように Stream 処理を Promise で受け取れるようになる。

stream2promise(data)
.catch((err) => {
  ..
}).then(() => {
  ..
})

StreamのEventEmitter実装状況には注意が必要

例えば今回書いたコードは Node.js 標準の Stream を基本にしている。前回、「readable#push(null) とか普通書かないだろ」みたいなことを言っていたが、あれは間違いだったことが分かった。実は前回書いたコードでは今回のようなことはできないのだ。

前回は

を利用したが、

  • memory-streams.ReadableStream.on('end') は emit されない
    • ということは WritableStream.on('finish') も emit されない*2
  • process.stdout.on('finish') は emit されない

つまり、意図通りに正常終了を判定するのは難しいです。

また memory-streams と似たような機能を持つ

を利用すると stream 処理できない object を String に無理やり変換してしまうので [object Object] が Writable Stream に渡ってしまう。

「メモリの中身を Stream っぽく扱えるコードはすぐできそうじゃね?」と思っていたけど、自分がそんな発想をするくらいなのでやはりカジュアルなコードが多いみたいで、ちゃんと標準の API を使った方がいいなと思い直しましたとさ。

*1 以前 Promise を使って解決したのと同じなのに

*2 readが終わらないとwriteも終わらないようだ。実際の処理が終わっていてもこれを検知することができないし、もしかしたらモノによってはwritable streamの動作に支障が出るかもしれない。