はじめに

外国からの輸入品を日本円から現地の通貨に換算して、向こうではどのくらいの価値があるのかの目安を示すことができるWEBアプリ「YEN$CONVERSION」を完成させてしばらく経ちました。
開発で疲れ切った頭もようやく回復してきたので、今回は反省点を書こうと思います。
文章量が多くなりそうなので、2つに分けて投稿したいと思います。

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

こちらの記事 → React.js + Supabase + GCPで作った個人開発WEBアプリ「YEN$CONVERSION」もよろしくお願いします。

今回の開発を通しての感想

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

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

の二つです。
夏バテに関しては根性で乗り切ったということで特筆すべきことは無いので詳細は書きませんが、体調不良はメンタルにもデバフがかかるので結構辛かったです。
バックエンドはすべてGCPで構成していますが、かなりの苦戦を強いられました。
本当に完成して良かったです。

バックエンド

今回のアプリでやりたかったことは、バックエンドでデータを定期実行で自動的に更新するようににして、フロントがそれを受け取っていい感じに表示するということでした(あやふや)。
少し違うけど簡単な永久機関のようなものを作りたかったと思ってください。
結果的には完成してハッピーハッピーやんケと今でこそ思いますが、軽く地獄を見ました。舐めてかかったつもりはなかったけれど、下調べと準備が不十分だったのが原因だと思います。
以下駄文注意。

構成の変遷(長文注意！読み飛ばしても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リクエストまでという制限はあるものの、
定期実行でタイミングをずらせば問題は無いし
どの組み合わせのレートも無料で取得できるので渡りに船でした。

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

8月に入り暑さがより厳しくなり体調を崩して夏バテになっていました。
このあたりかなりきつかったです。心が折れかけてやめてしまおうかと思いましたが、
途中で投げ出して完遂できなかった記憶が残る方が、後々自己嫌悪としての精神的ダメージが大きいので、
少し頭を冷やしてペースを落とすことにしました。
気分転換にフロントの方で折れ線グラフを実装しました。
それはそれで大変でしたがバックエンドのことを一時忘れられたのは幸いでした。

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

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

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

各々の解説

GAS(Google Apps Script)

救いの神。定期実行で外部APIから取得したレートの値をスプレッドシートに書き込む処理を担当しています。

スプレッドシート

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

Functions

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

Scheduler

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

まとめ

いかかでしたか？(ウザいブログ)
今回の苦戦は自業自得でしたが、プログラミングって結局根性なんじゃないか
と思いました。
あと完全に無料で運用したかったとほざきましたが、登録してあるカード会社からのメールを見ると普通に請求されました。
まあ数十円単位だったけど...それでも少しガッカリしました(泣)。
この記事に触発されて完全に無料でバックエンドを運用してみたいと思い自分なりに取り組んでみたつもりですが、何事も一朝一夕では上手くいかないようです。
ハッピーエンドというよりノーマルエンドみたいな感じで今回の開発は終わりを見ましたが、自分のやりたかったことが出来た点はとても満足しています。
この苦い経験を次に生かしてもっとスムーズに開発を進められたらと思います。