# 2021-01-21 第2回メンターセッション

## Content-Type: application/x-www-urlencoded の時に設定すべきbodyのデータについて
1. 課題の書き間違い→書き直し済み
2. 問題ないが、見たことはない

## expressのres.end()について
- endを実務で使ったことはあまりない
- jsonとかsendでラッピングされている
- コネクション繋ぎっぱなしになるので、必ずsendかjsonなど呼ぶ（end）
- json -> send -> end の順にラップ
- sendは、引数に応じてContent-Typeを自動的に決めてくれる
- sendであればETagも自動生成してくれるのでHTTPキャッシュが有効に使える
- res.end(画像のバイナリデータ) ではブラウザに画像が表示されるが、res.send(画像のバイナリデータ)だとブラウザに画像が表示されない？？？
- sendは非同期でデータをクライアントに返す
- 画像の一部がレスポンスとして返され、その後の書き込みでエラー
- res.endはnode.jsのものをそのまま使っていて、node.jsのendは待機するような作りになっていた
- fs.readFileSyncで読み込んで

## request.bodyがなぜストリームなのか？について
1. について
- メモリを一気に使用せず効率が良い←これがいちばんでかい
- 抽象化←それもそう
- http/2から、「バイナリでそのまま使おうぜ」という発想の転換があった→いろんなところで並列に処理できるようになった
2. について
- （イメージ）
0. まずコネクションをはる
1. 小さなパケットで送る
2. どこかでかい領域に展開する
3. 実際に使うとき、展開した領域からサーバーにストリームで送る（一度にメモリに展開しなくてもよいようにしてるのかも）
4. 受け取ってる間はコネクションはりっぱなし
?. サーバーからブラウザに送られてくるときは？
→逆でも同じはず。ブラウザもディスク領域を持っているのでそこにちょっとずつ書き込んでいるのでは

## WebサーバーでHTTPレスポンスを作成するときに設定するContent-Typeヘッダについて

- 基本的にapplication/jsonで問題ない認識
- 外部サービスがurlencodedしか受け取らない場合くらいにしか使ったことがない(例：stripe)
- フロントエンド側がapplication/jsonに対応できない場合（レガシーなシステム）
- プリフライトリクエストを送りたくない場合は、urlencodedを使うこともあるかも？

## TypeScriptでExpressを実装する場合の、例外の型の扱いについて
- ほんとにわからないから、型が定義できないようにされている
- https://github.com/microsoft/TypeScript/issues/8677#issuecomment-220385124
- if(error instanceof MyError)
- assertionとcontrol flow?
- `hoge as string`だとhogeがstringじゃないときにランタイムエラーが起きる

###### tags: `Team-2`