0からアプリケーション開発するならこうしたいというメモ

はじめに

最近モバイルアプリケーション開発を行い、インフラからバックエンド、フロントエンドまで全て開発して色々な学びがあったため、それを踏まえて次新規サービスつくるならどうするかを整理したいと思ったので整理してみました。

個人的なメモになりますが、ぜひアドバイス等あればコメントください！

基本方針

• 可能な限りコード量は節約して自社内で管理するスコープを最小限にする。
  • 特にバックエンドのコードは必要最低限になるようにしたい
    • API Keyなどを経由して外部アプリに接続するようなものや、複雑なビジネスロジックになる処理などはバックエンドAppとして用意
  • 基本フロントを改修すれば良い状態にしたい
• 利用するコードの種類を絞ることで学習コストを減らす
• ベンダーロックインされないような仕組みを目指す
  • 外部サービスはインターフェースで隠蔽しできる限り疎結合にし、移行コストを減らす
• マネージドサービスを活用して開発コストを少なくする

開発言語

フロントエンド

Dart(Flutter)

クロスプラットフォームでの開発において個人的に最も扱い易い言語・フレームワークだと思う。(他にもあるかも)

• ステートマネジメント
  • Riverpod
• HTTP Client
  • graphql_flutter
    • GraphQLのクライアントを生成
• ORM
  • orm(パッケージ)
    • Prisma Client Dart

バックエンド

• ミッションクリティカルなものやマイクロサービス化したいもののみバックエンドを用意する。
  • 例: 決済機能、ポイント操作、AI　など
• CRUDなどのDB操作は基本的にクライアントから直接行うようにする

Python

型が厳密ではないところは微妙だけど非常に描きやすく、また周辺パッケージも充実している印象。
バッチ処理なども全てPythonで実現する想定。
個人的にも扱いやすい

• フレームワーク
  • FastAPI
    • OpenAPIのスキーマファイルを作成できるの嬉しい
  • Strawberry
    • GraphQLで運用
• ORM
  • Prisma Client Python
    • PrismaのPython版
    • TypeScriptで最近人気
    • DBのテーブルはスキーマで管理することでドキュメントとしても利用できたり、自動生成が使えるので便利

備考

• スキーマ駆動開発を採用して、フロントとバックエンドでimmutableなモデルは使い回す。

インフラ

Supabase

DBやフロントエンドのホスティング、認証認可等はBaaSに寄せることで初期の開発コストを削減

• 初期の構築コストとスケールを考えた場合、DBにPostgreSQLが採用されているのは大きい
• オープンソースでセルフホストできるのも魅力的
  基本的にはBaaSの原則に従ってフロントからDBや認証にアクセスすることでコードの依存具合をできる限りフロントに寄せる。

Cloud Run(他も検討)

外部サービスなどへのアクセスなどBaaSで対応しきれない部分はバックエンドを実装。
Edge Functionsなどもあるが、制限が多くあまり好きじゃないのと、コンテナに寄せることで開発環境の構築の手間やプラットフォーム依存が下がるためマネージドなコンテナサービスを利用したい。(Cloud Runである必要もないが他に良いサービスがあんまりなさげ。良いサービスあったら教えて欲しい。)

他候補

• Heroku
  • 最近無料プランの改悪があったっぽい
• Fly.io
• Render
  • 利用実績が多そう

データベース

PostgreSQL

• Supabaseを利用する場合、必然的にPostgreSQLを利用することになる
• 最近はPlanetScaleも気になるので選択肢としては考えたい(PlanetScaleはMySQL)

CI/CD

Web: Vercel

• パイプラインの構築が非常に簡単(Webのコンソールぽちぽちでデプロイできる)

Mobile: Codemagic or Bitrise

• モバイルアプリの煩雑なCICDを簡単に実現できるっぽい(まだ使ったことない)

Backend or batch: CircleCI or Github actions

• スタンダードで利用しやすい

通信

GraphQL

• フロントエンドとバックエンドのスキーマ定義を管理し、自動生成することでスキーマの二重管理を不要にする
• フロントエンドの変更に伴うバックエンドの改修が少なくなる

リポジトリ構成

モジュラモノレポ

• マイクロサービスとかあまりにも管理不可高すぎてやってられない
  • マイクロサービスは部署ごとにサービスが細かく分かれているなど、大企業などで採用するなら良いと思う
• シンプルなモノレポも柔軟性を欠く
  • 共通部品として利用する独自のモジュールとかなら良いのでは

ディレクトリ構成(途中)

frontend or backend/
│
├── web/                       # サーバ部分(バックエンドのみ)
│   └── handlers/              # フレームワークによってはなくても良い？
│ 
├── components/                # UI部分(フロントエンドのみ)
│   ├── pages/                 # メインのアプリケーション画面
│   ├── organisms/             # メイン画面の一セクション
│   ├── molecules/             # セクションを構成する部品
│   └── atoms/                 # ボタンやアイコンなど最小のwidget
│ 
├── adapter/                   # APIレイヤー、コントローラーなどを含む
│   ├── controllers or providers/    # Flutterの場合はここでプロバイダーを実装
│   └── middleware/
│
├── domain/                    # ドメイン層、ビジネスロジックとエンティティ
│   ├── entities/              
│   ├── services/              # 細かい具体のビジネスロジック(画像のリサイズ 等)
│   └── repositories/          # infrastructure層のインターフェースを定義
│
├── infrastructure/            # インフラ層、データベースや外部APIのアダプター
│   ├── db/                    # DBアクセス
│   └── api_clients/           # 外部サービス
│   └── baas/                  # SupabaseやFirebaseなどの固有のメソッド
│
└── usecase/               # ユースケース層、DTOも含む
    └── dto/

開発環境

VSCode(もしくはforkして作られたエディタ)

• できる限りDevcontainerを活用することで個々人の環境に依存しない状態を作る
• Cursorが便利

テスト戦略

• 追記予定

セキュリティ対策

• 追記予定

エラー処理とロギング

• 追記予定

バックアップとディザスタリカバリ

• 追記予定

アーキテクチャ