How to solve the Facebook iOS App Design Interview — Amazon Engineer perspective

Clarification

• What part of the app should I design? Authentication? Feed? User profiles? Messaging? Post comments? Application nowadays serve a multitude of purposes with an infinite amount of features.

• (If for example a messenger app) What kind of attachments will the design support? If we don’t have to worry about images, then we don’t have to worry so much about caching. If we have to support map locations, do we need to worry about map performance? We need to ask the interviewer all kinds of questions to demonstrate our understanding of scalability.

• Do I need to design uploading functionalities as well, or just the data output? For example, for a new feed, it’s possible that creating feed items is also part of the design. Although, it typically isn’t.

• (If you’re as familiar with it as I am) Is it okay to assume a Firebase backend so I can demonstrate my strengths best with my past experience? Just ask the interviewer if it’s okay if you demonstrate an example utilizing an industry standard method you’re best familiar with.

• (If some kind of social media feed) What kind of feed items? Facebook, for example, supports tons of different types of elements. Everyone of them might deserve its own microsystem and so we need to define the focus.

• Scalability. We need to write an application that will be able to serve countless users, and handle an excessive amount of content all over the world.

• Security. The application needs to at least match the high industry security standard in terms of authentication, networking and data storage.

• High Velocity Development. Arguably as part of scalability, we need to support many users, as well as, many engineers. We need to lay out the foundation for a scalable code architecture that can support thousands of commits a day, without major disruption through merge conflicts.

• Separation of Concerns. The design should demonstrate your seniority and understanding of code architecture in terms of clean code. Write services and managers that are easily interchangeable and are concerned about only themselves.

Overview

• NetworkingManager - Responsible for all requests that go outside of the application. Firebase, as part of an SDK, with its own wrapper of network operations would be left out of the following, but with a networking manager, the idea is to wrap all operations that interact with the internet. So all kinds of Alamofire or URLSession operations and tasks. Another example could be a delegate method to the AppDelegate that could cause some kind of UI banner, notifying the user of missing network connection, and kicking off some kind of offline mode.

• DatabaseManager - Responsible for taking in database requests and returning states to potentially notify the user of issues. The advantage of wrapping database operations inside a wrapper class, is best demonstrated here. We could replace Firebase with AWS, without the rest of the application being affected at all. Only one class needs to be adjusted.

• UserManager - Responsible for all auth related operations. Logging In. Logging Out. Provides some kind of observable API to make sure the app switches state when the auth state changes. A class best implemented in a LandingController class. When the auth state switches from user to nil, LoginViewController gets presented, and once logged in, FeedViewController.

• AppDelegate - Instances for most managers are created, and passed down the view hierarchy using dependency injection. A NetworkingManagerProtocol could then have its delegate in the AppDelegate, and state changes could be kept and processed from there, creating visual indicators for the user.

• FeedManager - Responsible for getting feed items. Has dependency on the DatabaseManager, and wraps everything needed from database to feed list. Casting database items to FeedItem objects, as well as caching, and handling errors and states. Providing APIs for its consumers. For example the FeedListViewController.

• ImageManager - Provides a one-stop API to get images based on a URL parameter. It wraps the ImageLoader, and provides APIs like getImage(forURL) and uploadImage(forElement,image) and handles everything from loading, caching, all the way to error handling.

• ImageLoader - Not exposed to consumers of the ImageManager, but a private dependency or initiation within, the loader itself has a dependency on the NetworkingManager. Remember: All networking requests are meant to go through one dedicated API.

• ImageCache - Dependency of the ImageLoader. Provides an API to cache and retrieve images into and from the memory cache. Controlled using an LRU. A least recently used object queue.

• UIViewController - It's important to mention to the interviewer that the view controller's only concern is to present elements to the view, and define view specific attributes. The remainder of the business logic is handled by prior defined API wrappers, the ...Managers classes.

enum Image { // 1
  case image(UIImage)
  case thumbnail(UIImage)
}enum LoaderResult { // 2
  case success(Image)
  case failure(Error)
}class ImageLoader { // 3
  func getImage(from url: String, onLoad:@escaping ((LoaderResult) -> Void))
}

1. Image enum, to demonstrate that we will have thumbnails for reduced perceived latency of the user. Demonstrates that performance is important to us.

2. Result enum, to demonstrate that we write clean code and define secure types, and understand how to structure code well. Those are all important aspects of scalability.

3. Dedicated ImageLoader, that demonstrates "separation of concerns". Having a clear, one-stop service to handle all "image loading" requirements. A clear defined API for future consumers.

Scalability

Security

• We won’t store sensitive information in the UserDefaults, as that storage does not enjoy higher encryption, and is therefore not safe against exploitation.

• One trick to safely secure API keys is to utilize a private CloudKit database. This is potentially vulnerable against “man in the middle” attacks. But every idea in security can be countered with a “but”.

• A good practice to securely store Secrets, is to utilize a .xcconfig configuration file, ignore the file using a .gitignore, and reference the Secrets within the configuration file in code. That way, you're not exposing Secrets in your repository.

Caching

Offline Support

class DatabaseManager { // 1
  private let offlineDatabase = OfflineDatabase() // 2
  private let onlineDatabase = OnlineDatabase() // 3

  public func query(_ path: QueryPath, onLoad:@escaping (DatabaseResult) -> Void) { // 4
    offlineDatabase.observe(path) { result in  // 5
      onLoad(result)
    }

    onlineDatabase.query(path) { result in // 6
      offlineDatabase.store(result, forQueryAt: path)
    }
  }

  public func store(_ payload: Payload, forQueryAt path: QueryPath) {
    offlineDatabase.store(payload, forQueryAt: path { scheduler in
      // 7
    }
  }
}private class OfflineDatabase {
  public func observe(_ path: QueryPath, onComplete:@escaping (DatabaseResult) -> Void)
  public func store(_ payload: Payload, forQueryAt path: QueryPath, onStore: ((SchedulerResults) -> Void)? = nil)
}

1. As always, we want to demonstrate that we’ll write clean and well-structured code, with separation of concerns. We will have a dedicated model for all database related tasks.

2. We’ll have a dedicated OfflineDatabase

3. And a dedicated OnlineDatabase

4. A query function that takes a QueryPath, some type of structure we specify as a prerequisite. We would communicate to the interviewer that we'd plan on having such types, but we will not be expected to implement every one of them.

5. The idea is to observe the offline database and forward the information to the closure, down to the consumers.

6. Then, we’re using the online database, to update the offline database. And since in #5 above, we said that we’re observing on the offline database, new information will automatically be forwarded to the consumers.

7. Any kind of uploading functionality has not been set as requirement for this interview, but we provide a stub to demonstrate that the upload functionality will also be handled in this wrapper.