データ形式

• 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. 別記事)