Designing Around External API Assumptions: A Lesson from a Free Exchange Rate API

Asuka Suehiro — Fri, 02 Jan 2026 01:01:23 +0000

I developed and deployed an application called YenUp, which compares today's exchange rate with yesterday's and sends a notification based on the result. To keep the project simple and free, I used the Frankfurter API as the data source.

I was happy to have completed it. However, I soon noticed something wrong with the notification I received.

It was supposed to notify me when today's rate is better than yesterday's. To debug the delivery pipeline end-to-end, I added a notification=true flag that forces a Slack message even when the rate doesn’t change.
What I actually received looked like this:
Test Notification (forced). CAD/JPY: Yesterday 114.4300 -> Today 114.4300

At first, I suspected a bug in my own implementation. I reviewed the logic and double-checked the comparison code. Eventually, I realized that the issue was not in my code, but in my assumption about the API.

This behavior was further amplified by my own fallback logic.
When data for a specific date was unavailable (for example, on weekends or before the daily update), my implementation fell back to the latest endpoint.
As a result, non-business days could effectively collapse into the same underlying rate.

What I learned

This experience made me realize that the real problem was not the API behavior itself, but my assumption about it.
I had designed the logic assuming that "today" and "yesterday" were calendar days. However, external APIs often define these terms based on their own business rules, which might not align with how a product expects to use the data.

What I'll do next

Based on this, I'm considering changing the comparison logic to use business days instead of calendar days.
I haven't fully implemented this yet, mainly because defining business days consistently across currencies introduces additional complexity.

This small bug led me to question my assumptions, which changed how I think about external APIs and business rules. I hope to continue learning through future projects.

Automating Go App Deployment to Google Cloud Run with GitHub Actions(Free Tier)

Asuka Suehiro — Sat, 20 Dec 2025 00:40:52 +0000

Hi, everyone! This is my first article on dev.to.👋
I recently built a Go application and deployed it, using Google Cloud Run and GitHub Actions to deepen my DevOps skills. In this post, I'll share how I automated the deployment process and what I learned along the way.

Background

I currently live in Canada but earn my salary in JPY. Since the exchange rate fluctuates constantly, checking the CAD/JPY rate manually every day has been a hassle. I wanted a system that would automatically notify me via Slack whenever the rate improved compared to the day before. To achieve this, I decided to autmate the workflow, using GCP and GitHub Actions.

The System Architechture

graph LR
  GitHub[GitHub] --> Actions[GitHub Actions]
  Actions --> Registry[Artifact Registry]
  Registry --> CloudRun[Cloud Run]
  Scheduler[Cloud Scheduler] --> CloudRun

Why these technologies?

Why Go?: It's a static typed language, which ensures robustness and keep the container image size small.
Why Google Cloud Run?: It's a serverless platform, so I don't need to manage severs. Plus, it scales to zero when not in use, allowing me to run this bot within the Free Tier.
Why GitHub Actions?: It allows me to manage CI/CD pipeline at right next to my code. Integrating it with GCP is secure and seamless.

Key Challenges & Solutions

The "Secure by Default" Trap (403 Forbidden): At first, I didn't realize that Google Cloud Run blocks unauthenticated access by default and focused on 403 Forbidden errors without allowing unauthenticated invocations. I set OIDC Token in Cloud Scheduler Authentication Header.
CI/CD Configuration Details: I spent Time debugging The GitHub Actions pipeline because of a simple mismatch in the Artifact Registry configuration. I confused the Repository Name with the Repository ID. This experience taught me that in DevOps, paying attention to the smallest details in variable names is just as important as writing the code itself.

What I Learned

The Trade-off: Initial Setup Pain vs. Future Efficiency### Future Improvements
Runnning code locally is intuitive and instant, while moving to the cloud felt tedious. But once I overcame that initial barrier, I realized the power of automation. The system now works for me, while I sleep. I learned that engineering is about enduring the initial struggle of setup to achieve long-term efficiency. This project allows me to save time to do something else to improve my skill - which I believe is the essence of technological progress.

Future Improvements

Database Integration: I plan to use PostgreSQL(with Atlas) to store historical rate data.
Data Analysis: I want to build a Python component to analyze the rate trends using Pandas and visualize the data.

🔗 Links

GitHub Repository: https://github.com/kskiii/yenup-app

Forem: Asuka Suehiro