💯

ぼくのかんがえたさいきょうの個人開発アーキテクチャで実際にサービスをリリースしたので振り返りをする

2022/01/17に公開

GraphQL

Next.js

React

idea

以前、以下の記事で個人開発に適した最強のアーキテクチャについて考えました。

上記で考察したアーキテクチャで実際にサービスを作ってリリースするところまでいったので、実際に最強だったかどうかをいくつかの観点から振り返ってみようと思います。

作ったもの

以下のサービスを作ってリリースしました。
一言で説明すると、ジーンズを好きな人が自分の育てたジーンズを記録することのできるサービスです。
https://www.denitz.net/

アーキテクチャ

以前書いた記事で紹介したアーキテクチャとは若干違いがありますが、それほど大きくは変わりません。

レビューの観点

次の5つの観点でレビューしていきます。
すべて開発者自身による自己評価なので、多少の甘さは大目に見ていただけたらと思います！

開発速度
保守性
品質
コスト
楽しさ

開発速度

開発期間はおよそ2ヶ月ほどでした。サービスとして提供している機能が少なめとはいえ、早めにリリースまでこぎつけたのではないかと思っています。
工数の割合としてはフロントエンド:バックエンド=7:3くらいです。
特に大正解だったなと思うのはGraphQLの採用です。
GraphQL Code Generator周辺ツールのおかげでコマンド一発でバックエンドのスキーマの変更に追従できる、クライアントの型の生成ができる環境がお手軽に作れます。
GraphQLのメリットは他にもあると思うのですが、「クライアントの型を簡単に自動生成できる」というのが個人的には一番ありがたく、それだけでもGraphQLを使う価値があると感じています。
個人開発に必要な初速は出せたので、開発速度については十分良いと思います。

保守性

フロントエンド、バックエンドともにフルTypeScriptで作っています。
そのため、開発中にランタイムエラーに遭遇することがかなり少なかった気がします。
コードに変更を加えて不安なとき、yarn type-checkで型エラーを検知できる体験はもう手放せないです。
一つ気になる点としては、テストを全く書いていないことです。Lintと型チェックで最低限の秩序は保てているはずですが、急いだあまりテストの実装をスキップしてしまったのは良くなかったと思います。

品質

これに関しては、これからユーザーに使い込んでいってもらう中で分かっていくことが多いと思います。
現時点ではバグや、パフォーマンスの問題などはあまり出ていません。
パフォーマンスについてはLightHouseでトップページを計測してみました。

まずまずといったところでしょうか。

コスト

料金が発生するのは、画像を置くAWSのS3とバックエンドのApollo ServerをホストしているGCPのCloud Runだけです。
DBについてはHerokuの無料枠のPostgresを使っているのでタダです。
できるだけお金をかけないことがテーマの一つでもあったので、ここはだいぶお財布に優しい設計にできたと思いっています。

楽しさ

個人開発なので楽しさは重要な指標です。
今回の開発では自分が最強だと思うアーキテクチャで試行錯誤しながら進められて、最終的にリリースまで行くことができたのでかなり楽しく開発できたと思います。
コードを書くこと以外のことでストレスに感じること（UIで悩んだりインフラで悩んだりとか）があまりなかったので快適でした。

選定技術・ツール等をピックアップ

特に開発効率の向上に寄与したライブラリやツールについて言及します。

Next.js　on　Vercel

SEOが必要な環境でReactのフレームワークと言ったらこれしかないのですが、（Remixは開発はじめた時点ではまだ公開されていなかったので）Vercelに載せて使うNext.jsは快適だなと思います。
特にありがたいのは画像最適化の実装を何もせずに済むことです。自前で画像最適化の仕組みを用意しようとするとそれなりの工数が必要となるため、フレームワークレベルで画像最適化をサポートしてくれているのは嬉しい点です。
SEOが必要なくても、画像をたくさん使うサービスでは画像最適化で楽をするためにNext.jsを選択するのもありだと思いました。

Chakra　UI

UIの実装を最低限に抑えるためにChakra UIを使いました。
Chakraは、Muiよりもかゆいところに手が届くコンポーネントやhooksが用意されていいる印象です。
また、スタイリングもpropsで行えるため、生のCSSを全く書かずに済みました。
CSSで疲弊したくなくて、デザインが自分でコントロールできる環境の場合はChakra UIを使うと楽ができます。

React Query

GraphQLとReact Queryを合わせて使うことでデータフェッチとサーバーstateの管理を容易に行うことができます。
GraphQLとReact Queryを合わせて使う方法については以下の記事を読んでもらうとイメージしやすいと思います。

React Queryを使う最大のメリットは、クライアントのstateにサーバーからフェッチしたデータを出し入れするコードを書かなくて済むようになることです。
単純にコードの量が減りますし、状態の更新処理も簡単になります。Reactを使う場合は特にuseEffectの使用量がめちゃくちゃ減ります。
React QueryやSWRのようなサーバーの状態をうまく扱うためのライブラリを使うときは、キー管理がサーバーstateの管理に直結します。
キー管理をうまく扱う方法については、React Queryのメンテナの方が書いている以下の記事が参考になります。

Apollo Server

GraphQLサーバーをたてる方法として選択肢にあがっていたのは、Hasura、Apollo Server、Nest.jsです。
個人の意見ですが、この3つの中で最も覚えることが少なく、最小限の構成で小さく始めていけるのはApollo Serverだと思います。最初はHasuraを使おうと思っていたのですが、調べた限り更新系のAPIの複雑な処理（例えばMutation1の結果を待ってMutation2を実行したいみたいな感じ）を行う場合はHasuraとは別の場所に自分でコードを書いてリモートスキーマなどで扱うようにする必要がありそうでした。結局コードを書く必要が出てくる可能性があるなら最初からコードを書いて始めようと思い、Apollo Serverを選択しました。

Prisma

バックエンドのコードの量が少なくて済んだのはPrismaのおかげな気がします。
自分は仕事でバックエンドのコードを書いたことはなく、バックエンドに関してはド素人なのですが、そんな自分でもあつかうことができました。
また、Prismaはマイグレーションを行うための仕組みも付属しているのでCI/CDに組み込んでマイグレーションを自動化することができました。

Auth0

認証に関することはすべてAuth0に任せました。ログイン・新規登録ページなどを自分で作る手間が省けるのは嬉しい点です。自分は他のIDaaSはAWSのCognitoしか使ったことがないのですが、Cognitoと比較してログインページのカスタマイズの自由度が高い印象を持ちました。餅は餅屋といったところでしょうか。

全体的な所感

とにかくリリースできたことが嬉しいです。
個人開発に重要なのは初速だと思います。開発意欲が高いうちにガーッと一気に主要な機能を実装してしまってあとは細かい調整に時間を使うというやり方で進めました。
また、自分が最強だと思うアーキテクチャを実践してこのように振り返ることができました。
作り終えたばかりなのでまだ改善点はこれから出てくると思いますが、開発速度、開発体験に関しては最強とまでは言わずともかなり再現性のある強いアーキテクチャなのではないかと思います。
最強のアーキテクチャにゴールはないので、より良いアーキテクチャをこれからも探求し続けます。