During my 5+ years at Adobe, the search page was perhaps my favorite project. I took the lead on architecture and engineering and collaborated with teams across the entire company. Some of Adobe’s flagship products with in-app search would send users to us. Sister sites like Behance, HelpX, and others also hooked their search fields into our app. On a busy day we would serve half a million users from all over the world, in all languages. With this kind of traffic, and visibility, the app needed to be rock solid.

Top priorities were not only stability, performance, and accessibility, but the UI would also need to adapt to the user. For example, if the user typed their search in the photoshop app, the search page would show a set of results oriented toward creative users - the entire layout of the page could even change based on context. The goal was to build a single web app to unify the search experience for all Adobe products and users.

Building a transformer app

Since the search app needed to adapt to the user’s context, there were too many cases for engineering to support directly. Therefore, the app would need to be authorable in AEM (squarespace for enterprise). Product, design, or marketing reps could login to author their own version of the app, and their customizations would be saved to a “context object” which became part of the search page url. This made each experience fully portable, and deeplinkable.

Of course, offering this level of customization didn’t come without challenges. I repeatedly found myself in the classic engineering predicament of “Do we manually code this requirement, or take some extra time to build the tooling to support all future requirements like it?”. As usual, there’s a happy medium to be found, but a misstep can lead to an unwieldy codebase and maintenance nightmares. This is particularly true in a large corporation where changing priorities, and conflicting requirements are coming from all directions. In the end, we found that happy medium, but not without constant attention to clear documentation, and communication across all teams and stakeholders.

“I wanna go fast.” -Ricky Bobby

After wading through all the business requirements, it was time for my engineering nerdiness to stretch it’s legs. This app needed to load instantly, and every click, hover, and keystroke needed to have immediate purpose. This was no small task considering the search API team was in active development when I started to integrate.

By the time the search app went live, we were actually sending 5 separate search requests just for page landing (because the API team hadn’t yet supported batched category searches). As they continued to refine the Elasticsearch indexing and query logic, I found ways to compensate. All search requests were concurrent and rendered progressively. They were also cached in session storage (which was particularly helpful when users would bounce between query/filter/sorting/page combinations). There was always meaningful content rendered, and it was nearly impossible for the user to know that requests were often loading in the background.

I was also able to implement a ‘lite’ version of the FE asset package that most Adobe.com domains used (one luxury of being project architect). After some fat was trimmed (or moved to bottom of page), and webpack magic was in place (treeshaking), I had a tidy little bundle with negligible load times. When designers would ask about a loading spinner, I’d happily respond “we don’t need one”. For some time, the search page ranked #1 fastest load times out of all Adobe.com pages, even outperforming pages with static content.

On to a new chapter

I made the decision to leave Adobe this winter. It’s nice to reflect on the wins as I consider the many different projects I worked on over 5 years. Some projects were better than others, and there were some tough lessons learned, as with any job. For me, perhaps the greatest challenge was learning to crawl when I was trained to sprint (a side affect of moving from startup to corporate world). As a creative coder, and somewhat of a perfectionist, It took me a while to adjust to a system of guardrails and speed bumps. However, I’d like to think I’ve emerged as a much more well rounded engineer, and am thankful for those challenges.

When I started the front end team was just a fraction of it’s current size, and it’s web tech has come a long way since then. I was honored to play an integral role in that evolution, and am proud to have mentored some new hires along the way. Big thanks to Adobe, and the folks I worked with. See you out there!