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.
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.
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.