Our buying flows architecture: sharing code between react and react native

At Getsafe we offer our innovative insurance products on two main platforms. The one you probably know is the Getsafe mobile app itself; with it a user can manage his portfolio and it’s our default platform for offering new products. But aside from the app, a lot of our users buy their first product on our web app at https://www.hellogetsafe.com. Both platforms implement the necessary steps to configure and purchase insurance products. This is what we refer to as buying flows (from now abbreviated as BFs).

Today’s post will give an overview of our mobile and web apps BFs architecture: what they have in common, how they differ and what we are doing to improve the infrastructure for both of them.

What our BFs have in common

We will start by looking at the BFs on our web app. They consist of a client-side react app which the user can use without the need of having a Getsafe account. All BFs follow these steps:

1. Gather information relevant to the product’s pricing, such as birthday, postal code and property size (for contents insurance).
2. Show possible product upgrades or extensions (e.g. tenant liability for the contents product).
3. Show prices to the user in the summary screen, including upgrades. When possible, give the option of adding or removing said upgrades.
4. Gather user’s personal information, including the email address. The latter one is very important, as it uniquely identifies a Getsafe account. If the user already has an account with that address, a web purchase won’t be possible (we will allow for it in the near future, keep tuned!).
5. Gather payment information.

Our mobile app is made with react native and a BF therein is very similar. It also follows steps 1 to 5 with some differences, namely that some information can already be present in the app (i.e. email, personal and payment information), so there is no need of asking for it twice. The following figure gives an example of a web and an app screen for the car product.

It would seem that the screens are exactly the same, right? We can say that they are conceptually the same, but that does not mean that their implementation is the same or even similar. In the next section we will take a look at how these steps were implemented in the beginning (until very recently).

Initial BF implementations for web and app

Let’s go one step further and take a look at the source code of the steps shown in the last figure for each platform:

Web:

Mobile:

Aside from some similarities (like the use of a RadioCardSet component), the snippets look totally different. One features JSX, the other one is a plain JavaScript object. Even if we also use JSX in the react web app, we would still need different components, because react and react native components are not compatible. It follows that developing a BF for each of the platforms involved writing very similar logic in two different ways, resulting in duplicated efforts, both for the initial version and subsequent modifications. That sounds pretty bad, doesn’t it? And it really was.

For that reason, we have thought of a way of refactoring our BFs architecture, in order to significantly reduce the duplication when developing a new product or when modifying an existing one. The new approach is explained in the next section.

What we are doing now: shared BFs

Under our current architecture it is possible for us to share common elements just as UI components, texts and step logic, writing most of the flow configuration only once for both platforms. Similarly, changing a step needs to be done only once. The new architecture is summarized in the next figure.

We have two shared packages: the UiKit and the flows packages. The first one contains react and react native implementations of elements of our design system, which share the same styling thanks to the styled-components library. The flows package condenses the essence of each buying flow in plain JavaScript objects, so that they can be consumed from both platforms. The code looks exactly like the snippet presented earlier for the web, where the configuration is stored in a JSON-like format. In fact, the car BF is in the process of being migrated to the new architecture! Having the BF logic as a JavaScript object instead of as react or react native JSX has several advantages:

• It’s platform independent.
• It can be statically proved.
• It can eventually be serializable, so that an IDE with a graphical interface can write it.

Each platform has its own flow renderer, which consumes the shared configuration coming from the flows package and renders it natively with the help of the UiKit. At the moment the flow renderers themselves look quite different, although they implement the same tasks. The reason for this is that they have been developed independently, but we plan to abstract and extract common functionalities in a future refactoring, such as the way that step transitions are handled (which can be platform independent).

Currently we are in the process of migrating all existing products to the new architecture. This will allow us to maintain them and do small modifications much faster. Additionally, introducing new products (like the new dental product) is now much easier, freeing up time to work on new features and bug fixing.

What’s next

In the future we want to streamline our BF development even further by moving parts or all of the BF development process to a graphical user interface sitting on top of our CMS. This will allow product managers and colleagues of the insurance team to modify texts and step logic without changing the source code, for both platforms at once.

In Getsafe we not only focus on delivering the best insurance products and customer support, but we also care a lot about improving our internal processes and technologies. Having a robust buying flow architecture which is easy to implement and extend is paramount to this goal, and we are working hard to improve it. Another important aspect of our infrastructure is having extensive testing coverage and error monitoring, so that bugs are prevented before a release and existing ones are caught and corrected early. We will talk more about testing soon!

If you like to work with the latest React features and want to spend your time writing software which has an impact and makes the lives of our customers better, come work with us at Getsafe. We are building the future of insurance together.