Why did I write another React Native boilerplate

Approximately 2 years back we decided to move from Native Android and iOS applications to something cross-platform. As most, I went looking for a boilerplate, and this story is about why I decided to write my own after all deliberations.

Note: this article is not about why you should / shouldn’t do Native. It is about how I was not disappointed with what I found, but felt that they just left me wanting for more…

To view the repo, click here .

Some Backdrop

Circa 2015 — working for an e-commerce company, we had separate mobile, desktop, checkout, account and tracking code bases (so that’s 5). And yes, native iOS and Android apps (2 more). Imagine the size of development team you would need to maintain all of that. And the fact that we were a startup. And I haven’t even mentioned the API and DevOps teams.

To deploy a new change / feature, we had to make changes in 3 applications at least (if not account / tracking) and test them out separately. And do this 2–3 times a week as the company was still learning and we had to be agile.

A year into this, talking to my manager, we felt that it was not possible to maintain so many applications at the pace needed for a startup. So we decided to write an in-house application that, to start with, would work as a single code base for our desktop, mobile and checkout versions. And may be if things work out, we also integrate account and tracking (reality check — tracking is the only piece that is not a part of it today).

We started off with an official Aurelia boilerplate . A year later, everything was controlled using an in-house CMS — no html editing, no separate testing for functionalities. The business logic was shared and everything was modularised using web components (polymer). The folder structure is below:

Project structure from single code base

basically, 2 main separations:

shared : All shared stuff moved in here — like business logic, images, even fonts and translations. After all add to cart is same, whether its desktop or mobile (or even apps).

src : All website presentation stuff went here. small for mobile, large is desktop. We later also introduced checkout .

This was pretty scalable. Later, when the company was looking to venture into the FMCG business, it was just about adding a new folder under src , grocery-small :relieved:.

Ok, so a year later, it was all done. With a lot of A/B and number comparisons, we were able to convince the analytics guys :smirk: and in phases replaced the mobile, desktop and checkout sites with this new solution. We were all very happy and satisfied with it.