Today's mobile and web applications are built using a collection of frameworks and application program interfaces (APIs). Typically, the mobile app uses a Javascript framework like Ionic that uses an API to connect to a cloud-based database like Firebase. As the user navigates the application and performs actions, data is transmitted back and forth between the application and the database.
It's not only databases that are accessed using APIs. These interfaces exist for thousands of different datasets, from geolocation services to dictionaries to cocktail recipes. Many APIs are free, while others are available on a subscription or usage-based model. But building an application using an API involves some risks—most notably, the potential for the API to stop working or become deprecated entirely.
This is what happened to the DarkSky API, one of the APIs we use for our mobile application, Water My Lawn.Water My Lawn, one of our BitBakery Labs projects, uses historical and forecasted weather data APIs to alert users when it's the right time to water their lawns. The application aims to reduce wasteful water usage while helping property owners keep their lawns healthy. Last year, the team tasked a co-op student with rebuilding the application using Google Flutter and Firebase. It was a fantastic opportunity to build their skills and help us learn more about how we could apply these technologies in other applications.
When I started my co-op term, I was excited to learn that one of my first projects would be to continue the work on Water My Lawn to convert it from using DarkSky to Apple's WeatherKit API. Apple purchased DarkSky in March 2020 and announced that Android support would end in July of that year, with support ending for iOS on March 31, 2023.
This exciting project for my co-op term involved a significant rework on the application's backend. Thankfully, there are a number of similarities between how DarkSky and WeatherKit APIs work. These similarities made it simple to understand the changes in how the API calls were made and how the responses would be formatted.
This kind of work is challenging because, unlike frontend projects where you see your changes to a user interface in real-time, backend work is purely done in code. We can send requests and get responses, but the impact of the changes involves a lot of tinkering to ensure the mobile application responds and displays correctly.
Another challenge is that WeatherKit is still technically in beta, so there's not much documentation available. Most of the "documentation" is threads from Apple engineers on its forums.
Even though the API calls were similar, there were a few differences in the data the API responded with that we needed to adjust the mobile application to handle. Water My Lawn takes the weather data and uses our team's algorithm.
I found some data that the DarkSky API provided that was no longer available with WeatherKit—specifically, dew point data. The dew point is the temperature air has to cool to become saturated with water vapour. Since WeatherKit doesn't provide dew point data, I had to rewrite a large part of the backend to calculate it another way for the application.
There was a benefit in the move from DarkSky to WeatherKit for the application. Previously, the DarkSky API only provided one day's worth of data per API call. That meant that we needed to make ten calls to get the ten days' worth of data we needed for the calculations in Water My Lawn. Since DarkSky was a pay-per-use API, those ten calls were costly.
The WeatherKit API delivers ten days of data in one call. Previously, ten users using the app would require 100 API calls. Now with WeatherKit, those same ten users only need 10 API calls.
This project has been very different from anything I've worked on—the kind of work I hoped to find in a co-op experience. You can download Water My Lawn from the Apple App Store and Google Play Store. And if you already have the application downloaded, you don't have to do a thing—all the updates are in the backend!
