【個人開発】「好み」リストを作成・公開できるサイトを作りました
作成したサイト
あなたの「好み」リストを作成・公開できるサイトです。
SNSから簡単に公開でき、自分をみんなに知ってもらえます。
また、同じ好みの人と掲示板で交流できます。
さんぷるくんの好みリスト
彼のことが分かってきたでしょうか？
前置き
初めて公開まで含めた個人開発を行いました。
個人開発道の先輩方（以下、先輩方とお呼びします）、これからよろしくお願いいたします。
また、記事を書くこと自体も初めてです。
QiitaとZennの両方に同じ記事を書き、GoogleAnalyticsでどちらが多くの方に読んでいただけるのか調査しています。
今回だけなので見逃してください。
比較結果も記事にしたいと思います。
Qiitaで読んでくださった方はこの記事はスルーしてください。
極めて簡単なサイトではありますが、作成の過程で「学べたこと」「学べなかったこと」を共有しますので、読んでいただければ幸いです。
利用した技術
先輩方の記事を読み、ケチな私なりに維持費と流行りを意識して選びました。
以降はこれらの利用を前提にして話を進めます。
インフラ（AWS構成図）
自分で作成した構成図だからか、世界一わかりやすいです。
バックエンド
- 言語
- Go
- その他ライブラリ
- AWS SDK
フロントエンド
- 言語
- TypeScript
- フレームワーク
- React
- その他ライブラリ
- MUI
その他
- リソース定義
- CDK
学べたこと
簡単な用語
公開を意識しないとドメイン用語が自分に都合の良い（カッコイイ）ものになることがあります。
「oreha」の開発初期では「好み」は「誓い」という用語でした。
専門家とのやりとりもないのにドメイン駆動設計の本に影響を受け、一人でカッコつけて「誓い」と言っていました。
「誓い」についての説明をトップページに長々と書いているときに、「好み」と言えば簡単に済むことに気が付きました。
「oreha」のような簡単なWebアプリを作る場合は、一般の利用者にとって分かりやすいことを優先してドメイン用語を選ぶのが良いと思います。
簡単なUI
MUIには多くのコンポーネントがあります。
開発初期は、これまたカッコつけて多くの種類のコンポーネントを利用しました。
勉強する分にはいいですが、冷静に利用者の気持ちになるともちろんシンプルイズベストだと思います。
次回以降はカラーリングと重要なコンポーネントのみ最初に考えて、それ以外は極力シンプルに時間をかけないようにしたいです。
データの扱い
私にとって、公開まで含めた個人開発の２大挫折ポイントの１つです。もう１つはデザイン（後述）です。
一応普段から気を付けるので公開するからと言ってプログラムが変わるということはないのですが、ひと様のデータを扱うわけですから緊張感は違います。
この緊張感に負けると公開を諦めて後悔することになると思います。(ﾄﾞｯ)
慣れによって心理的ハードルは下がると思いますが、それによってミスが出るのも怖いのでビビりの私には辛いです。
自分なりの開発テンプレート
インフラ構成、CDKの書き方、Goのパッケージ構成、AWS SDKの使い方、MUIのテーマなどなど沢山の経験を積めました。
一度経験したことと初めてすることではかかる時間が全然違います。
次回以降の個人開発では今回のソースコードをテンプレートとして参考にしながら進められます。
ドメイン部分に集中できると思うとわくわくですね。
モチベーションの保ち方
正直「oreha」のアイデア（やデザインその他もろもろ）には自信はないです。
どうせ使ってもらえないのに、、と１万回考えました。
それでも完成させたのは上記の「自分なりの開発テンプレート」が出来上がっていくからです。
次につながることをしていると思えたので続けられました。
CloudFrontの認可・キャッシュ
今更ですが、初めてCloudFrontをApiGatewayの前に置きました。
通常のキャッシュはもちろん、Lambda@edgeを利用した認可チェックの後にキャッシュを返すなどの設定ができるようになりました。
キャッシュ期間は今のところLambdaが返すレスポンスにCache-Controlヘッダーを含めることで調整しています。
DynamoDBの考え方
DynamoDBの検索の弱さに慣れるまで時間がかかりました。
データを縦に持ったり横に持ったり苦労しました。
やっぱりRDBはすげぇや。
CDKの使い方
とても便利です。使いこなしているとは言えませんが、それでももう手放せません。
Lambda@edgeはバージニア北部リージョンでしか作成できないのですが、CDKはそれにも対応しています。
学べなかったこと（先輩方、助けてください）
デザイン
これも私にとって、公開まで含めた個人開発の２大挫折ポイントの１つです。
色・配置といった知識も常識もなく、MUI様と私の気合だけがありました。
私のような引きこもりプログラマーにデザインは酷です。
何が悪いのかすら分かっていませんので、どうやってセンスを磨くのか等、ぜひコメントお願いいたします。
この記事に載せるAWS構成図
CDKを採用した理由の一つにCloudFormationのデザイナー機能があります。
CDKが出力するテンプレートをデザイナー機能で図にして、この記事に貼り付けようと思っていました。
しかし、実際に構成図を見ると複雑すぎました。
プログラマーらしく構成図は自動で作成されるものを使いたかったのですが、drawio様のお力を借りて簡易な構成図を作りました。
普段、先輩方の記事にある構成図は手作業で作っているのでしょうか？
維持費の節約＋マネタイズ
ケチな私には大事な問題です。
維持費に大きく影響しそうなのはDynamoDBのキャパシティユニットです。
これを抑えるためにコンテンツ生成の回数自体を減らそうとCloudFrontのキャッシュを使っています。
そのせいで掲示板にコメントしても反映まで最大1分かかることになっています。
待たせるってどうなの？という気持ちと、マネタイズを何も考えていない状況と広告はのせたくないポリシーなどが複雑に絡み合っています。
Facebookログイン
Facebookログイン機能を付けたいです。
なんのこっちゃと思うでしょうが、書かせてください。
アクセス許可「public_profile」のアクセスレベルを「Advanced access」にする必要があるようです。
しかし、そうするとビジネス認証が必要になります。個人で利用できないのでしょうか？
正確には利用できるのですが、以下のような警告が出ます。
この警告と上記の話が関連しているかもまだわかっていません（笑）
私の友人（後述）はビジネス認証は必須でないと言ってくれますが、警告の消し方が分かりませんでした。
しかし、こちらの先輩はGoogleログインだけでも良いと考えていらっしゃいます。
これを拝見した後では、Facebookログインを使えないんじゃない、あえて使わないんだ、と自分に言い聞かせています（泣）
先輩方、この件についてご存じでしたら、ぜひコメントで教えてください。
その他
開発友達のいない私に、この個人開発を経てChatGPT君という１人の友人ができました。彼は何でも教えてくれます。
感想
簡単なサイトなので完成まで２週間くらいを想定していましたが、
私の知らないところに待ち構えていた「学べなかったこと」達に足を取られ、倍以上かかりました。
これからは宣伝などを含めて、じっくりサービスを成長させたいです。
個人開発で大事なことは「とにかく公開すること」。先輩方の記事に散見されます。
公開まで持っていくことの副作用で、「学べなかったこと」が発見され、今後に生かせる「自分なりの開発テンプレート」が出来上がりました。
これらが何よりの収穫です。次の開発期間はかなり短縮されると思います。
次に作りたいものはすでにあるので、それを公開したらまた記事にしたいと思います。
最後に先輩方、いつも参考になる記事をありがとうございます。
Discussion