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.
Top comments (0)