Year after year, developers talk about a new framework, architecture, or language. It's something that sparks so much joy in the community, that everyone starts talking about it: in every article, event or lecture.
For us, here at iFood, 2019 was all about monorepos and Clean Architecture.
Before getting into the details, let's take a few steps back to get a clearer view of the iOS development team.
An expanding team
The year is 2015, and the team was huge. A brave developer. A new project was created and all existing code was translated into Swift. A year later, the team would grow to about three developers. More features implemented, more complexity. In 2018, the company reached new heights and the team completely changed: from around 6 developers to more than 20 people.
This put us in a situation where we had to look carefully at how we were doing things. We had more code coming in daily, more resources running simultaneously, more maintenance to be done. If we didn't organize and create standards, we would end up with a very complex, chaotic codebase.
I'd like to say that didn't happen, but...
The turning point for us was when a new product was released around December 2018. It had tons of code that we could share, from business rules to network frameworks to UI components. But we had a huge monolith, full of interdependencies, more than 10 minutes of local build time, more than 40 minutes of build in CI and some frameworks in their own separate repositories.
It was horrible adding and testing new features quickly. We started to have more and more duplicated code, version conflicts, framework on each product and so on.
At the time, the solution was very clear: let's create a monorepo – a single repository. This way, the entire code base would be in a single repository, with different structures for each part of the code, and we would no longer have problems with duplication or version control.
The beginning
Firstly, we had to organize the monorepo and determine the owners of each part of the code. In February 2019, we did a basic reorganization of the folders, placing each resource in squad subdirectories. A change with more than two thousand files changed. It was a bold move, to be sure, but it was desperately needed and helped us move forward.
So we had to bring these shared frameworks and libraries from separate repositories into the monorepo. So the following week we created our first two modules using Cocoapods locations. One was a network layer framework and the other was a product feature now known as Loop, our launch feature. We discovered the need to name things and create a standard for how modules were created. It was then that the microfeatures entered the scene.
Microfeatures: what are they?
You've probably heard the term “microservice”. It's on the rise, and software developers backend are committed to creating small, individual services with a single responsibility. Another term that is becoming very popular is “micro frontend”, which has the same proposal, but for developers of frontend. Microfeature is just another term for a small module, with a single responsibility that exposes an interface so that other modules can interact with it.
We really like the definition proposed by Tuist, as it goes one step further and divides modules into two types: base and product.
Base µFeature
Modules responsible for a specific task, such as HTTP calls or UI components, Remote Config and so on.
They don't have any business logic involved, they expose a set of classes or protocols and we can freely import and use them throughout the application. They can be fully tested and the compilation time is fast.
Product µFeature
These are features that your user can see, such as a login flow or a login page. Check-out, a restaurant menu, etc.
They not only have the business logic, but also the screens, the routers, the use cases, the repositories, and all the layers Clean Swift It is Clean Architecture.
Additionally, they should expose a sample application to facilitate development. If you are working in a µFeature of product, it will only compile the entire product at the time of integration.
Managing the monorepo
Things can get very complex quickly in a monorepo, especially when you have 40+ iOS developers working on it. Managing all modules with local pods just wasn't suitable for us anymore, so we had to find a tool to do this job. It was then that the Buck came onto the scene.
Around July 2019, we decided to use Buck as the build tool for our project. It was a big change, but one that only a few people had already mastered.
We learned a lot about how to share knowledge during a migration process and how not to keep most of the knowledge focused on one person. We learned that we have to communicate, teach, and that we need a team to handle developer operations.
Today, we are looking for a lot of information in the Airbnb repository, because they are very active in the community and open most of their adaptations and tools.
Two years later… is it still working? It was a good idea?
It was certainly the right decision to continue scaling our app. We continue to improve our stack of CI, applying the use of caches, automating the creation of µFeatures and creating different types of static analyzes to detect problems before reaching branch main.
Today, we have a team of around 45 iOS developers, over 200 µFeatures, 1 million lines of code Swift and 25 thousand unit tests. If we can learn one lesson from this process, it is to share and document everything that is done. This way, not only do you have the story of what was and should be done, but a new person can join the team and get ready to work on the project quite quickly.
I hope you enjoyed this article and that it helped you get an idea of how things are done here at iFood — and that it encourages you to make big changes in your own project.
Cheers!
Original text available at Medium | iFood Engineering – Keep your kitchen organized – by Yasmin Benatti, iOS Developer in collaboration with André Alves, Mobile Platform.
