Moving YellowLabel Forward
After a very successful season beta tests with YellowLabel’s we were ready to bring the experience for our customers and supermarket partners to the next level. Fresh from a fresh round of financing from angel investors we were finally able to afford UI/UX work from a very competent London-based agency, Flipside.
The first step to build a fully production ready app for YellowLabel was to get some proper design work done. In the beta version, I had to improvise myself as the interface designer, whilst the experience was well-refined within our whole team. If you look at the details of the beta version, you can tell it was the work of a developer not a designer, just look at the courier font I used!! Flipside handed me over their design work with a very useful designer-developer bridge app called Zeplin that I really enjoyed using and still am to this day.
Tech Stack Decisions
To Expo or not to Expo?
The biggest decision I had to make about what tech to use, was whether to rely on Expo for its ease in installing complicated libraries and release to the stores, or once again use vanilla React Native. After testing our two main difficult-to-install packages Maps and Notification, I decided to take the leap and go with Expo, all this considering the risk that I may have to ‘eject’ back to vanilla react native which would cause significant delays in development time. Expo turned out to be an incredible development tool that continues to improve to this date! Now they have added a vast number of easily importable packages which I believe cover the needs of the vast majority of mobile apps. Big shoutout to the Expo for making thousands of developers’ life much easier!!
App-Level State Management
Although I did not enjoy the verbose Redux APIs (as mentioned in this post) for something as simple as state management, I ended up being stuck with it despite many other careful considerations. The only real alternative I saw was relying on most of the app-level state data being stored in or custom Node.js backend, but this came with two very obvious problems. The first was that our customer had to have an active internet connection to use the app, but we could have decided to proceed along this path since the user needs to see the list of most recent products discounted in the supermarkets. The second proved to be what made me decide to stick with Redux – prop drilling. Given the tree-structure of React components, it meant that the query to GraphQL had to be made in a high-level (root of the tree) parent component, then each piece of data had to be ‘drilled’ down to children or children’s children all the way to the leaf components of the tree through the prop api native to React. This proved, not only to be extremely cumbersome and repetitive code to write, but also made the entire app very prone to bugs which cause inexplicable errors that were a real chore to trace up the tree structure. Even in small and simple example apps I was losing my mind, so I decided to take my medicine and stick with Redux.
The backend’s purpose was to transform data from a stream RESTful API provided from our partner supermarket into data that was visible at the app-level. In addition we had to authenticate users and store their usage data such as location, items selected, and other metrics that would help us improve our product in the eyes of the customer. The idea was also that we would sell this customer-level data back to the supermarkets to help them improve their buying and waste less food.
The stack I ended up using ran on Node.js and used MongoDB as a database. Storing our user data ended up being some pretty straight forward code, as the info was just being written into the database and very rarely read. What proved to be a little more complicated was transforming the stream of data coming from our partner with a REST API and converting it to non-relational format on our db and expose it in real-time to our front-end. I ended up using a library called nest to help me in this task. It actually turned out to be very straight forward as all I did was write this data-stream to our db, then expose it to the front-end with GraphQL queries.
The Unfortunate News
Unfortunately, due to circumstances out of my control, this full-scale version of the app never hit the market properly despite a very successful comprehensive software test by both the Ten10 Group and our internal team. The main reason is that our deal with our launch partner, supermarket Morrison’s fell through at the last minute due to a change in their upper management. Despite having all the infrastructure ready to be able to get live updates on their discounted goods available, we were unable to ever turn on the real-time feed. There were subsequent attempts by our business development team to strike deals with other supermarket chains, but there seemed to be no light at the end of the tunnel for our team. I ended up resigning to concentrate on my golf business, which were rapidly picking up pace after many stagnant months.