Zenn
🔖

Twitterと全く同じものを作るPJ-1

に公開
Web
tech

⚠️ この記事は、ChatGPTが先生です。
はじめてZennを使うんですが、フォントが好きです

Why

TwitterってCRUDの要素全部あるし、研修課題にしてるところも多いと思うんです。だから、真似してみます

お知らせ

せっかく遊ぶんだし記録しとこうみたいなところがありますので、プロのエンジニアの皆さんは温かい目で見守ってもらえると助かります。あと自分がめんどくさがり屋なので、多分続きません。頑張ります

方針

基本めんどくさがり屋なので、シンプルにいきます。結構ChatGPTの内容ベタ貼りしています。下手に自我を出すほど、すごい複雑なロジックとかはないだろうし。。。

はじめに

ChatGPTをPlusプランに課金しました。プロジェクト機能が優秀すぎるので、それを使います。
Cursorとか途中から使うかもしれません。ChatGPTの出力は大体引用で書きます。

設計をする

ゴールを求める

実装するTwitterの機能ですが、基本的な機能は全て実装してみようと思います。リストアップすると以下の感じです。

> 以下に、Twitterクローンで実装予定の全機能をカテゴリごとにMarkdown形式で整理しました。MVP（最小機能）→フル機能までを段階的に構成しています。

# 📌 Twitterクローン 実装予定機能一覧

## ✅ MVPフェーズ（まず作るべき基礎機能）

### 👤 ユーザー認証
- [ ] サインアップ（メール+パスワード）
- [ ] ログイン・ログアウト
- [ ] Firebase Authenticationを使用

### 🐦 投稿（ツイート）機能
- [ ] テキスト投稿
- [ ] 投稿日時の保存
- [ ] 投稿の一覧取得（タイムライン）

### 📰 タイムライン
- [ ] フォローしたユーザーの投稿を表示
- [ ] 投稿の並び替え（時系列）

### 👥 フォロー機能
- [ ] ユーザーのフォロー・フォロー解除
- [ ] フォロー・フォロワー一覧表示

### 🧑‍💼 プロフィール
- [ ] 名前・ユーザー名・アイコン・自己紹介の表示
- [ ] 投稿数、フォロワー数、フォロー数の表示

---

## 🚀 拡張機能（段階的に追加）

### ❤️ リアクション機能
- [ ] いいね（Like）
- [ ] リツイート（Retweet）
- [ ] 引用リツイート（Quote Tweet）

### 💬 リプライ機能
- [ ] ツイートへのリプライ（スレッド構造）
- [ ] リプライの表示・取得

### 🔍 検索・発見機能
- [ ] ユーザー検索
- [ ] 投稿検索（キーワード・ハッシュタグ）
- [ ] トレンド一覧（簡易）

### 🔔 通知機能
- [ ] いいね・リプライ・フォロー時の通知
- [ ] 通知一覧画面

### 🖼️ メディア
- [ ] 画像添付（Firebase Storage使用）
- [ ] サムネイル表示
- [ ] 複数画像対応（オプション）

### ✉️ ダイレクトメッセージ（DM）
- [ ] 1対1のチャット機能
- [ ] 既読・未読表示（Optional）

### ⚙️ その他
- [ ] ダークモード切り替え
- [ ] レスポンシブ対応（モバイル最適化）
- [ ] 投稿削除
- [ ] アカウント削除

使うものを決める

最近すごい色々な言語だったりフレームワークだったりが普及していますよね。自分は、のほほんと過ごしていたのですっかり置いて行かれてしまったため、勉強の意味もこめて知らない言語を使ってみようと思います。以下は、ChatGPTとの技術選定の会話です。

## 🚧 フェーズ別方針

### ✅ フェーズ1：MVP開発（まずは機能を揃える）
- **フロントエンド**: Next.js（Reactベース、柔軟かつ高速）
- **バックエンド**: Firebase（統合プラットフォームで開発が早い）
  - Firebase Authentication（ログイン、認証）
  - Firestore（NoSQLデータベース、リアルタイム対応）
  - Firebase Storage（画像・動画アップロード）
- **ホスティング**: Vercel（Next.jsとの相性◎）

#### 🎯 目的：
- 迅速にMVPを完成させ、Twitterらしい機能を一通り実装
- 認証・投稿・タイムライン・フォローなどの基礎構築を優先

---

