Continuous Improvement of the AutoZone Applications

Introduction

For nearly four years we’ve been working with the AutoZone teams on their AutoZone web and mobile applications. Initially, the primary purpose of our cooperation was to enhance the performance of the AutoZone web app on mobile devices and to migrate old native apps (Android and iOS) into a brand-new React Native app.

As the projects evolved, the scope of work naturally expanded as the client wanted us to take care of more features. That’s why, after reaching the most important milestones, together with the client's teams, we turned to address other needs. Now we are working on securing further improvement and, all in all, making every effort to keep up the metrics at the highest level.

Migrating from native to React Native

Beginning

AutoZone had two native mobile apps - one for Android and one for iOS. Both were rather dated at that time, filled with loads of legacy code that was hard to navigate and even harder to onboard new engineers. Migrating to React Native was a good opportunity to refresh the client’s mobile app, and it was in line with improving its overall design and functionality. 

Since there were several issues in communication between native and React Native elements, we had to prepare the app for integration with React Native.

Objectives

The declared aim was to get from native to React Native gradually so that the app could work well at all times, and the client could continue its maintenance and releases. Another objective was to create one design codebase for both platforms, Android and iOS, and refresh the app.

Work and technologies

First, we audited the architecture - we created a report with all areas of opportunities along with a proposal on how to handle them. We also checked the existing modules to determine which elements can be transformed into React Native to work better.

The app was divided into small modules (vehicle, store, profile, etc.); all the modules were prioritized from the smallest to the highest number of dependencies. We started the migration from the store tab since it was the simplest module.

Then we took care of screen transitions: we had to create a linking layer to send data between old and new screens (between native and React Native). Also, there was no wrapper or support in React Native, so we had to make a custom solution to adjust React Native to AutoZone’s needs.

The entire migration process was gradual - we integrated React Native module by module. In line with that, we created a React Native brownfield library to optimize the migration workflow.

All in all, it was a brownfield project as we worked with the existing native elements throughout to build a cross-platform app with a shared codebase. We had to consistently ensure that the native and React Native components were in sync.

Results and what’s next

We gradually integrated React Native the brownfield way, which means the transition was smooth and controlled. At the same time, the application was up and running during the whole process to ensure business continuity.

It took a year and a half to fully migrate the app to React Native, and the project came to an end. However, the collaboration went very well on both ends, and we agreed to continue developing new features. 

Since we had domain knowledge about the AutoZone system, it was easier for us to understand the client’s business needs and convert them into new features. 

What we’ve done so far:

• All user interface (UI) and functionalities are now refreshed 
• There is a special layer added to parse network responses
• We introduced advanced push notifications (which required creating a new software development kit (SDK) wrapper) 
• We implemented mobile payment methods (Google & Apple pay)

All in all, the mobile app was upgraded and refreshed, which directly translated into a better user experience, and consequently, higher user ratings. The score increased after the migration.

Web app development with Next.js

Beginning

At first, we were asked to help with AutoZone internal apps already written with React Native. For example, there was an app for drivers to help with deliveries and a B2B app designed for ordering auto parts and accessories by smaller businesses. Gaining more business context and proving our expertise in React and React Native, Callstack developers were asked to work on the AutoZone web app.

The app had already been developed for nearly two years by one of the in-house teams who adopted a mobile-first approach to the project. Consequently, the app’s performance on desktops and mobile devices was unsatisfactory at that time. Our role was then to support the client’s team efforts and accelerate the implementation of the web app in production.

Objectives

The client wanted better (faster) web performance, but the main goal was to improve SEO rankings in Google. In order to help with technical SEO, the AutoZone developers created their own custom server-side rendering (SSR). 

However, without any framework that could facilitate its use, the client’s SSR became problematic. Not only did it make the codebase more complex, but also slowed down the development iteration. On a typical machine back then a developer would need to wait for 5-11s for a full page reload as the hot module refresh failed to work in this setup.

Our objective at the time was to migrate the AutoZone custom solution to Next.js - a React framework for server-rendered web apps. It offers all the functionalities needed to support ecommerce sites.

Work and technologies

Full migration of AutoZone server-side rendering took several months, and we always worked alongside the client’s teams. We became part of the SEO team.

After the successful migration to Next.js, we could finally focus on improving the performance metrics that mattered to AutoZone most:

• Time To Interactive (TTI), 
• Largest Contentful Paint (LCP), 
• First Contentful Paint (FCP), 
• Cumulative Layout Shift (CLS) accompanied by the Time To First Byte (TTFB) from the server. 

All these metrics make up Core Web Vitals (CWV), and at the time Google made it clear that websites with low performance measured in CWV were going to drop in Google search results.

We set up Lighthouse to continuously check the metrics and worked towards an initial goal of raising the performance score on mobile and desktop. Thanks to Next.js reducing our hot reloading times twice and, later on, introducing Fast Refresh to further improve the results, we were able to iterate quickly. 

One of the biggest reasons for the low score was a large shared JS bundle weighing more than 500 kB. This was after migration to Next.js, which introduced the route based code-splitting. We used Bundle Analyzer and Source Map Explorer to identify the parts of the codebase that could be further lazily loaded and worked our way through it. 

Results and what’s next

Our intense work and a sound plan resulted in remarkable SEO improvement, so the client achieved their business goal.

We enhanced the app performance by at least 200% and improved renewed Core Web Vitals metrics to more satisfactory levels. We achieved much faster loading times. All in all, we optimized the app for quality and better user and developer experience.

Thanks to Hot Module Reloading that came with Next.js, later replaced by Fast Refresh, we could reduce the refresh time to ~2s. This was a massive improvement:

Currently, we are continuing to build on the foundation of Next.js. We want to make the most out of the framework by adding new functionalities or more advanced features to the app such as middleware, Incremental Static Regeneration, React Server Components, or SWC.

We are also working on a migration from Redux to React Query. Touching the Redux-driven business and network logic uncovered a whole new level of complexity for this project, most of which was really related to fetching data. Hence the decision to rewrite all the Redux network layers into a dedicated solution like React Query. 

We not only focused on performance but also code quality and DX improvement. To achieve this, we're using TypeScript, Eslint, TypeScript-Eslint, Jest + MSW, and PlayWright.

Being halfway through the effort already allowed us to untangle code, reduce dependencies between unrelated features, remove code, and also code splitting. What’s more, it will finally provide the website with the ability to cache pages on a CDN level.

We continue upskilling the AutoZone developers through knowledge-sharing sessions. To keep the desired results and suggest best practices when making changes, we do the necessary code review.

Our approach

Leading-edge technologies

We offer the most advanced solutions within React.js and React Native. And the technologies based on React let you add new functionalities to your app over time so you can always stay up to date, and further tailor the app to your needs.

Agile collaboration

From day one we work on the AutoZone apps from the inside, closely collaborating with the client’s teams. As the projects have expanded a lot, it’s been of utmost importance for us to work with alignment and transparency.

Why is this approach better than any other?

• There’s no need to engage three separate teams (for Android, iOS, and web)
• You can handle the performance and maintenance of a giant app. We know what to do to take care of huge applications in React and React Native.
• Everything is done in one stack

Partnership

Our collaboration is always based on partnership and a very comprehensive approach: we dive into the project, analyze the situation and what should be done, and plan our work accordingly. We are trusted experts and partners, not just developers who provide code.

We operate from within to better meet the client’s needs. This model also involves knowledge sharing - by joining an in-house team our developers become expert colleagues who can help.