ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記

日本→シンガポール→ベルリンへと流れ着いたソフトウェアエンジニアのブログ

GraphQLを最速でマスターするための意識改革3ヶ条

GraphQLをサーバー側とクライアント側とで実装してみて得た意識すべきポイント3つについて。

  • ひとつのエンドポイント
  • バージョン無し
  • できるだけ薄く

この3つを意識して実装するのとそれが無いのとでは実装スピードが何倍か違うと思う。特にREST脳な人の場合。

GraphQLは使い所さえあえばめちゃくちゃに有用で面白い。しかもGraphQLの公式サイトはとてもわかりやすく説明されている。その辺のブログ記事よりもよほど洗練されていて、技術に関してはここ以外に読む必要はほぼ無い。

しかしGraphQLを使いはじめた当初はなんか妙にコーディングが進まなかった所があった。その原因はずっとRESTfulでやってきたREST脳の意識からGraphQLへと変換できていなかったことだった。GraphQLとRESTは設計思想が異なるので、意識を変える必要がある。その意識さえ変えればGraphQLに難しいところなんて無く、とてもカンタンに実装できてしまう。公式サイトに技術内容がどんなに分かりやすく書かれていても、このポイントを絞って意識を変えることに注力していなかったら「あれ??今まではこうだったのに、なぜだ?」となってしまうのだ。

そもそもGraphQLってなに?となっている人はこことか公式サイトを読んでください。

GraphQLを書いてみた話 - emahiro/b.log
GraphQLに関するメモ - ushumpei’s blog
GraphQLを使ってみた - kakts-log

以下はそのGraphQLの概念は分かっているという前提で書く。

【意識改革1】 ひとつのエンドポイント

GraphQLにエンドポイントはひとつしかない。RESTのように `GET api/v1/users` `POST api/v1/users/:id` とか一切無い。どんなリクエストも全て`/graphql` に向けて飛んでくる。GraphQLのクエリ言語がそういった処理を全て吸収してくれるからだ。クライアント側を実装していて「えーっとこのリクエストはどこに投げればいいんだっけ?」と思う度に、いやいや「どこ?」とか考えてる時点でそれREST脳だ、と自分で訂正していた。

個人開発したウェブアプリをGraphQLで実装していた時にある箇所のキャッシュとデータベース側の処理を2種類に分ける必要があった。そこで通常の処理を`/graphql` で受けて、その他の処理を別のエンドポイント(例えば`/graphql2` とか)で受ける設計を考えた。今から考えてもバカなデザインだったと思う。こんなことをするとGraphQLのメリットをちっとも活かせないし、メンテナンス性が著しく下がる。後からqueryやTypeが変更になった際にいちいち2つのエンドポイントとその挙動について考えなければならない。個人でやってたのでクライアント開発者とサーバー開発者の間でやりとりする必要は無く、自分の脳内で2役やって終わりだったが、あれをチームでやってたら、エンジニア同士の間でムダな話し合いが増えていたことが分かる。

GraphQLのメリットはクライアントーサーバー間で「この型でいきましょう」と決めただけで実装にかかれるところにある。後は欲しい情報を欲しい時にリクエストするだけで完了する。
公式サイトにはサラっとしか書いていないが「ひとつのエンドポイント」はとても重要なことなのだ。

【意識改革2】 バージョン無し

GraphQLは基本的にバージョンレス。つまりRESTのようなバージョンという概念は無い。RESTでやってるプロジェクトは`api/v1/...` からバージョンがあがるとクライアント側の実装と呼吸を合わせて、せ~ので`api/v2/...` とかを作ってリリースしていた。
理論上はうまくいくはずなんだけど常にこれが頭痛の種になる。だがGraphQLにバージョンは無い。`/graphql` というエンドポイントでv1もv2も無くずっとそのままだ。

これがREST脳だった私には不安だった。「え?バージョン無し???一応は念の為に付けとこうかな?」みたいに考えた。しかしこの質問と答えで気が付いた。「RESTのAPIになぜv1やらv2とバージョンがあるのか?」答えは「破壊的な変更があって、その度にバージョンを上げる必要があるから」と。
つまりは「GraphQLにすれば破壊的な変更は無いのでバージョニングする必要がない」となる。
クライアントが欲しい情報をリクエストして、そのままレスポンスを返すGraphQLでは基本的に変更をかけても破壊的ではない。今まであったfieldを削除するとかは破壊的かもしれないがGraphQLではadd-only approachを推奨している。つまり加えるのみ。

なので今回作ったrailsのルートはBest Practice にのっとり
`graphql POST /api/v1/graphql`
とかではなくて
`graphql POST /graphql`
としている。清々しい。対外的にも「バージョンは無いからな」と宣言することにもなる。
今までRESTfulでAPIのバージョンを上げることの痛みをずっとガマンしてきた人なら、このversionless APIという発想は気に入っていただけるだろう。

