「シンプルで拡張性が高く速い」を目指して DENGEN CAFE（電源カフェ）はGCP+GraphQL+Reactで作りました
DENGEN CAFE（電源カフェ）の再構築時に考えたこと
こんにちは。DENGEN CAFEの開発を担当した @morizotter です。普段はiOSの仕事をしていることが多いのですが、最近は、企画面やUXなどプロダクト全体を考えることに興味があり、そういうことをしていきたいと思っています！
この記事では、DENGEN CAFEのリブランディングにおいて、私がどんなことを考え、どんな選択をしたのかを書いていきたいと思います。プロダクトの裏側の話です。
もともと、Wordpressのサイトであった「電源カフェ」は7/21深夜に「DENGENCAFE」としてGCPとReactをメインとしたサービスに生まれ変わりました。まだ不安定なところも多々あるのですが、設計思想のにってちゃんと安定してくると思います！
サービスの構成全体を考えた時に重視したのは下記のポイントです。簡単にそれぞれ説明します。
ユーザーが欲しい情報にすぐにたどり着ける
ユーザーが最速で欲しい情報にたどり着いて、移動して、充電してもらうというサービスの理想の流れをサポートするために開発側でできることは、速く、シンプルで変更に強い作りを実現できる下地を作ることだと考えました。
関わる人が全てリモート
メンバーの全てがリモートで働き、稼働の日数も時間もバラバラという環境下で、どんなサービス設計が良いのか悩みました。できるだけコミュニケーションコストは下げつつ、一緒にやっている感やオウナーシップはみんな持っていた方が楽しいし、持続可能であると思います。シンプルな言語と構成にして、それぞれがそれぞれの領域を触れるけれど、他の領域にも簡単に入っていけるというのが良いと思いました。
自分ができることと全体として良いこと
自分が最初からできることはiOS周辺など限定されていました。ただ、それを軸に考えてしまうと、全体として最適な構成を考える際にミスをしてしまう可能性があります。サービス全体としての今後の方向性、持続可能性、関わる人のモチベーション的にも最適な選択は、自分の今までやってきていないことも含めて、アドバイスをもらったりしながら考えました。その中で自分が不慣れな部分はのちにリプレイスできる範囲で簡易的な構成にしたり、サービスにお金を払うことで対処しました。
今後の拡張可能性
サービスの今後の方向性を聞いていたので、その方向性をサポートするために足かせにならないような構成にする必要があると思いました。最近は、クラウド環境が発達しているので、フロントとのコミュニケーションはGraphQLにまとめて、裏側は拡張がし易いような構成にしようと思いました。
シンプルで簡単で拡張性が高く速い
それができればいいよねって話なのですが、真面目にこれを実現したいと考えてみました。さらに、章題に付け加えるとしたら「楽しい」です。やっぱり楽しく開発したいものです😉
これを元に構成全体を考えた経緯をざっと書き出してみます。まずは大枠を書きます。個別のことはまた別の記事で書くかもしれません！
Googleに乗る:主にバックエンド側の話
モバイルアプリはFirebaseを使うことは確定なので、使う。そうすると、AuthやPushやHosting、AnalyticsなどをFirebaseに任せられます。Firebaseを使うなら、もうGCPの一部なので、GCPを使うということにしました。AWSより利用されている件数はだいぶ少ないですが、Firebaseとの相性が良いのでとても楽になります。
そうなってくると、簡単にするために全てGCPに寄せたい。「Googleに乗る」という方針を立てました。これにより、Google Adminを入れ、ドメインのホスティングもGoogle Domainsに。さらに、Wordpressも（今は、オペレーション用でのみ利用していますが）Google Compute Engineに移し、サーバーはCloud SQL、リソースはCloud Storageに移し変えました。APIはGoogle App Engineを利用し、GraphQLを採用しました。GAEはオートスケールしてくれるので、インフラの知識がそこまでなくても管理コストを抑えて上手いことやってくれると思いました。デプロイ周りもブルーグリーン的に切り替えできるのでストレスも少ないです。
AWSの方ができることは多いと聞くこともあるのですが、私のようなモバイル出身のエンジニアがインフラまでカバーするとなるとGCPを選択するのが合理的なように感じます。コンソールが見やすく、触るのに抵抗が少ないというのも良い点です。
気になる料金の話ですが、だいぶお手頃に収まったと思っています。当初、Google Mapsがガンガンお金を使っていって焦りましたが、これは無料の地図に切り替えてなんとか回避しました。
GraphQL+Goを使って学習コストとストレスを減らす: API
GraphQLをどの言語で書くかは少しの間悩んでいていろんな人の意見を聞いたのですが、最終的に「あとでGoにリプレイスするなら最初からGoで書いたら良いのでは？」という意見をいただき、Googleに乗るという意味でもやってみるか！と、Goを採用しました。Goは初めて書いたのですが、学習コストが低くコードがわかりやすい（難しくなったりブラックボックスになりにくい）という意味でも趣旨に沿った良い選択ができたと思っています。
GraphQLはこれもまた色々リサーチした結果、スキーマから簡単に処理系を生成できる、 gqlgenを採用しました。このライブラリの主な特徴は、簡単なスキーマから処理系をジェネレートするということです。それ以外の通信のハンドリングや、リクエストが来た時の対応はgqlgenとは別の枠で独自でやる必要があるのですが、それはそれでシンプルでとてもわかりやすいと思いました。あまりGraphQLがどうとか考えずに、クエリで要求されたものを返すということに集中すれば良いからです。こちらも学習コストを下げることができたと思います。
GraphQLはドキュメントのようなものが自動生成できますし、それで動作の確認も可能。フロント開発するときも、それで簡単に動作を確認しながら繋ぎこむことができます。
GraphQLは変更のストレスが非常に少ないと思っています。特に、モバイルの場合、新しいバージョンをリリースしてもユーザーが切り替えるタイミングはまちまちです。その間にAPIの変更をどう扱うか。GraphQLは気楽に新しい口を増やすことができると考えていて、ある程度たったら古い口を削除すれば良いと思います。その辺りの設計のコストが下がることはとても良いと思いました。
Reactで少ない開発者での開発をカバーする: フロントエンド
WebフロントはReactを採用しました。モバイルはReact Nativeです。現状、開発者がすごく少ないし、稼働時間も少ないという中で、合理的な選択だったと思います（iOSと同じ機能をAndroidで、というのを少ないメンバーでやっていくのは結構ストレスだったりすると思います）。
WebのReactが書ければReact Nativeへのスイッチングコストはそこまで高くないし（面倒なことも多々あるのですが、それはサポートがあれば問題ないと思います）、逆も然りです。万が一の時に継続しやすいと思いました。
だいぶ枯れてきている感じもありますが、まだ現役です。「Googleに乗る」ということであれば、Flutterを使ってみたいところですが、まだ、自分としても選択できるほと自信がなく今回は見送りました。そのうち使ってみたいとは思っています。
GraphQLのクライアントはApolloを採用しました。今はおそらく一択くらいなので、選択肢はあまりない気もします。TypeScriptです。Apolloは周辺サービスとして、GraphQLの型を生成してくれるので、開発はしやすいです。これもApolloに依存することで独自のオレオレ仕様が発生しづらくなったように思います。
という感じで大まかな構成を考えていきました。完全にFirebaseやGoogleにロックインされていますが、それは積極的な選択ですし、今後、5,6年は問題ないと思っています。
今後のことと課題
課題はたくさんあります。突貫で仕上げたのでまだ基本的なユーザーエクスペリエンスが高くないので上げます。これは、すでに開発計画にのっているので順調に上げて行けるかなと思います。
さらに、Wordpressから完全に脱却できているわけではないので、データの集合である電源カフェ周りだけでも脱却したい。AirTableやGraphCMSなど代替候補は検討しているものの、Wordpressのプラグインを使い倒して、稼いでいるアクセスなどもあるのでそれを失わずに移行するのが難しいなどです。
一旦、リブランディングは済んだし、内部的に拡張しやすい構造にはなったのですが、今後さらに攻めていくためにはこの辺りを解決する必要があります。
もし、上記構成の選択や課題に関して興味を持っていただいた方は気楽にご連絡ください！
電源カフェ株式会社はリモートなどこれからの働き方を支援する組織です。そして、組織の形もそれに沿っています。気楽にアドバイスをもらえたり、協力してもらえたりするとうれしいです。
iOS：https://apps.apple.com/jp/app/電源カフェ/id782308388
Android：リリース予定
この記事が気に入ったらサポートをしてみませんか？