shoetBlog
技術や好きなことについて発信しています。
オセロのWebアプリを作りました
2025/4/12 9:31:15
AWSTypeScriptWebSocketReduxVite
オセロのWebアプリを作りました

なぜ作ったか

はじめはフロントエンドの状態管理でReduxを学びたくて、簡単なTODOアプリなどではReduxの旨みを感じられないと思ったので、オセロを題材にしました。
またチャットアプリのようなWebSocketを使ったリアルタイム性のあるアプリケーションも作ってみたかった理由もあります。

アプリの紹介

URLに -dev がついており、思いっきり開発版ですが、とりあえず形に残したかったので、一旦そのあたりは後回しです!
とりあえず動いた状態です。

アプリ名は NetOthellO と命名しました!

有人対戦: RoomIDに適当な値を入力してJoinRoomボタンをクリックすると有人対戦が始まります。 (対戦相手にRoomIDを共有して同様にRoomIDを入力してJoinRoomボタンをクリックすると対戦が始まります。
CPU対戦(vs ChatCPT): アプリを開いてそのままVS CPUボタンをクリックするとChatGPTとの対戦が始まります。

扱った技術/ツール

フロントエンド

React: 特にコメントはありません。
Redux: WebSocketのオブジェクト管理やオセロの盤面の状態管理に使いました。
Vite: SPAの構築に使いました。
WebSocket: フロントエンドからのポーリングではなく、サーバーからフロントエンドに向けて通信するために使いました。
S3 CloudFront: SPAの配信に使いました。

バックエンド

AWSでの構築です。
APIGateway WebSocketAPI: AWSでWebSocketをサーバレスで扱うために使いました。
Lambda APIGateway SQS: サーバー構築が不要なので使っています。
DynamoDB: RDBにしたいところですが高いのでDynamoDBです。
OpenAI API: CPU対戦ではChatGPT(モデルは4o-mini)に回答させています。

その他

AWS CDK GitHub Actions: インフラ構築、CI/CDパイプライン構築

リポジトリ

GitHubのリポジトリを公開しています。
https://github.com/shoet/othello-redux

反省点

Viteではなく最初からNext.jsを使ってもよかった

当初実験的に、何か勉強になればいいや的な感じで始めたので、オセロのゲーム画面のことしか考えていませんでしたが、
Webに公開するにあたってそれ以外の画面も必要になったときに、ルーティングをどうするかを考える必要が出てきました。
ReactでのSPAで選択肢としてReactRouterがありますが、
ルーティングのためにわざわざコードを書かないといけない煩わしさがあったり、SPAオンリーのアプリを習熟したいとも思わないので、
はじめからNext.jsで構築して、必要になるまではClientComponentで実装する進め方でも良かったかなと思いました。

その他の所感

Reduxを使ってみて

ReduxToolkitを使用して、簡単に実装できました。
また、機能ごとにロジックが集約できるので処理の把握がしやすく感じました。
ボイラープレートが多い、と聞きましたがReduxToolkitを使った場合はそこまで多いとは感じませんでした。
Next.jsで実装する場合は、useReducerやContextを組みわせて使うほうが取り回しがしやすいかもしれません。

コメント
profile
匿名ユーザー(ID: )
Markdown
Preview
エンジニア。
エンジニアリングで価値提供できるよう、
日々自己研磨。
AWSAWS LambdaChormiumCloudFrontDockerECSGitHubGoGraphQLLambdaLocalStackNext.jsOpenAIPlanetScaleReactReduxServerlessFrameworkTypeScriptUpstashViteWebSocket