Apollo Clientは便利だけど、考えるのが楽しいのはRedux

最近技術書典5に向けてApollo Client本を書いているのだが(【う03】で販売します！)知れば知るほど便利だな〜と感じている。

Apollo Clientはもはや単なるGraphQLクライアントではなくて、通信周りのいろいろをサポートしてくれるフレームワークぐらいに考えた方が適切だ。

と同時に、最近仕事ではRedux周りの技術選定や設計を考えていて「あれ？Reduxの方が考えてる時楽しくね？」と感じてしまっている。この記事はそんなフィーリングに対するポエムです。

Apollo と Reduxをなぜ比較しているのか

一応「同じ比較軸にないだろ○すぞ」と思われる方もいらっしゃるかも知れないので、なんで比較してるのかのスタンスを初めに述べておきたい。

結論から言うと、同じ比較軸にはないと思っている。

ただ、GraphQLがAPIとして存在する場合にApollo Clientを使うかどうかという判断があり、使うことになった場合にReduxを使う必要性が薄まる、というロジックの流れになると思っている。なのでApolloを使うことによって一部Reduxの役割と奪うことから比較をしている。

まずGraphQLのバックエンドがある時「そもそもGraphQLクライアントを使うのか？」という問いがある。まあ十中八九使うことになるとは思うが、別に必須ではなくGraphQLエンドポイント自体はHTTPでPOSTのbodyにクエリをつめるだけな話である(あんまり真面目に考えたことないけど薄いGraphQLクライアント + Reduxとかもあり得るのかも)。それで、最近のGraphQLクライアント界隈ではApollo一強感が出てきたのでおそらくApollo Clientを採用することになると思う。

そうなった時に通信周りの状態は基本的にApolloのキャッシュの機構にお任せすることになる。すると残るはローカルのクライアントステートをどう扱うかという話だが、この状態に対してだけReduxを用いるのはいささかオーバーエンジニアリングになるケースの方が多いのではないかと個人的には思っている(自分が作ってきたプロダクトたちにおいてグローバルなStoreに持たせたい状態がほとんど通信周りの状態だったので、偏りがある可能性は否定できない)。

こういった背景から「Apolloを使うとReduxは使わなくなる」可能性が高いという前提を持っている。

Apollo Clientはなにが嬉しいのか

GraphQLでのクエリ合成によりデータを成形したり、様々なエンドポイントを叩いたりする必要がなくなることももちろん嬉しいのだが、Apolloが提供している通信によって得られたデータをアレコレしてくれるAPIは本当によくできている。

例をいくつか挙げてみると

・ 勝手に正規化してくれる
     - 特に指定せずともスキーマとIDから一意に特定して正規化した状態で
        データを持ってくれてる
・loading, errorの状態をQueryコンポーネントが持っといてくれる
     - reduxとかでも通信の状態専用のreducerとか作れば別にそこまでめん
       どくさくないのだが、思考停止で設計なしで扱えるのは大きい
・Optimistic UIが簡単
     - Responseの形を記述するだけでOptimistic UIが簡単に実現できるのは
        地味に嬉しい

1個1個は地味かもしれないがこういった工夫が散りばめられていて、知れば知るほど感心し、状態管理のベストプラクティスが凝縮されたライブラリだなと思う。

でも考えるのが楽しいのはRedux

ただApolloを書いてて思うのが、あまり"状態管理"というトピックに対して真剣に向き合っている感覚がなくなったことだ。正直ガッツリプロダクションやスケール耐性気にするアプリで使った経験はないので、この感覚はそもそも間違っているのかもしれないが、Apolloが大体のめんどうごとを意識しなくてもやってくれているのであまり考えることはなくなる。

フロントエンドに携わっていて、一番頭を捻るのが状態に関する設計だと思う。本当に考えることが多い。

先ほどApolloの嬉しいこととしていくつか事例を挙げたが、あんな感じの粒度のトピックが無数にある。この部分の設計は分かりやすく開発生産性に直結するので、はじめにある程度要求やチームのレベル感を鑑みた上で「これくらいは必要そう」というラインを準備しておく。

これは面倒といえば面倒なのだが、とても楽しい。あーでもないこーでもないと一番ディスカッションしがいがあるポイントで、もしかしたら個人的にはフロントエンドやってて一番楽しい部分かもしれない。

この楽しみが大きいのがApolloとReduxどちらですか？と聞かれたら私は現状はReduxの方が楽しいなと感じた。Apolloは便利で、Reduxは楽しい。

まあReduxでも自分なりの「こういうプロダクトの時は、こういう設計」みたいな型をいくつか持っていたらさして変わらないのかもしれないが。

将来に対するちょっとした不安

ただ、この感覚はエンジニアの自己満足でしかなくて、仮にApolloが使える状況の時に、Reduxを選べるのか、選べるほどの価値を見出せるのかと言われるとちょっと怪しい。自分の趣味プロジェクトならともかく仕事で主張しきれる気がしない。

便利なもの、自分が面倒に感じていたものをバシッと解決してくれるソリューションが出てきたときはテンションが上がるのだけど、実はその面倒なものに対して頭を捻ることが楽しかったりして、ふと気がついたら自分が楽しいと思っている活動は非生産的で無価値なものになっているのかもしれない。10年後20年後のエンジニアリングのトレンドを果たして自分は楽しめているのだろうか、というそこはかとない不安を感じた。

ただ、こういうことずっと言っているといわゆる"老害"になってしまうと思うので、ちゃんと新しいパラダイムに適合していく努力はしていきたい。がんばろう。