Sooner or later any Android, iOS or Windows application wants to get outside of the local hardware box and start to communicate with the outside world. In case of our application we new that already from the very beginning that we are going to have a back-end web services in one or another way. At the beginning of the project, after the user requirements were set, and the architecture of the solution designed, it seamed quite straight forward to implement our back-end services. Bellow is the architecture we decided to use for our Fitradar system.

But in the process of the implementation we realized that quite often we have to adjust our back-end web services API. So in this article I want to share some experience we had while joining our client applications with back-end web services.

Initial approach

First we divided the whole system in 4 sub-projects:

• Android application
• iOS application
• back-end web services application
• the project website application

and created 3 teams. We thought the client application teams and web services team will be able to work independently after the APIs and data contracts on the web services were defined. Once we received the UI designs we started to model web services API and data contract between the applications. And when the data contract between the applications was defined the back-end team started to work on the web service implementation, meanwhile application teams started to work on the UI (User Interface) part.

We estimated that by the time application teams will complete one use case UI, back-end team will implement the web services for that use case to the degree that they can start to receive and send data.  The first use case we picked up was user profile creation. The interaction between the client application and back end services went smoothly. Web service received the user profile data and stored that in the database. So we took the next use case – displaying full user profile information to the profile owner and limited information to other application users.

The problem

As we started we thought it will go fast and smooth since all we needed was to fetch already stored data from our web service. But soon we discovered that the data coming from the web service is not complete. We needed to display some statistics about the user activity. Since on early stage of development and user requirement gathering we new very little how the statistics will be calculated, we assumed that some of them we will be able to calculate in the clients application and some we will be calculated on the back-end server. It turned out that some statistics we were not be able to calculate in the client’s application and we needed to fetch more data from the server but on the other hand to calculate statistics on the back-end server we needed more input data from the user during the profile creation. So we had to change the data contract for the user profile creation and for user profile fetching web service end points. And when was the time to move to the next use case – sport event creation, we decided to call for a meeting to find a better approach.

Different approach

After some brainstorming we decided that both teams should work simultaneously on one or two use cases. When we had to work on use case that shows some data we kept an eye on the use case that sends this data to the back-end web service.  It means that we always started with the use case that fetches data from the web service and displays data to user. Application team started with UI that was unambiguous, since we had UI designs and we new quite well what we want to see in the UI. In the development process along with UI layout View Model was created. This View Model clearly defined what data we need in order to meet the design and functional requirements. Now we could see what business layer entities can provide the required data. And once the entities were defined for the use case we could tell what endpoint we need and more important what data these endpoints should provide. So at this point the data contract for fetching data was quite stable (it had some minor changes later nevertheless, but mostly because we decided to introduce change in UI design).  And the back-end team now could see if they can provide the required data form the data they will gather. If something was missing on the server the back-end team adjusted the data contract for incoming data accordingly.

To make this process more smoothly and allow the teams to work independently as much as possible application team instead of real network calls used mock objects that returned the required data. And the same did the back-end team for incoming data.

Another thing that back-end team had to keep in mind was, if we really should be the ones that provide the requested data. For example, after user profile use case analysis it quickly became clear that we should delegate the user’s profile picture storage to third party services like Cloude Storage

Conclusion

The one thing we learned is that the more complex project is the more difficult is to come up with precise requirements. We were familiar with the agile development model and applied it extensively on the project bases, but we thought that the interface between the client and the back-end is clear from the initial requirements. We were wrong, the web service interface was changed in several iterations because the discovered more requirements for the client application. So the conclusion we made is that for bigger projects we have to apply iterative development approach for the whole system, we can’t really make the projects independent from each other. We had to check the initial web service interface after each implemented use case and see if we need to make changes there. So are final web service API and data contracts after several use cases looked quite different than that we designed in the beginning.

http://fitradar.me/