### 🔄 フェーズ2：本格スケールへの移行（柔軟・堅牢な構成へ）
- **フロントエンド**: 変わらず Next.js
- **バックエンド**: Node.js（Express） + PostgreSQL
  - 認証: NextAuth.js または JWT
  - DB接続: Prisma（TypeScript対応ORM）
- **デプロイ**: Vercel（フロント） + Render/Railway（API・DB）

#### 🎯 目的：
- データ構造が複雑になる投稿・返信・通知の関係をRDBで管理
- APIの設計や認証処理を自前で管理することで柔軟性・拡張性を高める

---

### 🚀 フェーズ3：スケール処理のマイクロサービス化
- 高負荷・非同期処理が必要な機能を **Go** によって分離実装
  - 通知配信サービス（Goroutine + キュー処理）
  - DM（チャット）機能（WebSocket + Go）
  - 画像変換・圧縮サービス（CPU負荷に強いGo）
- 通信: REST APIまたは gRPC / Redis Pub/Sub など
- コンテナ化: Docker + Cloud Run / ECS / Kubernetes（将来的に）

#### 🎯 目的：
- 負荷の集中する機能だけGoで高速・軽量に処理
- 機能単位でサービスを独立させ、保守性とスケーラビリティを高める

---

## 💡 技術選定の背景と意図

| 技術        | 採用理由                                                     |
|-------------|--------------------------------------------------------------|
| Next.js     | SSR・静的生成・柔軟なルーティングが可能で、Reactベース      |
| Firebase    | MVP開発に最適。認証・DB・ストレージが揃っていて迅速に構築可能 |
| Node.js     | フロントと同じJSで統一、ExpressでAPI設計がしやすい         |
| PostgreSQL  | 複雑なデータ構造・多対多関係をリレーショナルに管理可能     |
| Go          | 高性能・軽量な並行処理に強く、マイクロサービス化に最適     |

---

## ✅ 今後の進め方（案）

1. FirebaseベースでMVP構築（投稿・認証・タイムラインなど）
2. Express + PostgreSQLに移行し、バックエンドを独立構成に
3. 通知・DM・画像など負荷が高い機能をGoでマイクロサービス化

みたいな感じになりました！
ふむふむ、面白そうな構成です！ひとまず、Firebaseで思いっきりバックエンドはサボって、あとでしっかり作る。ゆくゆくはGoみたいなモダンな技術を使ってk8sとかでいい感じにしちゃうってのは夢がありますね。そこまで走れることを期待笑

それはそうと、課題としては、この言語移行みたいなものは非常に厄介になるかと思います。例えばFirebaseはNoSQLみたいなものですし、変なDB設計をしたら大変なことになりそうです。しっかり先生に聞きながら着実な設計をしたいと思います。一応気をつけるべきことを聞いてみました。

> この進め方をするにあたって、移行時に問題が発生しないように考慮しとくことなどがあったら、教えてください
1. FirebaseベースでMVP構築（投稿・認証・タイムラインなど）
2. Express + PostgreSQLに移行し、バックエンドを独立構成に
3. 通知・DM・画像など負荷が高い機能をGoでマイクロサービス化

## ✅ フェーズ間の移行を円滑にするための設計指針

| 設計方針             | 内容                                                                 |
|----------------------|----------------------------------------------------------------------|
| データ抽象層の導入   | Firebase専用コードにせず、データ取得・保存処理を repository パターンなどで抽象化しておく。後で実装差し替えが可能に。 |
| RDBベースの構造意識  | Firestoreでも「正規化」「参照型（Reference）」「IDによるリレーション」を意識し、後のPostgreSQL移行に備える。 |
| API設計を先行        | フロントからのアクセスをAPI経由にし、将来的にバックエンドが差し替わっても影響が出にくい構造にしておく。例：`/api/users`, `/api/tweets` |
| サービス責任の分離   | 通知・DM・画像処理など、将来的にマイクロサービス化する機能はモジュールを疎結合にして設計しておく。 |
| 非同期設計への意識   | イベント駆動（Pub/Sub）やメッセージング（Redis、NATSなど）の構成を想定し、後でGoマイクロサービスが受け取れるような構造を念頭に置く。 |

なるほど。とりあえずはデータ設計のところをしっかりした方がいいってところですかね。
では、またやる気がある時に進めたいと思います。この記事はMarkdownにして決定事項の内容ということで、ChatGPTのProjectファイルに追加しておきます

ではまた

Discussion