2020-07-10

データ形式

message interchange format
シリアライゼーション形式/serialization format

encoded messages

評価観点

speed: serialize/deserizlize time
size: serialized data size
representation: what format can represent (e.g. type, enum)

型の表現

0と"0"を異なる表記にするか
falseと"false"を異なる表記にするか

型は上位のスキーマレベルで解決すべきという考えもある.
fieldA: stringとスキーマで定義されているなら、fieldA: falseはconst fieldA: string = "false"しかありえない。
だから「このレイヤーに型は不要でオーバーヘッドを減らし高性能にできる」という主張

falseと"false"を区別すると、前者をbooleanに割り当てられた1byteで表現できたりする (e.g. MessagePack true = 11000011 = 0xc3)
JSONは峻別するけど文字列フォーマットなのでこの恩恵は受けれない.

Wire プロトコルとinterface

binary wire formatと.proto

wire format

wire formatは変数名を保持しない。変数識別intを保持する.
これのおかげで小さいsize、interface名のリファクタリングが可能.

protocol buffer encoding

一覧

JSON
MessagePack
Query parameters/Query strings
- 型がない。1も"1"もfield=1になる

schema+wireProtocolか、schema-lessか

schema/interfaceを前提とすれば、内部表現が自由になる (protobuf .proto & wire protocol)
同時にschema-lessだと「見てわかる内部表現」になっているのは逆説的な利点の1つ（内部が存在しない、ってだけなんだけど）
wire protocol使うとpayload単体を見てもほぼ利用できない
JSON payloadは見ればわかる。怠惰に使える.

自由に使える、マッシュアップ、相手方の厳密性は担保できない、みたいな思想が根底にあるwebだと「みりゃわかる」は強い誘因力を用いそう.
schema-less JSONが流行ったのはそれも一因？

完全に透過できていない内部形式ほど面倒なものはない、もあるんだろうな.
結局どこかで内部形式のデータをみたくなるタイミングが来てしまう。それが頻発してかつそのときのDXが悪いと、その領域では流行らない.

Utilities

Query parameters
- Global.URLSearchParams: QueryParam object. 取り込みや文字列化、Fetch Bodyへの挿入による自動content-typeなどいろいろこなす (c.f. 別記事)

2020-07-10

Fetch API周りの丁寧な世界

`URLSearchParams`

fetch Bodyにセットすると自動でContent-Typeをapplication/x-www-form-urlencoded;charset=UTF-8にしてくれる、安全。

To safely extract a body and a Content-Type value from object, run these steps:
... Set Content-Type to application/x-www-form-urlencoded;charset=UTF-8.
Fetch Living Standard

query parameterを使いたい（not JSON）のならばこのオブジェクト.
ToString()で文字列を吐けるので、POST BodyじゃなくてGET URL querystringにも利用できる.