【意識改革3】 できるだけ薄く

GraphQLの作者Lee Byron氏も言うように「なんでもできるGraphQLだが、GraphQLはできるだけ薄く保つのがいい」と。Lee Byron氏の公演ビデオはとても示唆に富んだビデオで参考になる。そんな中で一番はこの「できるだけ薄く保て」という箇所だった。
実装していけば認証やらセッション管理やらありとあらゆる処理がGraphQLを通して行われる訳だが、それらをGraphQL内でやってしまわないこと。それらの処理をするのに適したクラスが必ずあってそっちでやるべき。
GraphQLの責務と役割はquery(RESTfulのGET)とmutation(POSTもしくはPATCH)だけであって、それ以外は無い。したがってresolve ->(obj, args, ctx)の中にロジックがあったら、その責務はどこが持つべきか考えてそこに移すべき、ということだ。
これはアプリのソースコードが大きくなればなるほど効いてきた。「薄くしといてよかったなー」と。

以上がGraphQLを最速でマスターするための意識改革3ヶ条でした。

動くGraphQLの実例

こちらがGraphQLとRails、React+Reduxを使って個人で開発したウェブアプリです。
エンジニアの集合知を図解するSNS「node-node-node」デスクトップ版
PCでしか見れませんが、ぜひ感想をお聞かせください。ぶっちゃけ、どう改良したらいいのか分からなくなってきたので「ここがダメなんだよ」とかなんでも言っていただけたらありがたいです。

情報ノードはパラっと開いて、グリグリとドラッグできる訳でして、こうして階層構造の技術リンクをマッピングしていけば理解しやすいかな、と。
f:id:tango_ruby:20180205204551g:plain

node-node-nodeについてなんでも感想や批評を書き込めるフォーム

少し前はいろいろとダメな点とかご指摘をたくさん受けて修正した。でもその修正が終わった途端、あんまりコメントをいただけなくなって辛いので、ちょっとでもコメントいただけたら嬉しい。

tango-ruby.hatenablog.com

www.youtube.com

tango-ruby.hatenablog.com

tango-ruby.hatenablog.com

イノベーションを後押しするのはシリコンバレー的文化で、それはとりあえず「スゲー!」と言っておくこと

個人開発ではあるが、なんとか公開にこぎつけたのはベルリンにあるシリコンバレー的文化があったことは紛れもない事実。そんな経験からアメリカのある特定の都市から革新的なIT企業が次々に現れる理由にはそういったシリコンバレー的文化が後押ししているんだろうな、と感じた。

個人開発においては開発者のモチベーションだけが鍵になる。納期も約束もなくただその開発者が「やってみるか」と思ってやる開発においてはそのモチベーションだけが原動力になる。そしてそのモチベーションは本当にもろくて崩れやすい。

  • こんなの作っても意味ないわ
  • これ公開しても誰もアクセスしねーわ
  • こんなしょぼいアプリを公開しても恥かくだけだ

といった思いはなんども開発者に押し寄せる。で、そういった思いが間違っていることはあまりなく、ほとんどの場合においてそれは正しい。
それでも何百万とある企画の中から0.0001%のキラっと光る企画で諦めずに改善を続けたモノだけが、脚光を浴びて大成功する。

ヨーロッパのITスタートアップ聖地と言われるベルリンに身を置いて感じるのは、良くも悪くもシリコンバレー的な考え方がひとりひとりに染み付いているな、ということ。それは端的に言ってしまえば、なにかよー分からん新しい企画や考えに出会った時にとりあえずは「オーサム」「ファンタスティック」「アメージング」などを連発してノリノリのコメントをぶつけておくこと。ぶっちゃけIT関連のアイデアはあまり素直に「スゲー」と思えないのが多い。今では成功が確定している企業ですらこんな感じだ。

  • ビデオが観れるウェブサイト(YouTube)
  • 24時間で消えるSNS(スナップチャット)
  • 写真がキレイに並ぶSNS(インスタグラム)

もしこれらのアプリが流行る前にこのアイデアを聞かされたとしても「スゲー!」「オーサム!」「ファンタスティック!!」とその先見性を予感して心の底から絶賛できる自信が私には無い。でもベルリンのITカルチャーにならって一応はそう言っておくだろう。なにが当たるか分からない時代にとりあえずノッておくのはまーまー大事なのだ。そしてこの「一応はノッておく」というのがこの都市の全てのITスタートアップに勤める人々の意識にデフォルトで入っているようだ。

言っておくが全てのヨーロッパ人がこんなノリな訳ではないし、アメリカ人にしても全てがヒャッハーな訳がない。その証拠に全米の全ての都市から革新的なIT企業が出てきる訳でもなく、限られたアメリカの都市が突出しているだけだ。

