@d_time いいよ エイム合わせてる
For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
ところでGraphQLでWriteが実現されてる現実のプロダクトをあまり多く見たわけではないんだが、実際のところどれくらいカスみたいな状況になっているものだろうか
なんか普通にHTTPのKeep-Aliveだけつけておけばいい感じになるような気がしてきた
我々は何も考えずにREST APIを実装すべきではなかろうか
というわけで、従来のRESTにおける複数リクエストを束ねるだけの機能を持つAPI層はなんですかね
HTTPの機能で実現したほうが良かったりしますか?
WriteにおいてはINSERT/UPDATEの発行回数と同じだけCREATE/PATCH Requestが飛ばされるのが設計上最もシンプルなので、コネクションを貼る回数だけを削減すれば良く、ネストされたオブジェクトの一括保存などは最も不要な機能
REST API書いてて「これどこからのリクエストだからフィールドからこれ消そう」とか、「このリクエストにはこの情報を付加しておかないと」とか考えるのあまりに不毛
GraphQLの嬉しさは、REST APIで発生しうるネットワークを跨いだN+1が削減できることと、不要なパラメーターをクライアントからの申告に基づいて削減できることにあり、これらの性質によってクライアントの要請に従ってバックエンドを複雑化させることを避けられるところにあると思う
API層がGraphQLだからどうとか、gRPCだからどうとかそういうことは全く興味がなくて、結局そこに価値があるかどうかだと思うんですよね議論可能なのは
あとはどれがやってみたいと正直に言えばいいのであって、我々は論文を書いているわけではないのでその合理性を誰かに認めてもらわなくたって構わない
本体ディスプレイ上の心拍数のログがなんか0:00~24:00まで常に表示されててそれはいつのデータなんだよって感じだし、アプリでデータ見ようと思ったら一ヶ月前のデータ表示されて、今日のはどこ?????みたいになる