How We Changed the Course of ECommerce at a Fortune 40 Company

4 min read • Jul 6, 2017

lowes.com Product Detail Page Screenshot circa 2017

If I had to pick the defining moment in my career with Lowes.com it would have to be a proof of concept (POC) I did that ended up drastically impacting the future of Lowes Digital. Up until that point the front-end team didn’t have ownership of the html markup and had to collaborate with a back-end developer to make changes to the Java Server Pages (JSP) on IBM Websphere Commerce.

After purchasing a new content management platform called Adobe CQ, the team set out to build key pages; specifically the homepage, user account pages, product category, product listing, and product detail pages. While some of these pages like homepage, category fit perfectly with the content creation driven focus of the platform, other pages which are data driven did not. We had concerns about the ability of Adobe CQ to scale these pages to our full traffic volume, especially when considering cost.

With plans for a complete redesign of our website, I saw the opportunity to suggest an alternative solution. I spent a couple of hours of downtime to stand up a small Node.js application using the Hapi framework written by the talented team at WalmartLabs. I focused on the product detail page, consuming some preexisting production API services to query the data. Using some early wire frames from the new design, I built out the main features of the page and mocked the rest to look more complete.

I then took the POC to our leadership, explaining the benefits of Node and how our UI developer team could finally take ownership of the entire UI development process. As a precursor to development, myself and a Web Architect traveled to the 2015 Node Summit in San Francisco. At the summit we got the chance to network with other people in the industry that had already gone down this path, as well sit through lectures and workshops.

We set out to re-build the Product Listing, Product Search and Product Detail pages in Node. These would consume our internal API Services that were built on Websphere Commerce and Oracle’s Endeca Search Engine. This project also included a complete face lift of the UI, re-platformed Homepage and Category pages on Adobe CQ.

After over a year of development we went live on June 8th 2016, a day that I’ll never forget. After getting in the office and being made aware of a critical defect, I collaborated with a Web Architect to troubleshoot the issue. We discovered that the issue was only apparent under load, which made me think it had to be a variable scope creep. Looking at the page handlers I theorized that one of our lines of code that extended upon the root application settings object wasn’t actually making a copy of the object. Instead, it was inadvertently adding handler specific data to the root application and thus bleeding into other requests. I wrote a fix for the issue, which was to clone the original object before adding data to it and passing to the view. We got approval to push the change straight to production, after running a build with successful unit tests in our CI server. This would not have been possible with our other technologies, specifically Websphere Commerce and Endeca, which would have taken over 30 minutes to build, deploy, and restart. All this happened in under 8 minutes from debugging to production.

Node had proven itself as being fast to make critical changes, as well as over the course of time and holiday season, stayed true to the performance and stability that we had believed it could. To this day I’m very proud of all the work that our team did in not only standing up this new technology, but being the catalyst for change within the organization. We gained more ownership in the UI development process, as well as saved the company money thanks to Node and Hapi being open source.

article originally posted on Medium