fabernovel loader

Mar 26, 2015 | 7 min read

Tech

Baking back ends

Before reading this post, take a moment to look at your smartphone dashboard and spot your most frequently used apps. What do they have all in common? Think about it or pick a guess: turn on the Airplane mode. Fact: It turns out none of them are useful anymore. This is because each of these apps works appaired to a server.

Thanks to the very variety of mobile products we were lucky to design, we realized that high quality and sense of great UX came with a kind of symbiosis between a front end i.e. mobile interface and a back end, the server part of the product.

That’s why today we take a moment to show you how we bake a mobile centric back end at Applidium.

What do you stack in a back end?

As in software engineering in general, back end is an area where giving an exhaustive picture of how things work, would require a thousand posts. We chose here to focus only on the main layers, setting aside other back-end choices for further articles.

A web server

The web server is the layer of your stack responsible for the networking with your back-end clients. In a textbook case it’s pretty boring, as it only establishes a connection with one nice client. It ensures everything sent by the client arrives to the next layer, and that everything responded by the next layer is transmitted to the client.

However real life is not so simple. First, no matter about the manners of your clients, they will not wait for the previous one to be finished before requesting your server. Then, because you’re awesome, there won’t be a few of them per hour, but rather thousands (or more!). Finally, they crave so much your service, they will even request it when commuting. Commuting means poor connectivity, means connections taking much longer than usual, means your server busy waiting for what we call: slow clients.

To face those three challenges, web servers designed strategies such as caching or concurrent connections. However each strategy is a trade-off between service offered and resources consumed, you have then to choose the server implementation that fits your needs.

Our choice: Phusion Passenger

We opted for Passenger, as a majority of the Rails community (and especially the Rails Core Team). It is indeed concurrent, memory efficient and deeply integrated with NGINX, which considerably accelerates static assets requests in particular. All those characteristics made Passenger our chosen one, considering web applications are most of the time hosted on instances with limited hardware.

A web application framework

Getting the request from the server, this layer interprets all its attributes to understand the expectations of the client and compute a response. The role of this layer differing a lot from one project to another, this is the one where most of the software engineer work happens. That’s why here rather than using an off-the-shelf product and tweaking some parameters, you only pick a framework to structure and accelerate your development.

A framework, even if it can be only seen as a frame, determines a lot of things. Because it is where heavy computation resides, it plays a crucial role in the global performances of your service. Moreover, depending of their popularity, frameworks are not equal in terms of resources (documentation, libraries) available. Finally some of them, because of their internal structure, do not enable to leverage some web features (such as push-pull).

Choosing the framework is definitely the strongest commitment of your stack choices. Switching from one framework to another can indeed require an almost complete rewriting of your project. So take your time to weigh the pros and cons for each of them.

Our choice: Ruby on Rails

Many frameworks are actively used and maintained by lively communities. There is no best overall, but one may better fulfill your particular expectations. For us, Ruby on Rails emerged as the one checking most of the boxes.

The factors, which contributed to our decision, were:

  • Maturity: even though we like to play with the latest technologies, we know that a framework needs time to prove its reliability. Born in 2004, Ruby on Rails has since grown each year to become today one of the most widely used framework. If it’s reliable enough for Github or Basecamp, it should be for you.
  • Open source: Using an open source framework allows us to browse its source code whenever we’re looking for an explanation to a specific behavior, or we’re wanting to enhance the framework with handmade features.
  • Lightning fast setup: developing a webservice facing a mobile app is an exercise where one skill is crucial, reactivity. Our clients crave our ability to launch or upgrade an API in a matter of days. In this perspective Ruby on Rails brings with its adoption of Convention over Configuration (or CoC) a speed of development ahead of its competitors.
  • Ecosystem strength: Most of the high-level issues a developer can face today have certainly already been solved. Thus, its features do not only define the quality of a framework, but also by the libraries its community developed along the years. And in this field, Rails takes advantage of Ruby’s proven and abundant package manager, RubyGems.
  • Developer attractiveness: we, Applidium engineers, are sensitive human beings and we know that a developer enjoying his work will definitely do a better job. At this level Ruby offers a syntax, which combined to the conventions of Rails, makes us happy 😉

