In search of agile stack, or selection of technologies for the mobile start-up

data: 25 sierpnia, 2014
czas czytania: 6 min
autor: Marcin Kania

In start-up projects time is worth its weight in gold. When a product has to be developed as quickly as possible, to leave behind the competition, there is no time getting to know some heavy technologies. Spending time on integrating a number of tools to finally start the very development is also not an option. Therefore, how to choose tools and technologies to instantly pick up implementation of the solution and easily resolve generic issues? For a few weeks now, I have been having an opportunity to develop a start-up and this article describes our current experience.

Starter toolkit

The start of a new project nearly always brings many challenges. It was the same situation in our case. The project is interesting. It is a social application with native clients on Android and iOS platforms. Scalable backend (possible number of users estimated for few thousands of people). Ambitious deadline and a new team. One of the very first questions we asked ourselves concerned the choice of technology, tools and processes. When it comes to the version control system, the Git + gitflow was an obvious choice for us, as it has already worked in many teams in our company. Gitlab is a complement to our set – an open source clone of github, which serves in FP as a central code repository. Choosing bug tracker and wiki also wasn’t a problem. We relied on time-tested tandem from Atlassian: Jira and Confluence.

Tough choices

Having chosen the basic tools, the time has come to select technology. As on the mobile clients’ side the choice is limited and mostly determined by platforms, the backend situation becomes quiet complicated. One thing is certain. Only cloud will let us provide the solution that fulfils requirements concerning the estimated number of users fast enough. Which service model will be the best? IaaS and maintaining servers ourselves, PaaS and using the ready application container, or maybe recently popular BaaS (backend as a service), which will enable us to focus on writing code and forgetting about infrastructure management? The last option sounds tempting, especially interesting seems Parse, quite recently acquired by Facebook, BaaS dedicated to mobile applications. As it is known, there is no silver bullet and each solution has its advantages and disadvantages. In case of such solutions as Parse or Firebase the price for using a ready-made service as a backend is loosing a full control, which usually results in necessity of writing additional code at the client’s side. In case of two client applications the problem becomes even bigger, because the mentioned code has to be duplicated in each of them. Partly, Parse solves this problem owing to cloud code, i.e. possibility to run custom logic logic on backend side. However, it isn’t deprived of limitations. The additional risk is the fact that the majority of our team has little experience in maintaining complex source code in JavaScript, which cloud code is based on; as well as the fact that Parse is still a quite new platform and probably sooner or later we encounter some problems. As a consequence, we decided to step down one level (PaaS) and implement our own backend.

Tailor-made backend

The majority of our team is Java programmers. Is Java suitable for start-up? Just a few years ago (e.g. in the EJB 2.0 times) the answer would probably be „no”. Today the situation is different. The Java ecosystem is changing. Recently, the awaited for a long time changes have been introduced to the language itself, i.a. the lambda expressions were added, due to which the language became more expressive in some cases. Also frameworks are being changed for better in terms of supporting programmer’s productivity. There are also new ones, e.g. dropwizard, which is a solid foundation to build REST web services by integrating a few proven libraries. If someone isn’t up to date with changes in the Java ecosystem, I recommend reading a series of articles: part 1, part 2, and part 3.

That is why we decided on Java. The majority of projects in our company is based on Spring framework. For some time now Spring has been criticised for necessity to write a lot of boilerplate configuration, even in typical cases such as simple REST web service. The Spring’s answer to this critique is Spring Boot, which combines the best features of dropwizard (easiness of launching, metrics and health checks) and Spring (features, easy integration with other technologies). Having great experience in Spring and pleasant memories from working with dropwizard, Spring Boot was very tempting option for us. After short, however quite stormy discussion, we decided to base our backend on it.

Authorization and authentication of mobile applications

We tried not to reinvent the wheel and went for a standard solution, i.e. Oauth 2 and to be more specific Resource Owner Password Flow, which assumes the existence of „trusted” clients, such as mobile applications in our case, that are implemented by us. Spring security provides its own implementation of oauth specification. We had few problems with adjusting it to our needs, however, in the end, we managed to do that.


Having domain, which quite easily can be represented using document model, we quickly narrowed the field of our interest to MongoDB and CouchDB. MongoDB was our choice, as, in our opinion, it is more development and ops friendly. It is a significant aspect having in mind the ambitious deadline. Database engine embedded mechanisms supporting scalability and reliability (sharding, replica set) may potentially save up precious time.


As it has already been mentioned, we rejected BaaS for PaaS. We have little time for development, even less for infrastructure management, so PaaS is an obvious choice. At the same time, we wanted to have the ability to smoothly migrate to the lower level (IaaS) in case the application architecture has changed so much that it would no longer correspond to patterns usually supported by PaaS providers. We chose Elastic Beanstalk, which is a part of Amazon Web Services. Then, we integrated it with our building process, based on maven, with the use of beanstalk-maven-plugin. Nevertheless, we still have in minds the presentation Mobile + HA + Cloud = Successful Mobile App HOWTO from this year’s Geecon, which alert to consequences of choosing AWS as a „no brainer answer” and for sure we will monitor the situation.

The devil’s not so black as he’s painted

Integrating all the pieces went quite smoothly. We quickly went to the moment when after a successful build in Jenkins testers have the newest backend build deployed on Elastic Beanstalk at their disposal. Still, there are many challenges ahead of us, but having a well-integrated set of tested technologies and well-established development process, we can face the future with confidence.


Zainteresowały Cię nasze treści?
Sprawdź co jeszcze przygotowaliśmy.

Adres e-mail

Dziękujemy! Na Twój adres e-mail wysłaliśmy prośbę o potwierdzenie zapisu do newslettera.

O nie! Coś poszło nie tak. Nie zapisałeś się.

Gdyby tylko dało się zapisać Twojego maila dwa razy :)

Niepoprawny mail. Spróbuj jeszcze raz.


W pracy serwujemy suchar dnia. Tutaj musimy Cię poczęstować ciasteczkami. Dowiedz się więcej.

Administratorem Twoich danych osobowych jest Future Processing S.A. z siedzibą w Gliwicach. Twoje dane będziemy przetwarzać w celu przesyłania cyklicznego newslettera dot. wydarzeń i inicjatyw realizowanych w Future-Processing. więcej informacji znajdziesz w naszej polityce prywatności.