概要

twitterでバズった動画や画像のツイートをいいね順、リツイート順、日付順で閲覧できるwebサイトを作った
https://twipop-app.tontonton.work/

使用した技術

サーバサイド
Rails
フロントエンド
React
API
公式TwitterAPI
DB
firebase Realtime Database
ホスティング
Heroku
ssl
cloud flare

全体像

こんな感じ

なぜRails

サーバサイドはRailsしか扱ったことがないから。Rails以外の技術を勉強する時間が勿体無い。

なぜReact

前々からSPAに興味がありReactの勉強を進めていた。Vueはちょっと勉強して挫折。
ページの部分更新するにもstate更新するだけで実現できてお手軽なのが魅力的。
gemはreact-rails

[Reactを知る前の貧弱な僕]
ビューにpartialファイル用意して、コントローラで専用のインスタンス変数用意して
あとpartialを返すようにして、それとそれとjavascript側でDOM更新してっｱﾜﾜﾜ

⬇️

[Reactを知った頑強な僕]
「フンッ」取得データでstate更新
シャッ(華麗にページ更新される音)

なぜRealtime Database

なるべく無料DBを使用したいと思っていた。
最初はFireBaseのCloud Fire Storeを使おうとしていた。

Cloud Fire Storeについて

CRUDについて無料プランは以下の制限がある。
書き込み 2 万/日
読み取り 5 万/日
削除 2 万/日

nosqlは初めて扱った。RDBしか使ったことのない僕は最初

「1日でこんなにselectしないでしょw」
とか見当違いのことを思っていた。

実装を進めるにつれ、読み取り数の使用状況がおかしいことに気づいた。

「うわ・・・私の読み取り数多すぎ？」

どうやらこの制限はデータ件数のことみたいだった。データ件数自体は1万も2万も扱うつもりはないが、読み取るたびに累積していくので断念。

RealTime DataBaseについて

RealTime DataBaseはCRUDの制限はない。容量は1GB。
gemはfirebase。
今の所問題なく動いているが以下のようなデメリットもある。

日本語の関連記事があまりない
データの降順機能がない。今の所、昇順で取得したリストを自力で降順するしかない
FireBase自体はCloud FireStoreを推奨している

参考
FireBase公式料金プラン

なぜHeroku

アクセス数などの制限が無くRailsと親和性の高いHerokuを使用することにした。

最初はFireBaseでホスティングしようと思っていたけど、Twitter APIを使ってデータ取得するのにNode.jsが必要なので断念。
FireBaseでNode.js利用するときはCloud Functionを使う必要がある。
Cloud FunctionはBlazeプランに変えないと使用できない。
プランを変えたからといってすぐ課金されるわけではないけど、なるべく慎重にいきたい。

まとめ

DBの差し替えとかHeroku環境変数の設定とか、結構つまづいたことが多かったが学びも多かった。
今後も少しずつ改良を加えていきたい