frontendがめまぐるしくかわるうちにbackendは技術スタックがクラスタ化した

エンジニア系

WEB frontend開発が日進月歩でどんどん進化してたのってReact Hooksが出たくらいまでで、それ以降はビルド環境も安定し2024年現在frontend開発における迷いは少なくなった。React系のライブラリ、フレームワーク選べばビルド環境もついてくるしデプロイ先もたくさんある。 そんな感じでここ10年くらいはfrontendメインで業界を見てきたんだけど、しばらくbackendに疎くなっていたらいつのまにか多極化したように見える。

上記は単独で使う以外にも合わせて使ったり、マイクロサービスにしたり、BFFおいたり、そもそもインフラまで含めれば膨大な選択肢がある。もうbackend＋インフラのアーキテクトって個人で行うの不可能なのでは？とも思う。さらにRemixなんかはfrontendからbackend界に逆進出してるし、今後もしばらくbackendは百花繚乱なのだろう。

これらはそれぞれ学習コストがかかるので、backend知識、経験として共通する部分はあるにせよ、経験した以外の選択肢は選ぶのが難しく組織や案件ごとに利用アーキテクチャがクラスタ化していく。これまで（というか自分の知ってる昔のbackend）はクラスタ化と言ってもMySQLかPostgresQLかのような今からすると屁みたいな差だったのでこれからbackend開発していく人は大変だなと思う（他人事）

とはいえ関わることもあるので自分的なキーポイントを考えてみた。

1、データをどう持つか。

今も昔も変わらない問題。無難なのはRDBMSで正規化されたスキーマでデータを保持すること。NoSQLには未だにメリットを見いだせていない。Firestoreはsecurity rulesが特殊過ぎてonSnapshotが必要なデータのみに留めたほうがその後の運用が楽。使い捨てのサービスをサクッと作るのは便利とは思うけど。RDBのマスタサーバ書き込み問題はスケールアップで結構持たせられるし、バックアップもうまくサポートしてくれるし特にいうことが無い。SQL互換DB以外を選択する強い意志も無い

2、frontendとのドメイン知識の共有をどう行うか。

OpenAPIでもJSON SchemaでもGraphQLでもgRPCでもtRPCでも何でも良い。一番汎用性があって楽なのはGraphQL、ついでOpenAPI。個人開発レベルなら最大工数払うとしてもGraphQLなんじゃないかな〜と思う。それよりもRemixとか使って楽する方が良い場合も多そう。 対応しない選択肢はない。仕事ならありえないし個人でも型なしでやるのはきつい。

3、自分が楽しいか、耳目を集めているか

つらい選択肢は選びたくない。マイナーで問題解決が基本コントリビュートなものとか。サクッと簡単に作れて使ってる人多いやつがいい。サクッと簡単に作れるなら多少マイナーでも良い。作るステップが多くてもメジャーなら良い。 あと人集めるときに集めやすいのが良い。Server-side Swiftとかチャレンジングで面白いけど採用難易度高すぎる。でも金あるならこういうピーキーな方が優秀な人材集まるのだろうか。

つまりまとめると、 - 最速（少コスト）でやるなら、 　　- 超小規模アプリ（Web/Native）ならFirebase 　　- 小規模以上のアプリ（Web）ならRemix 　　- 小規模以上のアプリ（Native）ならhasura + FaaS - 仕事でかっちりやるなら、 　　- チームの習熟度に応じたフレームワーク・ライブラリでGraphQL APIサーバ 　　- 規模が小さければOpenAPIでRESTも選択肢