Why your mobile app should never call an external API

December 12th, 2016

These days, you can find an API for just about anything. Whether you need flight tracking info, stock prices, or something else, you can be sure there’s a service out there with the data you need. When you’re building an app that uses external APIs like these, it can be very tempting to call them directly from your mobile app, but that can get you into trouble.

The problem with external APIs: Lock in

Let’s imagine you have a great new idea for presenting weather data, and you’re building an app. You’re not doing the forecasts yourself, so you’re relying on an external service to provide that for you, and you’re just calling it directly from your app (to keep things simple). Your app is doing great: users are loving it, and you’re making money.

But, one day, your weather provider decides they’re discontinuing a core feature you need from their API. You find another weather service that you can replace it with, but how do you handle all of the users who are happily using your existing app? It’s going to take you time to integrate the new service, not to mention getting it through testing and app review. Plus, at some point, the version that’s out in the wild will stop working, leading to lots of 1 star reviews complaining that they paid for an app that no longer works.

That’s one of the biggest problems with directly calling a third-party API: lock in. It’s a lot harder to switch out forecast providers when thousands of your users rely on it every single day. What if instead, you built your app so it called your own server for all of the information you need, rather than the external API? Your backend then manages the relationship with your external weather API, so when you need to switch it out or improve it, you don’t need to distribute a new version of the app: just update your backend server and your users are all instantly upgraded.

Wrapping means you get the API you need

When you call an external 3rd party API, you are stuck with the data they provide: sometimes it’s not enough, and sometimes it’s way too much. Imagine the forecast example: what if you just want the temperature, but the API you’re using always returns an entire detailed forecast? Your users are downloading way more data than they need, running up their mobile data usage as a result.

When you build out your own backend API, you can massage, merge, and prune the data as you see fit. If you have several different weather providers that you like to merge into a single forecast, your backend can do it, and your app doesn’t need to know anything about it. If you only need very specific data on screen, you can send down exactly that data and nothing else, even if your provider API doesn’t support that functionality.

Having your own backend wrapping an external API means you have much more control over the data you’re sending down, allowing your app code to be simpler and less likely to break. It’s a win-win.

Control your costs with caching and throttling

If you’re using an external API that charges you by usage, a wrapper API can be a crucial way to help you minimize your costs. Let’s stick with the weather example. Your app is directly calling a weather API that charges per request, and you have 1000 users in Philadelphia. If you’re calling it directly, when those users open up the app, they each make a separate call to the paid weather API asking for the Philly forecast today, costing you money for each request. But, the weather API is just returning the exact response to all 1000 of them! You’re paying 1000 times for the same data.

Instead, what if those requests first went through your backend API? The initial user’s request would need to ask your paid API for today’s Philly forecast, but you could cache that response on the server. For every subsequent request, you just return the saved response, saving you 999 extra requests! This is the power of wrapping an API: you can optimize costs and usage in ways that just aren’t possible when you’re calling it separately from every single user.

Along similar lines, when your app is directly calling an external API, what happens if one user is abusing the system, or there’s a bug that causes a huge spike in calls to the provider? You’re stuck with the quickly increasing bill, and there’s no way for you to stop it other than releasing a new version or disabling that provider for all of your users.

When you control your own API, you can more quickly respond to quickly rising costs by adding throttling to your responses. Did a bad bug pop up where your app is calling the API 10x more often than it should? Just have your server throttle those requests to slow them down, keeping your API costs at manageable level.

When wrapping isn’t right for you

Wrapping your external APIs sounds great: more control, no lock in, but there’s a downside: it’s another thing you have to manage and pay for. If you’re just building a hobby app or proof of concept, it might not be worth your time (and money!) to build out and support your own backend. That’s ok! If you decide later on you want to build out your own backend, you still can, you’ll just need to make sure you have a solid plan to transition.

If, on the other hand, you have a business-critical app that is making you money, and it’s currently relying directly on external APIs, you should seriously consider building out your own backend. It’s better to do it now than scramble to fix issues down the line when they inevitably pop up.

Interested in working together?
Make Contact