そのAPIが時々しか呼ばれないならいいのですが、頻繁に何度も呼ばれるケースだとAPIのへのアクセスが複数回になり無駄が多いので、バルクアップデートみたいなことはできないか?と指摘を受けました。個人的には、「うーん、そうはいってもAPIってそういうもんでしょ...。」と思っていたのですが、他のサービスのケースとかを参考にしてみますと回答して、調査開始。1度のmutationで同じAPIを使い回すググると、バルク処理用のAPIを作れみたいな記事が見つかってコレジャナイ感があったのですが、遂に以下の記事を見つけました。blog.grandstack.iopath名をつけることで、同じmutationを複数回使うという方法です。以下のように使います。}}すると結果は以下のように返ってきます。}}おおお、1回のアクセスで3つ更新できた🎉バルク処理のエラー検知でもこれってエラーになったらどう検知するのよ?と思い、無理やりエラーが起きるようにしてみました。上記でいえば、存在しないuser_idを渡すとかです。}}そうすると、以下のような感じで返ってきました(実装次第ではありますが...)。]}errorsの配列の中のpathの値を見たら、どのpathでエラーが起きているかが分かるので、対処しやすくなるかと思います。所感1つのデータ更新用のAPIと、バルク更新用のAPIをわざわざ作らないといけないのかなー?🤔と考えていたところだったのですが、これならば実装1つでいけるので、大変やりやすいです🥳ただし、トランザクションが必要になるケースの場合は、バルク更新用のAPIを作らないといけないでしょう。16:58mutationでバルク処理をする場合のアプローチTweet広告を非表示にする関連記事2019-06-04再帰クエリを書いてみたまんまなのですが、再帰クエリを書いてみたら一発で処理がキマ...2019-04-12ActiveRecordのmodel名が〜Typeで終わるものをgraphql-rubyで扱うなかなか情報がなかったので、書いときます。releaseする前回の記事で、TravisCIからCircleCIに移行したことを書いた。(1)月別アーカイブリンクはてなブログブログをはじめる週刊はてなブログはてなブログProはてなブログをはじめよう!patorashさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。