Click & Collect App Replatform

Officeworks 2018-2020

Click & Collect is an internal-facing Officeworks app, installed on PDT devices in-store, which enables team members to pick orders, manage collections, and co-ordinate deliveries with 3rd party vendors e.g. Toll, DoorDash, or UberEats.

The Problem

When I inherited Click & Collect from its previous developers, it was a HTML/CSS/JS based Cordova app, with some custom plugins to interface with the camera on the iOS devices we were using at the time. Click & Collect orders were starting to gain popularity at the time, and it was decided that the Cordova app would not be suitable for future operations.

Architecture

Due to the intention of the business to replace its iOS based PDT devices with Android ones, it seemed prudent to develop the new version of the app in React Native, in order to have an app that worked on both platforms. I also decided to use TypeScript instead of JavaScript as the previous version had used, in order to avoid the many unintended bugs that JS tends to accumulate.

Challenges

Some stores were set up with a local delivery offer (LDO), i.e. a Toll van would collect orders from the store and deliver them to the local area, instead of having orders fulfilled and delivered by their fulfilment centres. The picking and packing process for the LDO was very similar to the Click & Collect process, so it was bundled up into the same app. The initial build of the new version excluded the LDO process, as the business had wanted only stores without the LDO in the pilot.

I kept the design of the new version largely the same as it was in the original, in order to prevent disturbing team member familiarity and muscle memory. However, the new app got a completely new back-end -- the original app would talk to an AWS Elastic Beanstalk Node server which would simply pass the request through to SAP and return the response to the user. This could be very slow, or even time out, depending on server load, which became very evident at peak periods such as "Back to School" or EOFY.

Solution

To solve this load problem, I spun up an AWS ECS cluster and added several scalable tasks, backed by a Redis database:

• The main task handled incoming PDT requests, sending POST requests off to SAP for processing, and either serving cached data for GET requests, or manually fetching that data before caching and returning to the PDT
• The sockets task handled secure WebSocket connections from PDT devices, maintaining a list of orders that had been locked from a team member using it, or unlocked by returning to the menu list of orders
• The proactive fetching task actively monitored the order cache and if new orders were found, fetched and added them to the cache and sent a notification to that store's currently logged in TMs to promote prompt order picking times

Results

The response to the app pilot was very positive, many stores reached out to request being added to the pilot due to the increase in app speed and functionality, which was very encouraging. We included some LDO stores in the pilot, which was slightly uncomfortable as they had to use both versions of the app side-by-side temporarily. The business was very satisfied with the results of the new version and I was given the green light to go ahead with adding LDO functionality and removing the old version from PDTs completely.

Retrospective

Looking back, from a cost perspective, we would probably have saved some opex by using Lambdas instead of ECS tasks, and a DynamoDB instead of Redis. I'm still proud of the infrastructure implemented to handle the high demands of peak trading, and the app has continued to run strong for many years.