今回の私の個人開発でなんとかモチベーションを保てた原因は2つ。
公開前:プロトタイプを見せた時の職場の同僚や友人達の大袈裟でノリノリなコメント
公開後:アプリを使っていただいたユーザーからのフィードバック

断言できる。これらが無ければとっくの昔に頓挫していた。やったことがある人なら分かってもらえると思うが、自分が作ったものに対してちょっとコメントもらえるだけで、それがどれほどモチベーション向上になるか。それに「オーサム!」なんて言われてたら、そらやる気も出る。別にやたらと褒める訳でもない。特に技術者とかはノリノリではあるが、ダメ出しも強烈だ。

職場の同僚であるロシア人フロントエンドエンジニアのKは、私が個人開発したプロトタイプにあったReact+Reduxのソースコードを見て、ボロクソに言ってきやがった。バックエンドばかりやってきた私にとってフロントエンドはまだまだ知識が足りないのは分かっている。「それをそこまでメタクソに言うことは無いだろ」と思ったがそれでも嬉しかった。私の個人開発にそこまで熱を込めてダメ出ししてくれるKの熱意がまた私のやる気に火を付けた。ベルリンを包む空気が新しい企画に対してポジティブなのだ。

f:id:tango_ruby:20180228002741j:plain

都市はそこに住む人達が相互に作用しているのでひとりが「やってみるか」とやる気出してやったことが、他にも波及して、またそれがバイラルになって都市全体に波及していく。そういうエネルギーをIT都市ベルリンからはハッキリと感じる。

もしこれをお読みの方でご自身の住む都市をシリコンバレーに匹敵するぐらいのイノベーション都市にしたいと思ったら、カンタンにできることがひとつある。それは職場の先輩や上司であまり仲良く話す訳でもないし、ちょっと気を使うような関係の人が居たとして、その先輩が個人的に新しい企画を考案して「こういうの作ってみようかなと思うんだよね」と言った時にこう反応するのだ。

「えー先輩マジですか?それ。マジでー!それスゲーぇええ!!そんなの初めて聞いたわ!マジかよ!お前なー天才だわ!もう鼻血出るわ!てめー今すぐこの会社やめろよ!ヤメてそれやれや!天才のくせに時間ムダにすんなよな、おいボケ!そんな顔してザッカーバーグかと思ったわ、この天才!」

と言う感じでちょっとノリのいいリアクションを取ってみましょう。仮にその先輩のショボ企画がスベっても、そんな先輩の企画を見て触発された人や、そんなあなたの態度に触発された他の人達が「オレもやってみるか」と思ってきっとなにかアクションを起こす。そんな相乗効果は都市全体を包むはず。シリコンバレーなんて魔法の都市でもなんでもなく、結局はそんなひとりひとりの新しい企画に対するノリノリなコメントが大きく影響しているのでは、と思った次第。なので私自身も誰かの作ったモノをネット上でも見かけたらできるだけたくさんコメントするようにしている。

tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com

node-node-nodeに拡大縮小機能を追加した

node-node-nodeに拡大縮小機能を追加した。

たくさんノードを広げた後に右上の縮小拡大バーで縮小表示するとこのように見える。

f:id:tango_ruby:20180223060850p:plain

「拡大縮小ぐらいできるべきだろ!」とのご意見はたくさんいただいてたので実装した訳ですが、いかがですかね?

ちなみに自分で登録したノードは赤くボワーっと点滅している。なのでたくさんノードを作っていただいた方なら赤の点滅が多いとろこを見て「アタシってこういう分野にノード作ってきたんだ」と見て楽しんでいただければ、と。これは「投稿ユーザー」に気に入っていただける機能だと思って実装した。
白のノード(他人が作ったノード)しか見えてない方は赤ノード(ご自身のノード)をぜひ作ってみてください。
自分で言うのもなんだけど、この機能まーまー面白いし、楽しんで実装できた。

元々のアイデアは神経細胞がシナプス結合しているイメージだったんだけど、私は本職のデザイナーではないし、思ってることが形にできてないもどかしさがあった。でもこれとか見るとちょっと神経細胞っぽくて嬉しい。

f:id:tango_ruby:20180223065626p:plain

ただこれだけで爆発的にノードが増えるとも考えにくいので継続的に「投稿ユーザー」向けにいろいろ改善しなければ、と考えているところ。

こちらのフォームでご意見ご感想お待ちしてます。「なんかオレが思ってた拡大縮小と違うぞ」とかでもご意見ください。みなさんの意見がお聞きできるの、とても楽しいです。

エンジニアの集合知をノードグラフにして図解するSNS。
「node-node-node(ノード ノード ノード)」
 https://www.node-node-node.com/

tango-ruby.hatenablog.com