A database

Contrary to the two previous layers, this one is quite familiar to the non-tech people. Almost everyone knows that behind a website, there is a database. This layer is, as its name implies, responsible for storing all the permanent data.

Traditionally this data has been stored in such a way you can request it in a powerful way, with the popular Search Query Language (SQL). However, to be able to perform these requests, databases have to keep the data ordered in a relational manner, which is costly in terms of performance and requires to host the database on a single machine. With the apparition of giant databases, people started to work with NoSQL, trading-off some requesting features against better performances and the ability to scale out.

The database layer, aside from choosing between SQL and NoSQL, is the one where norms make existing solutions pretty similar. Differences are in details, and you can choose one solution without fearing to jeopardize the success of your project.

Our choice: PostgreSQL

As we picked Rails as framework, our choice consisted in picking one of the three natively supported database systems: SQLite, MySQL, PostgreSQL. If SQLite is the default database of Rails, it is however not suitable for production applications, because of its unique file based nature. Choosing between MySQL and PostgreSQL was not an easy task, as both have really close performances and features. However considering the community running each project, the independency and reputation of PostgreSQL’s one tipped the balance in its favor.

A hosting

The 3 previous layers dealt only with software parts of our back end, but in the end, all of them need some hardware to run on. If it’s still possible to have your own server in the basement, like in the old days, you may nowadays prefer externalizing this service.

First, hardware can fail. An uptime of 99.9% is now the norm, and achieving it internally might require some heavy hardware investments (such as redundancy of every single point of failure). Next, you can leverage the holy cloud.

You give the cloud provider an image of your application, and you decide how many instances of this image should run in the cloud. You’re no longer stuck with physical servers you need to set-up beforehand, here you simply move a cursor to spawn new instances of your application. It thus offers a huge flexibility allowing you to pay for exactly what you need, depending on the evolution of your service charge.

Our choice: Heroku

With the democratization of the cloud computing, people tend to think that hosting complexity is now fully handled by cloud providers. If it’s true they’re taking care of all the hardware problematic, the developers still need to manage the software part of hosting.

That’s why on top of the classic cloud computing services, several companies built platform handling some of the software complexity part. They bill a few more bucks than simple cloud provider would have, and in exchange spare developers tedious and time-consuming software maintenance operations. Often seen as superfluous cost, the premium of those platforms is in the end largely smaller than the numerous hours a developer would have spent maintaining the webapp.

From all the platforms we have scanned and experimented, there is no ambiguity that Heroku, the most famous player in the game, is our number one choice:

  • The Amazon cloud, an industry reference, backs Heroku, so it offers one of the best availability rate.
  • Year after year Heroku has iteratively added the support for more and more technologies, so that today it includes all of the ones we chose, and chances are high that the next one we will adopt will be.
  • For moderated scale projects, it offers a tremendous ratio, developer time saved against premium on the bill. Heroku is indeed roughly twice the price of EC2, which can seems a lot. But when your project only needs a few instances, this premium hardly reaches the cost for one developer’s hour a month, and it’s saving him at least a day.
  • The popularity of Heroku is such that an ecosystem of add-ons has developed around it. Today it’s now smoothly integrated in the platform, and it offers the developers plenty of great services, which can be added to a project in one command.
  • A large part of the back ends we set up had to serve multimedia content. Whether considering the performances or the bill at the end of the month, this is not the kind of content you want to host on your classical server, but rather on a file storage service. Heroku living in the Amazon Cloud, you can spare all the transfer cost between your server, and file storage service reference, Amazon S3.

Conclusion

Strong from our matured technologies choices, combined to our proficiency on our back-end stack, we can today offer our clients a fast and reliable mobile oriented back end set up. We have to admit we did no go for the cheapest solution, we rather favored scalability and portability.

Moreover, we keep our eyes on new components and this stack may be evolving in the near future, keeping in mind that a consistent app is nothing but a nicely formatted real-time data stream.

This is how we bake a delicious back-end. And you, what is your recipe?

Share it with us on Twitter!
logo business unit

FABERNOVEL TECHNOLOGIES

150 talents to face technological challenges of digital transformation

next read