Smart connections between data and product
In order to connect data to our apps and/or websites, a smart backend (API) is required. We assume the principle of "dumb apps and a smart backend". This is because is possible to update servers instantly, so bug fixes can be deployed as fast as possible.
Most mobile applications developed at 9to5 are connected via an API to a database. Below are techniques that we use every day to create high-quality APIs and apps.
Ruby is suitable for many different tasks. At 9to5 we make websites, APIs, command line tools and gems (plugins) with Ruby.
9to5 makes extensive use of the Ruby on Rails framework. The advantage of Ruby on Rails is that there are many 'plugins' available. This allows is to quickly work towards an end result. Our Ruby on Rails solutions always contain RSpec tests so that we can guarantee the quality of our software. Changes are saved via GIT and checked by other developers via pull requests. After merging the pull request, the code is automatically tested on the continuous integration service CircleCI and if no errors are discovered, it is deployed.
For small APIs, using Ruby on Rails is overkill. In these cases we like to use Sinatra. Sinatra contains less functionality, which benefits speed and security. Due to the arrival of Elixir and the Phoenix Framework, Sinatra is chosen less often, but if the use of Ruby is desired in the project, this choice is still made.
Because not every website contains dynamic content, we also use Middleman. Middleman allows us to quickly generate static websites, the code is stored in our GIT repositories and in case of a change we can easily make an adjustment and push it to GIT. These changes are then picked up by our CircleCI service to be built and automatically deployed to Amazon S3 and Amazon Cloudfront. In this process it is very important that our internal workflow of reviewing pull requests and deploying automatically after acceptance is followed. So it doesn't matter whether we deploy a static website or a large API with a frontend, everything follows the same workflow.
A new emerging programming language is Elixir. For developers who are used to Ruby, this is an easy transition. Elixir is based on Erlang, has been around since 1986 and was developed for telephone exchanges. For telephone exchanges, concurrency and fault tolerance were very important. It just so happens that these are also very important properties for an API.
For API development we use the Phoenix Framework. We also apply the workflow that we use for Ruby on Rails in the development of APIs in the Phoenix Framework. ExUnit is used for the tests and can run continuously due to the speed of Elixir.
All 9to5 APIs are hosted in the cloud on Heroku. We have explicitly made the choice not to provide the hosting ourselves, but to focus on software development. By outsourcing the hosting, we have more time and budget to make beautiful apps and websites. Heroku's hosting is very reliable and secure. Because a deployment to Heroku is no different than pushing to a repository, it integrates nicely into our CI/CD process. It is very easy to run multiple versions of an API on Heroku, which is why we always use a production environment and a staging environment. Production is used by the customer and end users, the staging environment is used by app developers.
With static content, it is important to get the data to the user as quickly and securely as possible. By saving the files on Amazon S3, they are in a safe and reliable location. Amazon S3 in combination with Cloudfront makes sure that files are delivered quickly. Cloudfront stores a cache of files near the users. Files arrive at the user faster, because they need to travel a shorter distance. A big advantage of Cloudfront is that SSL connections can be used for free, so all communication is secured via HTTPS.
Our choice for the primary database is PostgreSQL. This is a very reliable database and is supported by Heroku. Due to continuous backup at Heroku, the chance of data loss is very low. If more uptime is desired, more expensive production databases can be used. Many of our apps use location data and with the PostgreSQL extension PostGIS, queries can be performed quickly and efficiently on this data.
For super fast queues or temporary caches we use Redis. Redis is an in-memory data structure store. Which means that we can store and quickly retrieve different data structures. Unlike a database, no queries are possible, but operations on the data are very fast. Redis is now in use in combination with Sidekiq for background processing and for Pushr to send 9to5 push messages.
Continuous Integration and Continuous Deployment
The most important part in our workflow is pushing our code to our GIT repositories. The code is then automatically picked up, built and tested by our CI/CD service CircleCI. If the tests are successful, a new version is immediately released online. With this we ensure that our release cycle is short and that releasing a new version is not exciting, but just part of our daily work. When we're working on a project, it's not uncommon to have multiple releases in one day.