The dawn of the REST API — Part 1
After being involved in the development of several mobile application products for clients and partners, I started to notice common patterns emerge during the process. One in particular was the friction between the mobile (Android & iOS) and back-end teams.
This is Part 1 of a series of posts describing why it may not make sense for your project to develop a custom back-end, analyze the different alternatives, their benefits, and drawbacks. But first, you need to understand the process required to develop a typical mobile application.
The development process
At Wolox, most mobile projects consist of Android, iOS and back-end teams. The back-end team is in charge of developing the back-end web services that support the mobile applications. These usually consists of a Ruby On Rails REST API using JSON as the representation format. The default tech stack consists of RoR, PostgreSQL, Amazon S3 and Sidekiq. For deployment, we typically use Heroku, Amazon EC2 and lately we have been using Amazon Elastic Beanstalk.
With many of our clients being entrepreneurs who are looking to develop their first MVP, time to market and cost effective solutions are key drivers of the product. For us, this usually translates to a small team that generates a lot of value sprint after sprint, moving really fast (and trying to break as little as possible).
An important characteristic of these type of projects is that the majority of them are mobile only, reducing the web version of the product to a minimal landing page that communicates the key points of the product and links to the app store of your platforms of choice.
The development process varies depending on the client’s needs. Generally, they consist of a period of product building together with our UX team. This space is used to understand the main problem the product is trying to solve. From there we are able to iterate different solutions, gathering input from other departments (e.g engineering and design), until we feel our solution is worth implementing. The end result of this process consists of a set of wireframes describing the application’s flow.
After the product building phase, various processes begin in parallel. The design team starts working on the final design of the application: designing the logo, picking the color pallet and transforming the low-resolution wireframes into beautiful application screens.
At the same time, to accelerate the development process, mobile teams kick-off the new project and start prototyping a working version of the application flow provided by the UX team.
Although the design is not ready yet, we can start working on the functional requirements and minimize technical risk. This also allows us to show working versions of the application to our client so they can begin testing it internally (or with users) to validate that the current application flow is the right one.
To avoid being locked down by an endpoint that has yet to be designed we use services such as Apiary to implement a mocked version of the endpoint. This allows us to iterate faster on the endpoints and gives the mobile team the possibility of designing the endpoint as they see fit.
The kick- off of various teams in parallel allows you to be more productive on all fronts. By exhibiting a faster more continuous progress, we are able to minimize locks between teams. Additionally, each team may have several internal iterations of their work before presenting it to others. Yes, teams usually introduce other teams feedback as soon as possible however, they avoid committing to a design (either code or visual assets) until it has been approved by the client and in some cases tested with users.
By doing this we minimize breaking changes during the development process and other delays caused by having to re-implement a screen. This may be due to the design solution having problems or unable to be implemented in the required time. In order for this process to work, sprints and validation cycles have to be short and the client and users should check deliverables on a week by week basis.
Do you want to know more about our development process and the different approaches we take to be more productive, reduce cost, prototype and deliver faster? Stay tuned for part 2!
