【バックエンドエンド地獄編】YEN$CONVERSIONの駄話-SYABLOG

はじめに

外国からの輸入品を日本円から現地の通貨に換算して、向こうではどのくらいの価値があるのかの目安を示すことができるWEBアプリ「YEN$CONVERSION」の反省点を書こうと思います。

文章量が多くなりそうなので、記事を2つに分けます。

フロントエンド編
バックエンド編 ← 今ここ

こちらの記事もよろしくお願いします。

開発を通しての感想

とにかく長引いて疲れました。当初は2023年6月末から開発を始めて遅くとも同年7月が終わるころまでに終わらせる予定でしたが、ひと月も延期して8月末までずれ込みました。

主な理由としては

夏バテ
バックエンドの迷走

の二つです。

夏バテに関しては根性で乗り切ったということで特筆すべきことは無いので詳細は書きませんが、体調の悪さはメンタルにもデバフがかかるので結構辛かったです。

バックエンドはすべてGCPで構成していますが、かなりの苦戦を強いられました。

本当に完成して良かったです。

バックエンド

今回のWebアプリでやりたかったことは、バックエンドでデータを定期実行で自動的に更新するようにして、フロントがそれを受け取っていい感じに表示するということでした(あやふや)。

少し違うけど簡単な永久機関のようなものを作りたかったと思ってください。

結果的には完成してハッピーハッピーやんケと今でこそ思いますが、軽く地獄を見ました。

舐めてかかったつもりはなかったけれど、下調べと準備が不十分だったのが原因だと思います。以下駄文注意。

構成の変遷(長文注意！読み飛ばしてもOK)

当初は、GCP(Google Cloud Platform)のFunctionsでWeb APIとして使うSupabaseにデータを更新する処理を書いてSchedulerを使って定期実行させるつもりでした。

しかし、この構成ではトラブルが発生したので、最終的にGAS(Google Apps Script)とスプレッドシートを使って以下のようになりました。

GASでレートの値を取得する
取得してきた値をスプレッドシートへ書き込む
Functionsがスプレッドシートに記された値を取得する
取得してきた値を元にSupabaseを更新する
Functionsの処理をSchedulerで定期実行

という流れになっています。

なぜ構成を変更するに至ったか

まず初めに為替レートを取得する方法を探すことから始めました。最初に思い浮かんだのが公開されているWeb APIからデータを取得することでした。当然レートを取得できるものはあるにはあったのですが、どれも無料プランでは制限があり複数の国のレートを取得するには有料プランに入るしかなく、完全に無料で運用する構成にこだわる身としてはあり得ない選択でした。

次に浮かんだのは、ライブラリを使ってレートを取得することです。
forex-pythonというPythonのライブラリにたどり着き、ローカル環境でのテストも成功しました。
Pythonは以前趣味(スクレイピング等)で使っていたので勘を取り戻したらすぐ書けるようになりました。

さっそくFunctionsで処理を書き、Schedulerで定期実行させる処理を書きました。

度々Functions側でエラーが起きているとログが出ていたものの、Supabaseを確認するとちゃんと更新されているようだったので、成功したものとしてまったく気にしていませんでした。
この時は日付のカラムだけ見て判断していたので、完全に油断していました。
もうバックエンドは完成したものとして、フロントの開発に着手していました。
このことを後悔することになります。

フロントエンドの方があらかた完成したので、あらためてFunctionsのエラーを解消しようとエラーメッセージを読んでいると、forex-pythonのライブラリの値が取得できていないという文章があることに気づきました。
ローカルで試したところ、以前問題なく成功したコードにもかかわらずエラーが出ました。
どうも安定しないライブラリのようで、日によっては全くデータを取得できませんでした。

再びレートを取得する方法を探し始めました。
GoogleやTwitter, QiitaやYoutubeで検索で様々な検索ワードを駆使して、ようやく見つけたのがAlpha VantageというAPIでした。

以前見つけたものとは異なり、1分間に5リクエストまでという制限はあるものの
定期実行で外貨を3グループに分けてリクエストのタイミングをずらせば問題は無いし
どの組み合わせのレートも無料で取得できるので渡りに船でした。

こんな感じに分けた

早速FunctionsでAlpha vantageの値を取得してSupabaseの値を更新する処理を書いて、例によってSchedulerで定期実行させるという構成で行こうとしました。
しかし、またも問題が発生しました。
Functionsは無料プランでは外部のAPIにアクセスできないという縛りがあり、supabaseの値は更新できているものの、日付の値以外は変更なしという状況から変わっていませんでした。

やむを得ず構成の変更をすることにしました。

8月に入り暑さがより厳しくなり体調を崩して夏バテなりました。
かなり体調がきつかったです。

泣きっ面に蜂という状況でした。

心が折れかけてやめてしまおうかと思いましたが、
途中で投げ出して完遂できなかった記憶が残る方が、後々自己嫌悪で精神的ダメージが大きいので、少し頭を冷やしてペースを落とすことにしました。

気分転換にフロントの方で折れ線グラフを実装しました。
それはそれで大変でしたがバックエンドのことを一時忘れられたのは幸いでした。

フロントエンドはほぼ完成して後はバックエンドの完成を待つばかりというところまで進めることができました。
他のクラウド環境を使おうとも思いましたが、GCPより使い勝手の良いものが見つかりませんでした(あくまで個人的な感想)。
なのでここまできたらGCPと心中することに決めました。

Google Apps Scripts(略称GAS)というもので外部APIと通信できるという情報をTwitter(現X)で見かけて、藁をもつかむ思いで試しました。
結果は成功で定期実行も出来るようで一石二鳥でした。
ただ、Supabase(postgresql)に接続する方法が調べてもわからなかったので、スプレッドシートを利用することにしました。

functionsも書き直し、スプレッドシートから取ってきた値でSupabaseを更新する処理にしました。エラーが全く出なくなったので胸をなでおろしました。
Schedulerでの定期実行も問題なく、ようやくバックエンドを完成させることが出来ました。

各々の解説

GAS(Google Apps Script)

定期実行で外部APIから取得したレートの値をスプレッドシートに書き込む処理を担当しています。
GASは最も神に近い存在なんや。

スプレッドシート

GASから書き込まれた値をFunctionsに読み取らせる中継役を担っています。

Functions

スプレッドシートから取得した値によってSupabaseのデータを更新する、最も重要な役割です。

Scheduler

Funcitonsの手綱を握って定期実行させる役目を担っています。

まとめ

いかかでしたか？(クソブログ)
今回の苦戦は自業自得でしたが、プログラミングって結局根性なんじゃないかと思いました。
あと完全に無料で運用したかったとほざきましたが、登録してあるカード会社からのメールを見ると普通に毎月請求されています。
まあたった2円なのでヨシとしました。

このQiitaの記事に触発されて完全に無料でバックエンドを運用してみたいと思って自分なりに取り組んでみたつもりですが、何事も一朝一夕では上手くいかないものです。
ハッピーエンドというよりノーマルエンドみたいな感じで今回の開発は終わりを見ましたが、自分のやりたかったことが出来た点はとても満足しています。

この苦い経験を次に生かしてもっとスムーズに開発を進められるようにしようと心に誓いました。
これ以降のWebアプリやChrome拡張機能はバックエンドが無しでフロントだけで完結しているモノのみですが、そろそろ気合を入れて有りのモノをつくろうと思っています。

【バックエンドエンド地獄編】YEN$CONVERSIONの駄話