The tale of Cheerz technical stack
From Cheerz’ very beginning (2012) to the present day, we’ve worked with many technologies before converging on our current stack. Here is the short story of our experience.
(Updated in February 2020)
iOS app
~100K Lines Of Code
Initially developed in Objective-C, we have fallen in love with Swift language, from its type system great features to its concise syntax.
The last line of code of Objective-C has been removed in 2019 🎉!
Because it was a great match with Fastlane and Cocoapods, and because this is our main scripting & backend language, the tools and utils around our app are written in Ruby.
Android app
~100K LOC
Intially written in Java, we’ve started development with Kotlin a few years ago (way before Google announced its support). In a similar way as Swift did, the Kotlin language has really convinced us, all developments are done in Kotlin, and Kotlin now represents more than 80% of our codebase.
Android + iOS
We are absolutely convinced that Android and iOS applications should share as much as possible: If not code, at least architecture, interfaces, naming, configurations, etc.
Since the introduction of Kotlin Multiplatform and Kotlin/Native, we have followed very carefully its development, since we see great potential in it for cross-platform development. We have even shipped a small brick of Kotlin-based code on our iOS app, but so far, we haven’t got further and we even think of removing it to simplify the stack.
On the same kind of philosophy, we have also tried to introduce React Native in a small non-strategic part of our app, but have removed it in 2019 : We understand all the benefits React Native could theoretically bring, but at Cheerz, because it’s maintained by non-web developers and because it brought the complexity of another stack on top of the iOS stack, we tend to think that React Native has given us more trouble than worth.
We use git submodules to share configuration (in JSON format) between our iOS and our Android apps.
Front-End
~60K LOC
We started the current version of our web application as a part of a Rails project back in 2013. At this time, the choice of a framework was basically between Angular, Backbone, and Ember. We started with Angular, and were very happy with it for a long time.
Over that period though, we actually aimed to have less and less logic relying on it. In addition to that, we had performance issues with our version of Angular and in the same time, we really believed in Component-Based Design: It was the moment for us to move to another framework that would fit all of those needs. We really liked the Single File Component approach, and at the time we made this choice, Facebook still kept React in BSD+Patent : Vue.js was the winner, and the migration had begun.
Independently of Vue.js, we had faced a lot of challenges migrating big parts of our application because our Angular code was very coupled. However, after a while, we had the great opportunity of writing from scratch a very strategic part of our web application : the customization. At this time, because of the tooling around the framework and because our engineers were more comfortable with React, we decided to continue the migration, not toward Vue, but toward React… But this might be the story of a whole other article!
Long story short: All new parts of our web-app are developed on React, and we try to push to a heavy use of Storybook, that we happen to love.
On the language side, we have started with Coffeescript, before converting all of our codebase to ES6 in 2018, before introducing TypeScript.
Current stack (March 2020):
- TypeScript
- React
- Storybook
The back-end services
~100K LOC
After the clients, comes of course the question of what there is behind them! On the back-end side, we currently have a few services that have slightly different environments, but all of them rely on Ruby, and the Ruby on Rails framework.
We have had some experiments, and even more, some backend services in production, that were relying on other technologies (ES6/Express and Go), but with the time, we decided to make everything converge to the Ruby on Rails stack.
We know that Rails and Ruby have their defaults. Enough so that we at least gave a try to other technologies… But we still happen to love them ❤️. Rails framework and Ruby language allow us to craft complex applications quickly so that we can focus on core business features. The ecosystem is amazing, and Ruby language is very straightforward, yet extremely expressive.
Current stack (March 2020):
- Ruby (≥ 2.6)
- Rails (≥ 6)
The Databases
We have used MySQL, PostgreSQL and MongoDB in our different services, but the only DBMS that really got our heart so far is PostgreSQL.
At some point, we did decide to migrate one of our biggest databases from MySQL to PosgreSQL. The whole process of converting the dump from MySQL format to PostgreSQL took more than 6 hours 😴(mostly to run huuuge Sed scripts). But in the end, we really enjoy working with PostgreSQL. It provides us good performance and really useful features (like JSON data type).
We also use Redis to store data for background processing with Sidekiq.
Current stack (March 2020):
- PostgreSQL (11)
- Redis (5)
Key takeaways
We love our stack. It has its defaults and thousands of competitors, but in the end, we truly believe that good engineers should not focus too much on the stack, but instead on how to solve problems efficiently, with good data structure, architecture and methodologies.
All stacks can be valid, the only things that matter is how productive it makes you, and the pleasure you get from it!
You want to join our team to write with us the future of Cheerz technical story?
Contact us!
