「GraphQLのmutationは動的にネストしたリソースを更新するもの」ではない
「参照系はGraphQLだけど、更新系はRESTでPOSTにします」みたいな意見を稀によく見る。 もちろん何かしらのトレードオフを考えてRESTを選択しているのだとは思うのだけど、GraphQLのmutation(要は更新系)を誤解している人も中にはいるのではなかろうか。
先日GraphQLのmutationは難しそう……という意見をもらって、詳しく聞いてみるとmutationについて誤解があるようだった。 もしかしたら同じような勘違いをされている方は他にもいるかもしれないなーと思ったのでまとめておく。
あーそれは多分誤解があるような気がしますね!mutationの方は投げるクエリを変えることで、動的に更新対象を変化させる……みたいなことは志向していないと思います。
— すーさん二号 11月は飲みません (@suusan2go) 2018年11月18日
ここの例のsetMessageをみてもらうと分かりやすいかと!https://t.co/Jq08v5n4x6
※実際、自分も何となくリソースの更新も柔軟にできるようなイメージを持っていたところはあった。
GraphQLとは
もはや色々な入門記事が溢れているので、詳しく説明することはしないが、 A query language for your API
と公式にあるように、以下のようなフォーマットでサーバーサイドとやりとりをすることで、柔軟にデータを取得することができるようになっている。
GraphQLでは参照系をqueryといいます。
query { hero { name # Queries can have comments! friends { name } } }
{ "data": { "hero": { "name": "R2-D2", "friends": [ { "name": "Luke Skywalker" }, { "name": "Han Solo" }, { "name": "Leia Organa" } ] } } }
GraphQLというとこの説明が多く、柔軟にリソースを取得できるというところがメリットとして語られる。そのせいか、なんとなく更新系も柔軟にいけるのでは?みたいなイメージを持ってしまうのかもしれない。
GraphQLのmutationとは?
RESTでGETでデータ更新することが基本的にはアンチパターンなように、queryでデータ更新を行うのは推奨されておらず、mutationというものを使う。queryの印象に引っ張られて、mutationも以下のようなフォーマットでネストされたデータ構造を一気に更新できる……みたいなイメージを何となく持ってしまいそうだが、mutationにはそんな機能は用意されていない。
# GraphQLにこんなシンタックスはありません!!! mutation { hero { name = "hoge" # Queries can have comments! friends { name = piyopiyo } } }
以下のようにRPC形式*1のフォーマットでmutationのリクエストは定義する。
mutation { updateHeroName(name: '太郎') { # 以下はあくまで戻り値として何を取得したいか hero { name } } }
上記の例でいうとupdateHeroName
の中で具体的に何をするのかは自分たちの実装に完全に委ねられている。要はどのデータを実際に更新するかは自分たちの実装次第であり、GraphQLが絡むのはリクエストとレスポンスの型だけとなる。これを見ると、タイトルにあるように 「GraphQLのmutationは動的にネストしたリソースを更新するもの」ではない ということが分かると思う。
戻り値となるJSONのレスポンスに必要なデータはqueryと同じく柔軟に決められるが、データ更新という側面に絞って言えばRESTと比べたmutationの明確なメリット・違いは、リクエストとレスポンスに型が付けられる(付けやすい)ことくらいかもしれない。
GraphQLでmutationを使う意味はないのか?
こうやってみると、GraphQLのmutationはqueryほど強力な機能をもっているわけではなく、あまり使うメリットが感じられないかもしれません。しかしながらGraphQLを使っていればGraphiQLといったツールの恩恵を受けられますし、参照系をGraphQLで作るならあえて更新系をRESTにする必要はないんじゃないかなーというのがちょっとだけGraphQLでAPIを作った自分の感想です。
GraphQLのmutation使えば型もつくしドキュメント等含めたツールのサポートもあるのに、あえて更新系はRESTに寄せたいという人をちょいちょい見るのは何故何だろう
— すーさん二号 11月は飲みません (@suusan2go) November 18, 2018
参照系ほどGraphQL使うメリットが大きくないというのはまあわかるけど、あえてRESTにするメリットもないような
*1:この言い方が正しいのかわからないけど
「レガシーアプリケーションのリニューアルにNuxt.jsで戦う」というタイトルでVue Fes Japan 2018 Reject Conferenceに登壇してきました
VueFesにCFPを出したんだけど、残念ながら採択されず・・・・・・だったのですが有り難いことにReject Conferenceに登壇させて頂くことができました。
VueFesで公開されている資料がすごいものばっかりだったので、発表資料の作成は本当に難儀しましたw いろいろ考えましたがVueFesで公開されている内容とかぶっているところは潔くそちらにフォワードする形式にしました。会場でもややウケだったのでまあよかったかなと思います。 Nuxt.jsでのTypeScriptは変そうという認識の方が多いようだったので、その辺りは皆さんの参考になっていれば嬉しいです。
VueFes本番は家庭の用事で行けなかったので、自分がスポンサーで申し込んだビールに対面できました!感動!(スポンサーしただけなのでデザイン等には一切関わってないですがw)
ついに本物をゲットしたぞ Vue Beer by M3
— すーさん二号 11月は飲みません (@suusan2go) November 10, 2018
(11月は禁酒) #vuefes_reject pic.twitter.com/iX1fJIZtuZ
また懇親会で、「弊社さん最近めっちゃイベントで見るようになりました(意訳)」と言われたのが凄く嬉しかったです。会社の対外的なプレゼンス上がってきてるなら嬉しい・・・・・・
来年もVueFesやるということなので、来年は採択されるようにVueを書き続けたいなと思ったのでした。やるぞー!
「チームが機能するとはどういうことか」を読んだ
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
- この商品を含むブログ (3件) を見る
一ヶ月くらい前にnaoya_ito さんの記事を急に思い出して読んでみたらとても良い事が書いてあった。この本は、資料の参考文献で強くおすすめされていたので買って読んでみた。
まとめ
プロセス知識スペクトル
この本で繰り返し言われているのは、仕事の中にも「知識の成熟度」と「不確実性」に応じてルーチンの業務、複雑な業務、イノベーションの業務 があり(本の中ではプロセス知識スペクトルと言われる)、それにより適切なチーミングと学習のあり方を変える必要があるということだった。新規事業のような不確実性の高い仕事と、書類仕事のような手順の決まりきった仕事では、当然ながら仕事の進め方や許される失敗は異なる。当たり前のことではあるのだけれど、自分の業務がどういう位置づけのものなのか、このような分類を意識して考えたことがなかったので新鮮だった。
心理的安全
今でこそ「心理的安全が大切」というようなことはよく言われているのだけれど、なぜ心理的安全が大切でそれによってどんなことが実現されるのか、といったことをきちんと説明してくれている。また心理的安全な環境を生み出すには、リーダーがどのような行動を取る必要があるのかということも記載されている。紹介されているリーダー行動のなかで、個人的には以下が特に重要なんじゃないかと思う。
- 現在持っている知識の限界を認める
- リーダーが自分もよく間違うことを積極的に示す
エンジニアに限らないけど、リーダーになるような人はプレーヤーとしても優秀な人が多く、チームメンバーからすると「とりあえずリーダーの言うことに従っておこう」となりがちなんじゃなかろうか(※自分はあまり思ったことないけど、そんな雰囲気を感じるチームは見たことがある)。
境界を超える
組織のなかでチーミングをするときによくある3つの境界として以下が紹介されている。
- 物理的な距離・・分離による相違
- 地位・・・格差による相違
- 知識・・・多様性による相違
個人的には知識による相違について説明している箇所に頷くポイントが多かった。設計・モデリングをするときに、登場人物の関連図やユースケース図を関係者でワークショップ的に作るということをやると、システムに対する理解度が圧倒的に上がって、その後の開発がとてもやりやすくなった経験があるんだけど、こういった図・試作品をバウンダリーオブジェクトというらしい。バウンダリーオブジェクトを使うことで、職業や専門知識による境界が取り払われやすくなるらしい。
フレーミング
またこれまで「目標はワクワクするものがよい」ということを何となく思っていたのだけれど、それはフレーミングというものだったんだなーということがよく分かった。
著者がMICSという新しい医療技術を導入するというプロジェクトを調査した結果、成功したプロジェクトはフレーミングが異なっていたそうだ。フレーミングとは一言でいうと「プロジェクトをどのように解釈するか」ということだと思う。成功したプロジェクトではリーダーが、新技術の導入を「患者の利益」「チームの能力を高める」といった目的で捉えていたのに対し、失敗したプロジェクトでは「世間に遅れをとらない」といった後ろ向きの目的で捉えていた。目標が前向きなチームでは「患者が少しでも早く快復する手助けするときのワクワクした気持ち」を感じたり、「自分たちの可能性を試す機会」とメンバーは考え、積極的にプロジェクトに関わり助け合っていた。
これは自分がちょうど最近まで関わっていたシステムリニューアルのプロジェクトがそうだったと思う。単純に「レガシーなアプリケーションがメンテ不能になったのでリプレースします」ではモチベーションを保つことが難しかったと思うが、「レガシーなアプリケーションをモダンな技術を使って社内外に誇れるアーキテクチャにしていく」という目標(まあ明にこんなことを言われてたわけではないのだけれど、そんな雰囲気はあった)があったからやっていけた感はあった。
感想
決して読みやすい本ではなかったのだけれど、最近よく言われていることが体系的にまとめられており、学びがあった。これを読んだ上で naoya_ito さんの資料を見てみると、あーこれはこの本からの話かーというのがいくつかある。naoya_itoさんの資料にも、文化を変えようとすることは悪手だと書かれているんだけど、この本にもまさになことが書いてある。
学習する文化は、新しい働き方―なおいっそう、相互依存し、ほかの人の仕事や必要性に気づき、向上しようとする働き方―を実践する副産物として現れるのであって、その逆ではない。
もっとこういう文化にしたい・・・といった話は大なり小なり今の組織でもこれまでいた組織でも上がってきたんだけど、結局のところ今目の前にある仕事をどのように行っていくのか、その働き方を変えていく、なぜ働き方を変える必要があるのか同意する、というプロセスを踏まないと文化は変わっていかないんだなー
特にソフトウェアエンジニア向けの本というわけではなく、本書の中の例でもソフトウェアエンジニアの例が出てくることは殆どない。スクラム・アジャイルといったキーワードも登場すらしていないんだけど、これらの文脈で出てくる話と類似するものが多いのはちょっと驚いた。
コンサルを超える問題解決と価値創造の全技法 を読んだ
- 作者: 名和高司
- 出版社/メーカー: ディスカヴァー・トゥエンティワン
- 発売日: 2018/07/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
普段はこういう本はあまり買わないのだけれど、新幹線に乗る直前でスマホの電池があと僅かだったので、暇つぶしのために買った。
感想
買う前の期待値が大分低かったせいか、すごく面白く感じた。特に分析や戦略を考える上でコンサルがよく使うらしいフレームワークについて、ある程度網羅して記載されているのがよかった。7Sとか社内で何回か聞いたことあったけど、マッキンゼーの手法だったのね。
単純にフレームワークを紹介するだけでなくて、そのフレームワークを使ってどのように問題解決を行っていくか書かれていたのもよかった。正直こういったフレームワークみたいなの、使っても何か自明じゃんみたいなことしか分からないことが経験的には多くて、あまり信頼してなかったけど現場で使うときの視点というか考え方がわかったのがよかった。
例えばMECE。そんなん見方によっていくらでも分け方あるし、なんならうまく分けられないことのが多いやんーと思うことが多く、MECEを徹底的にやることに何か意味があるのかと思っていた。本にはずばりこれについて書いてあって「MECEに分ける目的は、それを完璧に行うことではない。むしろ、うまく切れないところから、違う答えが見えてくるところにこそ、勝ちがあるのだ。」とあって感心した。
他にも、マトリクスで物事を捉える方法についてなど、フレームワークについて一般的な説明だけでなくて、それを使っていかに問題を捉えるかが割と実践的に書いてあったので、こういう本では珍しく仕事で活用するイメージが湧くものが多かった。
一方で、偉人的な昔話とか、マッキンゼー VS ボスコン的な話は、ちょっとアレな感じ……
コンサルが使う思考のフレームワークを網羅的に浅くどんな感じか知りたい人は、読むと面白そう。一方で、こういった本をいくつか読んだ事がある人にとっては一つ一つの掘り下げは割とあっさりしたものなので物足りない内容かもしれない。
meguro.rbで「rescueされない例外?!」 というタイトルで LTしてきた
(多分)台風で出社して疲弊していたsuusan2goは、疲れからかQuipper社のEMにMeguro.rbへの参加を勧められてしまう。
疲れに効くかもしれません、都合あえばいかがですかhttps://t.co/7b6kmGhAhO
— 広島の粗大ゴミ (@ohbarye) 2018年9月4日
というわけでLTしてきました。他にもネタはなくもなかったんですが、風邪引いてて1から作る気力がなかったので、昔ブログに書いた内容をLTにしました。
このブログを書くもとになったqsonaさんもたまたま来ていて聞いていただけて何か嬉しかった。自分のLTとは関係ないですが、当日のqsonaさんの「目黒のさんま」は名演でした。
他の方のLTの内容もバラエティに飛んでいてとても楽しかったです。1年ぶりくらいに会う方と話せたり、EM的な話ができたり、若干体調悪かったのですが楽しめました。 やっぱりこういう地域コミュニティがあるの本当によいことだなーと思う。また参加します。
「センスのいらない経営」を読んだ
- 作者: 福島良典
- 出版社/メーカー: 総合法令出版
- 発売日: 2018/09/07
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Gunosyの元代表取締役社長の本。 経営したい欲があるわけではないのだけれど、経営者と呼ばれる人たちがどんな思想なのかを知れるかなと思って買った。
感想
本の読者層を想定してか、機械学習やエンジニアリングまわりにそれなりの量のページが割かれていて、その辺は知ってる人からすると少し退屈かもしれない。
KPIの追い方とかその辺の話は、WEB系の企業にいれば大体経験のある話だとは思うので、そこまで真新しいことはなかった。
ただGunosyの過去の転換点(CMとか、PF構想とか、別アプリとか・・・)でどのようなことを考えて意思決定をしたか、その意思決定に対する振り返りは面白い。 確かにCM最初はこういう形式だったよなーとか、あの構想は結局ダメだったのかーとか、当時の自分が感じたこと(そこまで深く考えたわけではないけどw)への答え合わせになった。
「社内からは反対の声もあったけど、自分としてはもともとの理念からぶれたわけではない」といった表現が何度か出てきた。もちろん本心からだとは思うけれど、一方でそう自分に言い聞かせている部分もあるような気もして、社長として会社を前に進めていくのって大変だなーと思った(小並感)
NETFLIXの最強人事戦略を読んだ
- 作者: パティ・マッコード,櫻井祐子
- 出版社/メーカー: 光文社
- 発売日: 2018/08/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Twitterでよく見かけたので買ってみた。
感想
単純に読み物として面白く、一気に読んでしまった。いろいろと名言の宝庫で、たしかになーとは思うものの、これをいきなり普通の組織に持ち込んでも破綻しそうとも思う。実際、最後のほうでも「重要なのは段階的に実験を行うこと」と書いてある。試行錯誤していきながら、組織を進化させていくことが重要なのだろうな。
- どんなに過去に素晴らしい成果をあげた人材でも会社の目指す方向性の業務に適さない人には辞めてもらう
- 「それ直接いったの?」
- 匿名の調査は「匿名のときに正直になるのが一番だ」と間違ったメッセージを送ってしまう
- データ自体にはなんの意見もない。チームで意思決定をする際にはデータ分析から得た洞察を参考にするが、それに振り回されることはない
- 「データを読み取れるほどスマートで、データを無視できるほど直感力にすぐれた人材を探している」
- 仕事に対する真の揺るぎない満足感は、優れた同僚たちと真剣に問題解決に取り組んだとき、懸命に生み出したサービスを顧客が気に入ったときにこそ得られる
- 組織はいろんなスタイルの人に合わせることができる。カルチャーフィットは双方向に働く。
それでもNETFLIXで働くのはハードだろうなと思う一方で、こんな会社で働いてみたいなとも思った。