Choose a Platform For Building an App Leveraging APIs
Imagine that you have an idea for a small app to build, leveraging multiple 3rd party APIs. What platform would you build on? Why? How would you get started? How would you measure success?
What can we ask to understand the requirements better? Do we know who we are building for?
For most apps, we will typically need a frontend and a backend. How would these potentially talk to each other? What format does data typically need to be in for systems to have seamless communication?
If people are using our app all over the world, what can we do with our infrastructure to make it quicker for them to reach it? What can we do about storage to speed this up as well? What analytics are most important to our success?
What questions did we ask before picking an example app? Do we know who we are building for and if there are any specific requirements?
Did we discuss the multiple systems our app would need to interact with? What would an example API request look like to our backend? How would it respond? What other endpoints may we need to consider?
How do we make sure our application is robust and fault-tolerant? When considering global scale, how would we need to adapt our architecture? What are some things we can do to speed up or optimize app performance for users in specific regions?
Clarifying Questions
This question is can be simple or complex, depending on the position you're interviewing for, your seniority, and at what stage of the interview you're at.
You'd want to get a sense of the level of depth the interviewer is expecting, and what's considered out of scope. Regardless of what direction you'd like to take it, be sure to ask if there's any expectation for scaling later. Even if the interviewer says no, be sure to spend a few minutes at the end discussing any changes you'd make to scale up significantly.
Assume, through some back and forth, that you've defined the following requirements:
- You're free to pick something you’ve built before, or choose one of your favorite apps.
- Our definition of "platform" is broad - whatever you are most comfortable with. For example, you might pick mobile app, a cloud platform, a work automation platform, etc.
- There's no need to write code – we're just looking for the high-level architecture to understand your thought process.
Solution
Step 1: Discovery
Start by first gathering any app requirements we have. Does there need to be a UI interface? Is there a specific target demographic / user base we are building for? Is anything specific we need the app to accomplish?
For simplicity, let’s pick an app everyone knows: a weather app.
Step 2: Design
The key to the design phase is to figure out what systems will be part of our architecture, how data is transferred between them, and what they will look like. We also have to make a decision on the platform and define why. This can vary based on what we find in the discovery phase, but let's assume our weather app is for millennials in the US so a mobile platform like iOS makes the most sense. If we were making a weather analytics app or something more data-oriented, we may have chosen a cloud platform to handle the computational workloads.
Typically for any sort of mobile application, there are backend and frontend services that will need to communicate with each other via API. In the case of our weather app – we will need a frontend mobile app (to house our UI), a backend service (for our UI to talk to), and perhaps a third-party weather API for our backend to query for real-time weather data.
This is a good time to also pause and diagram/whiteboard a high-level architecture:
Once we know what the relevant systems are, it's important to discuss the format in which they will communicate. For example, once a user opens the app on an iOS device, the app will need to make a /GET request to a /weather endpoint hosted by our backend. We can pass location as a parameter from the mobile app to the backend, so the API knows where we need the weather for. Then, we need to think about what the response from our backend will be to render an appropriate UI. Then, we need to think about what the response from our backend will be to render an appropriate UI. Assuming a standard JSON format, its safe to assume our backend API will respond with something like this:
It’s also good to discuss what additional functionality and endpoints we may need down the road. For example, our users might want the ability to search for weather in other cities (because they’re traveling there), the weather over a specific time period, the chance of rain/snow, etc.
What would a user in California asking for the weather in Boston the following week look like? On the UI side of the mobile application, we’d need some sort of search box for gathering the input of the desired city name. By default, we can return the weather for the next 10 days, assuming the user is likely curious about weather information in the near future. This means we need a slightly different endpoint and data structure now from what we had previously.
We can create an additional endpoint called /weatherByCity where making a /GET request will return an array of weather information for a specific location. If a user passes in “Boston” as a parameter, we can imagine our endpoint will respond with a JSON object similar to the below:
The key difference here from our previous endpoint is that the weather is now returned in an array, listing out different dates and weather information for that day. The iOS app will then need to just ingest this array response and display it accordingly in the appropriate UI view to the user. We now have our systems finalized and an example API they will use to talk to each other, let’s move on to how we would need to architect for success and scale.
Step 3: Scaling & Success Measures
Things to consider here for scale will be primarily related to how our backend handles and distributes requests for potentially millions of users. Since our user base will start in the US, we should architect for having a locally distributed backend in multiple zones (US-East, US-West, etc.). This way in case there is an issue in one region we will have the ability to fail over to another. Also, if the app is successful in the US, we should potentially plan to scale globally as well.
Ideally, we’d want a globally distributed backend to reduce latency within the mobile app (i.e. you don’t want a user in Japan needing to query a server in the US for weather). At scale, we will also need a load balancer to handle millions of concurrent requests, and distribute them across our infrastructure. Finally, it is worth mentioning caching as an option regionally when there are multiple users gathering weather for the same location – as this saves us the overall amount of data dips we need to make.
We can wrap by discussing how we can measure success outside of just counting users. Important metrics we may want to analyze are: What's the average time a user spends in the app? Are our users using the app daily or just once in a while, and are there things we can do to increase the frequency? Also, is our app more popular in certain regions than others? As our user base scales, is our application backend maintaining a low error rate and sustaining high uptime? All of these data points become important in claiming a successful app launch.