はじめに

この度、issueではバックエンドの構築をすることに決定しました。今回は序章になります。まずはバックエンドの必要性について感じたことをまとめてみました。Firebaseが登場してからはバックエンドを作るか作らないかの議論は結構あるあるな気がします。ですので、ここでISSUEでの事例を交えつつバックエンドの必要性について考えてみました。

■今までバックエンドを構築しなかった理由

開発スピードを最も重視していた

バックエンドを構築しなかった理由はこちら一択です。初期にバックエンドを構築していなかったのは開発スピードを優先していました。フロントとは別にバックエンドの言語やアーキテクチャのキャッチアップ、APIの開発に時間をかけて最低限必要な機能の実装に時間をかけたくありませんでした。これは正解だったと思います。Firebaseを使えば初期は爆速で機能開発ができるので、初期はFirebase、サービスが固まってきたらバックエンド構築の流れをおすすめします！

■バックエンドを構築する理由

ローンチしてから時間が経ち、システムの複雑性が増してきた

ISSUEのリリースは2021年6月です。もうすぐ一年が経ちそうな今の状況でも非正規化しているFirestoreでのテーブル数が30を超えてきたり、機能の数もかなり増えてきました。その状況の中でフロントにロジックが集中してしまっている現存のシステムの構造は良くありません。フロントではバックエンドから受け取った情報をレンダリングするという役割に沿ったシンプルなものにしたいと考えてします。ですので今後のスケールにも備えてフロントとバックエンドを疎結合な構造にする必要があります。

消費税計算など失敗した時のリスクが高いロジックが散らばっている

消費税込みの価格算出ロジックがfrontとfunctionsに散らばっていて、今後税率の変更が起きた場合非常に耐えづらい構造となっています。こういったものはバックエンドでしっかり呼び出し元を共通化して事故が起きないようにします。

責務がしっかり分けられていないので、エンジニアが増えた時に終わる

今は代表と共同創業の2人体制で開発をしており、統制するものもいないのである程度お互い放任してコードを書いている状態です。しかし、今後開発をお願いしてもらうエンジニアさんが複数入ってきたらそうはいかないでしょう。フロントとバックエンドでしっかり責務が別れていない状況で開発速度だけあげても、手に負えないコードが増えてすぐにメンテナンスを入れないといけなくなるでしょう。

今後既存サービスから独立したサービスを作る可能性がある

ISSUEでは勤怠管理やtopic機能にも力を入れています。確定ではありませんが、この機能は今後サービスが大きくなってきた場合は独立のサービスとして動かすことや提供することを考えていました。その場合、バックエンドを分けておけば、新しくコードを書く必要はありません。すでに作った勤怠管理やtopicのエンドポイントを参照すれば、あとはフロントを構築するだけで済みます。

以上がISSUEを運営している際に感じたバックエンドの必要性です。次回以降もバックエンド構築に関しての記事を書いていこうと思うのでよろしくお願いします。