目的
現時点でどういった形の開発環境が良いと思っているかを一旦メモする。
いろいろ考えたけど、自分でも突っ込みどころあるので、もっといい技術選定できるように勉強しないといけない。
toC向けの自社開発（もちろんそれに伴いtoB向け機能とかも作ったりしましたが）の経験しかないのでそのイメージで書いてます。
1人
フロント
React & TS。 Vueも好きだが、今はReactの方がTSとの親和性の点と情報量の多さで優位だと思う。
もし、自分一人だったら、SSRやSSG不要の時でも、Nextjsを入れて、ドキュメントコストを減らしたい。
デプロイ先は、Firebase Hosting、認証もFirebase Authnication、測定は、GA4やFirebaseを入れてBigQuery連携させておく。
記事サイトの場合はindexまでの速度が大事になってくると思うので、ISRがすぐ使えるVercel で最初は楽するのが良さそう。
そうでなければ、SPAで最初は良いと思われる。search consoleでindex数に悪影響があったりしたらISRやSSRを検討するにした方が楽。
ただ、ある程度スケールしたら、GCPに行った方が管理が楽そう。
SSGをしたことあるけど、ページが増えれば増えるほど、レスポンスタイムが増えるし、新規ページ追加する時もいろいろ考えないといけなくて、めちゃくちゃ苦しんだ過去があるので、あまり頑張る価値を感じない。将来的にも、CDNでキャッシュすれば変わらないですし。（セキュリティ上のリスクはついて回りますが...）
アプリ開発は、現時点だとFlutterが良さそう。試した所、細かい所はハマったが、大枠問題なくリリースまで持って行けた。
Flutter webに関しては、WEBとアプリで提供する体験って違うと考えているし、まずWEBでいろいろ試してみてから、ユーザーインタビューとかの結果を元に、アプリ用のUXを考慮してリリースっていう方が初期はよいと思うので、あまり使うイメージが湧かない。
API
Auroraか、CloudSQLをデータストアとして使いたい。
Firestoreも簡単でとても良いが、途中で上手く設計できず、RDSに利用に変更を2回ぐらいしたので、今のスキルでスピード優先なら最初からRDSだと思う。
APIに関しては、Next js のAPI routeに書くのが良いのかもしれないが、やっぱり以下の点から、最初はRailsが個人的には好き。
デプロイ先は、ECS（GCPだとGKE??）が設定慣れてるので好み。
アーキテクチャ
Rails Way
APIの連携方法
RPCでいいのではないかと思う。Validationや型付けは頑張るしかないが...
あるいは、Nodeでしか使ったことないが、GraphQLも良いと思うけど、型付けを手で頑張るのとそこまで変わらない感覚だったのと、学習コストがかかるので、内部のAPIには積極的に使わなくても良いかと思った。
監視
CloudWatch logs（GCPだとなんだろう？） とSentry のアラートをSlack通知するレベルで十分だと思う。
開発環境
DBはクラウド上に1つ用意。 - Local開発用に、自分でDB準備。 - 本番用に、本番用DB作成。
テストは本番DBに繋いでしたりする。 この時点だと、同期的にビジネスサイドとの確認がしやすいはずだから、ばんばん確認してリリースしていく。
CI, CD
最近は Github Actions にはまってる。 ブランチにpushしたら、lint & Deploy が走るようにする。
テスト
複雑なビジネスロジック部分は開発する時に楽なので書くけど、積極的には書く必要はないと思う。 テストの保守が大変なので...
レポジトリ構成
基本はレポジトリ分けて開発したい。
web1、flutter1、API1 といった感じ。
データ収集
BigQuery にデータをずっと入れておく。
となると、RDSの置き場所は、GCPがやはり分析に便利...
その他
AmplifyもAnalytics機能があるけど、どうなんだろう？？
2人 ~
開発環境整備や、E2Eテストの整備が必要になってきそう。
開発環境
DBはクラウド上に2つ用意。
- Local開発用には、DockerFileで自動で開発用DBが構築されるように準備。
- 本番 & Staging環境用に、本番用DB作成
- 社内テスト用に、確認用DB作成
ブランチは、mainブランチ、stagingブランチ、qaブランチを作成し、それぞれのブランチ毎に、フロントとAPIサーバーを作成する。
確認用DBの中身は、とりあえず手で同期するようにしておく。
自動テスト
フロント側に関しては、staging、QAブランチにアクセス時に、E2Eテストが走るようにしておくと、気が楽。
アプリはテストをしたことないのでわからないです。
API側の単体テストは、開発時には便利なので書いてますし、ビジネスロジックと呼ばれてる部分は書きたい。が、コントローラーのテストとかは変更が多くて辛いので、開発時に書いたとしても、後でテスト対象から外してる。
社内用ツール
社内の人がRDSにCRUDできるためのツールが求められてくる。
Google アカウントを発行しておけば、認証はGmailで完結するのでそれを使うと楽そう。
社内ツール作成は他チームと関わることができるし、目に見えて感謝されるので、新しく入った方で経験が浅い方にチャレンジしてもらえると、すごく勉強になるんじゃないかなと思うので、その人の技術レベルで使用言語を決めるといいのかなと思う。
インフラ
早めにコード管理しておきたい。
10人 ~
フロントもサーバーもインフラも全部みんなでやっていくのが厳しくなる時期だと思う。
自社開発系でこの規模だと、「サービスが好きな人」が採用しやすいと思ってて、その人たちがいかにボトルネックなく、そして不具合リスクを減らしつつ、サービス開発を進めていけるかが鍵だと考える。
一方で、技術力の高いエンジニアを、データの整合性担保や、難易度の高い業務ロジックに集中してもらうことで、業務量を集中させ、高い効率を発揮してもらえると思ってる。
そのため、以下のようなのが良いのかなと今思っている。
API
BFF的なAPI層と、BackendAPI層の二つに分ける。
BFF「的な」と書いたのは、一般的に行わないDBアクセスまで、そのAPI層に行わせるべきだと思うため。
BFF的なAPI層の責務
- BackendAPI層の呼び出し
- WEB、ネイティブアプリと分けて、それぞれが必要なレスポンスだけを返すようにする。
- APIの認証
- RDSの読み込み処理
レポジトリは二つに分けて、片方はWEBフロントエンジニア、もう一方はアプリエンジニアが中心で開発するのが良さそう。
自分としては TS & prisma & express で開発するイメージ。
BackendAPI層の責務
BFF的なAPI層から、BackendAPI層を呼び出すライブラリの作成もする必要がある。
この辺りを、技術力の高いエンジニア集団で保守していく。この時に、業務ロジックを極力ドメイン毎に分けていくことで、今後のマイクロサービス化に備える。
大きくは、一つのデータストアに対して、一つのAPIを作るイメージでいる。
APIの連携方法
引き続きrpc的な方法のままで良いかと思う。
BFF的なAPIの言語をTSに絞って、型付きのライブラリを提供すると開発しやすかった。
開発環境
DEV DBの自動同期が必要になりそう。
こんなイメージ
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
20人 ~
未知の領域
ここに関して知見が皆無。
フロント
サービスが複数個出来上がっていることが多いが、その場合も特に技術スタックを変更する必要もなさそう。
API
BackendAPI層の肥大化が生まれてると思う。
そのため、いくつかの主要なビジネスロジックは、マイクロサービス化していく必要がありそう。
ドメインに分けて、データストアを分離をしつつ、読み込み、書き込み共にマイクロサービス側から提供する。
トランザクションの保障や、ドキュメント化、k8sの検討などいろいろ考えることがありそう。
APIの連携方法
新規のマイクロサービスでは、gRPCを利用するのが良さそう。言語としては、Go言語を使ってる所が多そうと感じて、親和性が高そう。
一方で、BFF層を一般的な責務に抑えて、データ取得を比較的自由にできるAPIを提供したいのならば、GraphQLが良さそうだが、この規模ではまだ必要なさそう。
終わり
20人以上の規模の会社になると、どうなるんだろう...
想像で書いたけど全然違ってそう...
