GraphQLやめました
2020.05.27
当初Golang + GraphQLで作っていたAPIをRails + OpenAPIで作り直しました。なぜGraphQLで始めたのか、どうして作り直すことにしたのかなどを経緯とともにまとめました。
始まり
弊社では qrop という農家さん向けのサービスを鋭意開発しています。
私はAPI等のバックエンドの開発を主に担当しており、このサービスの開発を始める段階でAPIは GraphQL にしよう、という話になりました。
この時点でGraphQLである必要性はなく、詳しいメンバーがいたわけでもなく、新しい技術に触れておきたいよねという程度の理由でした。
せっかくだしGolangで開発しよう、インフラはGCPにしよう、という具合にその時やりたいことを詰め込んで開発はスタートしました。
新しい技術を学んでいくにあたり、最初はわからないことも多く詰まることもよくありました。それでもなんとか組み上げていくことの楽しさが苦労するより気持ちとして大きかったように思います。
移行を決めるまでの経緯
しかし、どこかの時点でこのまま開発を進めていくのは厳しいかもしれないと感じるようになっていました。
弊社は受託開発をしているので、基本的にメンバーそれぞれが複数のプロジェクトに関わっています。そのなかで受託開発に割り振るリソースが多くなり、どうしても社内プロジェクトの開発を先送りにしてしまう時期もありました。
その中で全体として技術のキャッチアップ、タスクの割り振りがうまくできず、求められる機能を実装する時間がどんどん大きくなってしまっていました。
このままだと開発コストはどんどん大きくなってしまうだろうなと思い、技術スタックを変更することを決めました。
これを決めた理由としては、ちょうどその頃別のプロジェクトで採用していた OpenAPI を利用した開発がチームとしてよく機能していたこともありました。
振り返り
移行したことについて
RailsとOpenAPIで開発するベースは別のプロジェクトでかなりできていたので、APIを作り直すことに関して困ることはほとんどありませんでした。
新しいAPIへの移行を優先したため、既存のGraphQLのAPIの開発はストップしてしまいましたが結果的に移行も大きな問題はなく完了しました。
今後の開発もスムーズに進めることができると思うので、移行したことは良い判断だったと思っています。
なぜうまくいかなかったのか
一つはチームとしてプロジェクトにフルコミットできていないことがあったと思います。
技術スタックの理解度もバラつきがあり、タスクの割り振りもそれに影響されていました。
さらに各々の担当するプロジェクトに割り振るリソースも時期によって変わるため、思ったような開発スケジュールに沿うことができていませんでした。
一定の開発リソースを確保するようにしようとはしていたものの、キャッチアップや認識合わせが時間の多くを占めてしまっていたようにも思います。
また、システムとしてどの程度の複雑さが求めらているかをよく認識できていませんでした。
仮にシンプルな機能で完結していたとすれば、GraphQLでやりきれていたと思います。
しかし当初の（私の）想定よりシステムに求められる機能が複雑であり、それを実現することがだんだん難しくなっていったと感じています。
新しい技術を採用する時にありがちかもしれませんが、「あるべき形」を求めすぎていたこともあったのではないかと思いました。
GraphQLの実装はこうあるべきだ、Golangでの開発はこうするべきだ、このような理想は様々にあるでしょう。
これらの理想を追うこと自体は悪いことではないと思いますが、そこにこだわりすぎても身動きがとれなくなってしまうこともあるように感じました。
慣れない技術スタックでどこが落とし所なのか見極めができていなかったことも原因だったと考えています。
新しい技術をどう取り入れるか
今回チームとしてGraphQLやその他の技術を新しく取り入れたわけですが、正直今の状態では開発のパフォーマンスを維持していくことは難しいと感じました。
しかし、GraphQLやその他の技術スタックの理解が深まったことなど良かった点もあります。
失敗したという経験もポジティブに捉えれば得たものといえるでしょう。
新しくプロジェクトをたちあげる場合、効率を考えれば現状でうまくいっている方法を採用するのが大体の場合いいように思いますが、一方で新たな選択肢を検討しないと幅を広げることはできません。
新しい技術に触れるのはエンジニアとして大事なことだと考えていますし、単純に楽しいと思います。
ただ、わかっているつもりではあったものの新しい技術を採用するにあたって考えることも多いと再認識しました。
- 開発に何が求められているのか
- スピード感
- 複雑さ
- 安定感
- 楽しさ
- チームとしてどうコミットするか
- 開発リソースの確保
- 責任の所在
その他にも色々あると思いますが、この反省を活かしつつこれからも新しい技術を取り入れる姿勢は失わないようにしたいです。
