VALUのパロディサービス「NILU」を2週間で作るのを支える技術
VALUをやりたいけど審査が通らない人のために、誰でも審査なしで無を売買できるサービスを作ったよ! https://t.co/ACObN14sLW
— Mito Memel (@mito_memel) 2017年6月16日
NILUは以下のような構成となっています。
バックエンド
- GAE/Go
- Gin
- Cloud Datastore
- Firebase Authentication
フロントエンド
- Vue.js
- Bootstrap4
- plotly.js
RDBは一切使っておらず、Cloud Datastoreだけで頑張っています。 Cloud Datastoreってトランザクション的なことはできるんですが、求められるテーブル設計がRDBとは大きく違ってCloud Datastore固有のノウハウが必要なので毎回設計に迷います。どっかにノウハウ落ちてないですかね。オライリーから「実践ハイパフォーマンスCloud Datastore」みたいなやつ発売されろ。
という制約を軸にテーブル設計していくんですが、1つのエンティティグループに何でも突っ込むと1秒1回制限に引っかかり、逆にエンティティグループを細かく分けすぎると25個制限のために1回のトランザクションでバッチ処理できる量が減りやっぱり1秒1回制限に引っかかるという、如何ともしがたい感じです。
証券取引なんてトランザクションの化け物みたいなものなのでこんなん無理やろって感じなんですが、NILUではどうやっているのかというと、売買注文は板に反映されないリクエストキューに一旦書き込み、定期処理でキューから取り出して順番に処理しています。画面への反映に5分くらいかかるのはこの定期処理待ちです。
こうすると並列処理できないのでスケーラビリティは落ちるんですが、並列処理したところでCloud Datastoreは楽観的ロックで競合しまくる可能性が高いので、処理がシンプルになるこの方法を取りました。1回の買い注文でも注文数量が多いと複数人の売り注文とマッチする場合があり1トランザクションで捌ききれない可能性がありますが、直列に処理しとけばたとえ途中でエラーが起きても単にリトライし続ければ注文順に捌けます。
Firebase Authenticationについては、基本スマホとかSPA用っぽいのでページ遷移のあるWebでの使い方が正しいのかいまいちわかっていません。JWTをcookieに保存するのはなんか違う気がしたのでログインが必要なページは一旦枠のhtmlだけ返した後非同期でユーザー情報を取得してきてるんですが、こういうやり方で良いんですかね。よくわかりません。
フロントエンドは雑に使えるVue.js+伝統と信頼のBootstrapです。フロントエンドについては本業ではノータッチなのでほぼ公式ドキュメントからのコピペとかで設計はテキトーです。恥ずかしいのであまりソース見ないでね。
あとplotly.js便利。VALUさんも見づらい謎チャートやめて素直に既成のチャートライブラリ使った方が良いんじゃないですかね。