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.

When you start thinking about the backend API for your mobile app, it can sometimes be tempting to just dive right in and start building something. While this can be effective to get your app out the door, having a solid plan for your API can save you time and aggravation later.

In the past, I’ve written about how to futureproof the client side of your API calls, but today, I’m going to focus more on the actual backend itself, with a few questions that you should be asking yourself before you ever open your text editor.

Recently, one of our clients was experiencing a lot of extra traffic, and we took the time to set them up with AWS autoscaling groups. Moving to autoscaling has mostly been a breeze, but we ran into issues with deployment. Here are a few lessons we learned while setting up autoscaling and CodeDeploy.

It’s a fact of life: some users of your game are going to try and cheat. There’s no getting around it, especially in multi-player games. While there’s no one silver bullet, there’s a lot you can do on your backend to help detect and deter cheaters.

Glenn Fielder wrote an awesome post the other day on how big name first person shooters prevent cheating, using the concept of “never trust the client”. This is a principle that applies to all sorts of software, including your app.

Whether you have an in-house dev team, you hired a consultant to build your backend, or you’re using a hosted backend like Parse, Firebase, or Telerik, it’s important to have a good feel for what the current state of your backend is. I put together a quick list of 9 of the questions you should be asking about your app’s API layer.

I was recently browsing Reddit when I came across a thread asking “How bad is Ruby on Rails performance, really?”, and I wanted to expand on it a bit, in the context of the projects we work on at 3e8.

Amazon Web Services (AWS) are everywhere. Seriously, I bet you’ll visit a couple dozen sites today, at least, that are built on it. But does that mean it’s right for your app?

At some point, you’ll likely need to drop support for an older version of your app. Perhaps a critical bug popped up, or it’s just calling an outdated version of your API—either way, you need your users to upgrade.

The problem is, once someone downloads a version of your app, there’s no taking it back. Until they upgrade, they’ll be using the outdated release, and, depending on how they’ve configured their phone, that might be a while. So how do you gracefully discontinue the old version of the app?

As soon as you put your app out into the wild, you can’t take it back, and your backend will have to support it going forward. While no release is perfect, wouldn’t it be nice to avoid issues before they happen? With a little bit of planning, you can.