How to unblock your mobile app development while the backend isn’t ready

Moving forward with application development with unresolved dependencies

Photo by Jungwoo Hong on Unsplash

Consider the construction of a complex puzzle — a mosaic of interconnected pieces that come together to form a complete picture. Similarly, software development can advance despite dependencies, just as the puzzle takes shape even if some pieces are missing or out of order. The same thing is the case when it comes to software development. Imagine each puzzle piece as a separate module or component in the software development process. While some pieces might rely on others to reveal the full picture, progress can still be made by focusing on the available pieces. As developers work on individual sections, they can refine and perfect them independently, contributing to the larger whole. In this blog, we will try to see what as mobile developers we can do while we are still waiting on the backend.

Mobile application development primarily has two components, front end, and back end. Often you will run into situations where as front-end engineers you need to work on the application while the backend is not ready.

So what can we do to make progress when the backend isn’t ready?

We will try to answer this question by taking an example. Say you are making an application that lists movies based on your search and the backend is not ready with an API that you can consume. Following are the steps that we can take.

1. Settling API Contract/Response With Server Team

We can discuss with the server team what the data model for our application looks like.

• Come up with a data model for the movie

• Since we are going to list the movies, we need a response that gives us a list. So after working with our server team, we could come up with something like this

{
    "movies": [
        {
            "id": "tt0076759",
            "Title": "Title 1",
            "Year": "1977",
            "Poster": "https://abc.com/url1"
        },
        {
            "id": "tt2527336",
            "Title": "Title 2",
            "Year": "2017",
            "Poster": "https://abc.com/url2"
        },
        {
            "id": "tt2488496",
            "Title": "Title 3",
            "Year": "2015",
            "Poster": "https://abc.com/url3"
        },
        {
            "id": "tt0120915",
            "Title": "Title 4",
            "Year": "1999",
            "Poster": "https://abc.com/url4"
        },
        {
            "id": "tt1185834",
            "Title": "Title 5",
            "Year": "2008",
            "Poster": "https://abc.com/url5"
        }
    ]
}

• Pagination for response: We can discuss with our server team regarding the pagination type that will make sense for the project, be it Offset, KeySet and Cursor Based pagination.

2. Coding the model and dependency structure

So now when we have the data model and sample data response after discussion with our server team, we can start with the part of our application we know the most about. In our example, we can with working on a networking layer that could be platform agnostic. Here is the sample code looks like this

struct Movie {
 let id:UUID
 let title:String
 let year: Int
 let poster:URL
}

protocol MovieLoader {
 func fetchMovies(completion: @escaping (Result<[Movie],Error>)->Void)
}

Since we aren’t sure at this point in time whether the app needs to support offline/local lists of movies as a backup if online fails, our protocol-based approach will help to implement the Local and Online loader when needed.

The diagram above shows the potential approach we can go with.

3. Delivering sample hard-coded response to the client

Once you have implemented the basic network layer going, we can have this hard-coded response data in multiple ways.

a) Local bundled json

Adding local JSON as part of your Xcode project and response with local bundled JSON.

b) Using Charles Proxy With Map Local

You can use any dummy url that the client tries to fetch and you can use Charles proxy to return the sample local JSON response. I will try to write a detailed implementation of this in a separate blog for this in the future.

c) Running a local server

We can run a local server and return the desired response. You can use things like node js or MAMP to deliver the response. I will be covering the detail of this in a separate article.

Conclusion

In conclusion, the blog emphasizes the importance of parallel development and adaptability. Like fitting puzzle pieces into place, developers can continue building and refining various aspects of the software, even if certain dependencies are unresolved. This approach allows for efficient utilization of time and resources while fostering a flexible mindset in the face of uncertainties.