ネイティブアプリからGraphQLを叩くときにどこまでパラメータ化するか - hitode909の日記

GraphQLを使って、ネイティブアプリにさまざまな集計方法のランキングを出す、というときについて考えている。 たとえば、ソーシャルブックマークアプリを作っているなら、「総合」「一般」「世の中」「政治と経済」みたいに、カテゴリごとのランキングを出すことがイメージできると思う。 どのようなqueryを用意して、どこまでパラメータ化するか、どこまで自由にするかによって、サーバークライアント間の責任分担や、その後の変更コストが変わってくる。 サーバーサイドで制御する rankings: [Ranking!]!みたいに、クライアントからは「ランキングください」とだけ送るパターンを考えられる。クライアントでは、Arrayの返ってきた順に画面上に表示する。 良い点 サーバーサイドでランキングの定義を持てるので、APIだけでなく、ウェブの画面に表示するランキングなど、他の面との仕様を揃えやすい 変更がサ

[itotto]

GraphQLのクエリーをクライアント側で組み立てるのってたぶんよくやられてるんだろうけど、SQLをクライアント側で動的に作ってるのと同じ気がして個人的になじまないというか自分が作るときはなるべく避けてる

[laiso]

“ リソースの潤沢にある側で改修したほうが全体的に見るとお得” シニアっぽい視点だ

[rararoro-ryo]

“ネイティブアプリのリリースが必要となり、審査を通すなど、サーバーサイドのリリースよりコストが高い場面が多そう” こんな開発チームに巡り会いたい。内製できないうちは無理なんだろう。

[wozozo]

federation

[mas-higa]

"古いクライアントがしばらく残ってしまう" 自分が作る立場なら共感するけど、使う立場なら ... アップデートの度に UI が腐って行く Instagram というアプリ、もうアップデートしたくないという気持ちになってる。

[kamocyc]

“ Federation” メモ

[hirata_yasuyuki]

「サーバーサイドで制御する」のやり方だとGraphQL使わずREST的なAPI用意する方が良さそうな。