これは Frontend Meetup vol.1 - SPAを語り尽くす会! で飛び入りLTした内容を、(だいたい喋った内容に基づき)加筆、および修正したものです。
Today's Bikeshed
Web API (JSON)
キー名は?
- camelCase
- snake_case
経緯
FiNCでは・・・
- Backend ... Ruby on Railsがメイン
- 今まではsnake_case
- Client
- iOS ... Swift
- Android ... Java
- Browser ... JavaScript (React)
- (全てcamelCaseな言語)
経緯
- 複数のBackendをたばねるフロントエンドサーバ(BFF)を GraphQLを利用して作っている
- GraphQLはcamel前提っぽい雰囲気あり
- GitHubのREST APIはsnake_case
- なのに、新しく公開されたGraphQLのAPIはcamelCase
- フロントサーバは、透過的な感じにしたい
- GraphQLTypesは書いた上で
- Backendのレスポンスをそのまま通すイメージ
- すなわちcamelでくると嬉しい
- この機会に、今後作るAPIはこうと決めたい、snake/camel決着つけね?
stats
- 10以上のMicroservices
- 大半はRails
- すべてsnake_case
- もちろん、今後特定の技術にロックインされるべきではないが
今日のつぶやき on slack
-
クライアントはどうなの
- Javaはどっちでも良いっぽい
- JavaScript的には、destructuringとかがある関係上、使う変数名とキー名がそろってたほうが嬉しいことがある。そうするとcamel.
- Swiftも同じ感じっぽい
-
バックエンドはどっちでもOK & GraphQLサーバがcamelに変換、という選択肢は?
- フロントサーバが、変換の役目を持つことになる
- できればフロントサーバはあんまりバックエンドのことを知っていたくない、来たものをそのまま集約して返すようなサーバになっていたい。だからあんまりキーの変換表みたいのはもちたくない。
- フロントサーバで、snakeをcamelで自動で変換するのは
- 一つはパフォーマンスの問題が起こりうる。とくに再帰的にsnakeをcamelにする処理とかは結構重くなりがち。
- jsonをパースするときはどうせ文字列全体をなめてるので、「jsonをパースしながらsnake caseをcamel caseに変換するようなパーサ」があれば良いのではないか
- もちろんC++とか低いレイヤで実装する
- まー現実的ではない。
- snake => camel 自動変換だけど、ランタイムにスキーマを生成して、何回かリクエストしてるうちに速くなる的な何かを作ることはありうる気がする。
まとめ
はーbikeshed楽しい
camel or snake どっち派ですか?
結果
camelCase10人, snake_case8人. そして50%以上の人はどっちでもよさそう、
この結果は、社内での調査とほぼ同じ割合。