GraphQLのMutationのビジネスロジックのエラーはどうハンドリングすればいいのか - taiyoh's memorandum
最近調査していた内容のメモ。 GraphQLのJSONレスポンスは data と errors の2つのキーに内容が大別される。 基本的に、期待するレスポンスが返せないときは errors にエラー内容が入るというのがGraphQLでやろうとしていることだが、特にMutationにおけるビジネスロジックのエラーはどう記述すればいいだろうか。 恐らくFacebook的には「ダメです！」とエラーダイアログを表示させて終了なのかもしれないが、世の中のサービスが全部それに倣っているということはなく、エラーとなった要素をクライアント側で特定して赤くしたりエラー文言を添えたりしたい、なんてケースはよくある。自分の担当しているサービスもそんな感じだ。 ひとまずRelayのドキュメントを開いてみる→ Mutations · Relay ざっくりと「レスポンスには（追加・削除含め）変更のあったTypeのオブ
Amon2のDispatcher::RouterSimple、個人的にこんなのだといいなー、という例 - taiyoh's memorandum
[追記] tokuhirom氏に「よさげ」って言ってもらえたので、調子にのってgithubに上げました（シーパン王サーじゃないので）。Amon2::Web::Dispatcher::RouterSimple::Extendedって名前にしております。::RailsLikeとかも考えたけど、関数名違うから混乱するのでやめ。そして自分の英語がひどすぎて死ぬ。あとモジュール名長すぎる。 https://github.com/taiyoh/p5-Amon2-Web-Dispatcher-RouterSimple-Extended [追記終わり] [追記2] gfx氏から「no strict 'refs';状態でガリガリ書くのはマズイ」という指摘を受けて、確かにそうだよなー、でも、submapperへの出入りでコロコロ切り替わるから、限定するのはムズいよなー、と思ったので、関数はある程度他所で定義す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
