Category: Architecture

Categories
3D Architecture Distributed Teams eCommerce Frontend Innovation Management Performance Engineering VR

New VR UX For Nurseries

(3/19-10/20)

Challenge

Ship new, web-based, VR-powered, eCom experience as requirements changed.

Action

Act 1 : 3/19-5/19

While on my trip to India in April 2019, I formed a Tiger team of one of my best Lead Engineers, a project manager, and two junior engineers, coaching them to see the similarity between what was the business was asking for and current existing components of the system (PLP, PDP, NUX, and Checkout,) setting a plan in motion towards delivering an MVP for the 6/26/19 deadline.

They went heads-down and we successfully shipped v1 (following) on 5/29/20.

ecom landing page

Business priorities shifted and the project was moth-balled, leading to Act 2.

Act 2 : 8/19-10/19

Having shifted focus to more product-based eCom (see Act 1,) the business decided to leverage existing shop-the-room modeling infrastructure in a more user-friendly, web-based purchase flow.

While the original plan was to have them spin up a completely new POC with a new checkout flow, I intervened and met with the remote Technical Project Manager and Architect, providing guidance around the existing monolith marketplace system, knowing it could serve as enough of a “buy” to meet requirements so as not to have to “build” a custom solution.

Shipped v1 in Oct 2019:

Landing Page

Room Detail Page

I saved $40K in redo work after guiding the non-primary, remote, web team around component re-use while then shipping web-based, VR-powered shop-the-room.

Act 3 : 3/20-10/20

Under tight deadline, coached the Pakistani team to iterate and improve perceived and actual load times using CSS Sprites, caching via HTTP headers, use of a spinner, and gzipping in order to get a usable UI to market sooner:

Landing Page

Drilling down, a user looking to design a nursery can swap out items (made possible by a compositing technique with Three.js and photo spheres)

Room Page

Lastly, recognizing future strategic value-add within corporate partnerships, guided the team to decouple the frontend as a Single Page App for iframe embedding after having decreased page load times, introduced progressive enhancement / graceful degradation, and led the SPA strategy.

Results

New VR-powered site finally launched in Feb 2021.

Categories
Architecture Chat Collaboration Integration Site Reliability SOA Troubleshooting

Connecting Supply with Demand

(10/18-5/20)

Challenge

Ongoing reliability issues with 3rd party chat solution crucial for business operation w/o documentation and integration monitoring.

Action

The key aspect of the Decorist experience is the connection between the Client (Demand-side) and Designer (Supply-side.) To facilitate that connection, many years prior, the business had included a (at that time) nascent Chat-as-a-Solution provider as part of the user experience; it made sense to “Buy” instead of “Build.”

Architecture Overview

The chat UX is loaded into an iFrame. When users chat, their payload is posted to the 3rd party’s backend. The 3rd party then fires a webhook to Decorist which tracks the event in the DB and fires a transactional email depending on business logic.

The Problem

The ways the bugs manifested boiled down to:

  • chat UX not appearing (like below, often as the result of a 3rd party deploy gone bad)
  • emails not sending because webhooks not called

Lacking integration monitoring, issues often bubbled up through first-tier support.

Chat not loading

Improving the Dependency

Noticing the reliability issues, I first delegated to one experienced engineer to triage and then another.

I also dug in on my own and discovered/remedied bugs in our own webhooks while also providing data-backed reliability outage information to 3rd party, escalating to 3rd party’s CTO when necessary

Almost quarterly, as a company, the decision to continue using the 3rd party is re-visited given the reliability issues. Each time, though all stakeholders are aware of the pain collectively experienced, the decision has been made to punt replacing the solution.

Results

  • Ensured remediation of 3rd party issues in 24-36h, even on lowest support tier.
Categories
Architecture eCommerce Management Process Re-platforming Roadmapping SOA

Changing Engine Mid-flight : Again

(Decorist : 8/18-12/19)

Challenge

Take a half-baked v1.5 SOA and continue re-platforming to support scaled integration with corporate parent and its subsidiaries.

Action

Aug 2018

When I joined, it was with the idea that I would be instrumental in helping scale the Decorist relationship-creation paradigm leading to higher AOV to its corporate parent – Bed Bath and Beyond – and its subsidiaries: Buy Buy Baby and Cost Plus World Market.

I inherited the beginnings of a movement away from a Django/Angular/MySQL monolith and towards a Django/React/Postgres multi-tenant platform; a v1.5 of the application architecture. My predecessor had extracted some facets of the monolith to build out the initial stages of the SOA in partnership with another Bed Bath and Beyond subsidiary: One Kings Lane.

Although labeled a multi-tenant platform, it had been built quickly – effectively as a prototype – to service one tenant and was not truly extensible for other silos, though it did encompass solid SOA principles for reuse.

Dec 2018

As part of roadmapping for 2019, wanting to strategically position ‘scalability’ for the corporate org, I worked with my boss – SVP Prod/Tech – to detail a project plan to leverage the exisitng nascent SaaS paradigm for the next generation of the Decorist user experience.

We were sanctioned by the CEO for reduced scope on the roadmap; it would be the very first effort internally for moving towards a new platform to future-power the site. We focused on porting a back-office, manual task of determinging supply-side match and availability with demand-side need.

Wanting to keep a engineer engaged, I shepherded him and helped him understand the Cost-Benefit trade-offs we would need to make in order to meet the deadline, setting a course of re-using the User service for authentication, builidng out a new React-based UI, and integrating with the monolith.

Feb 2019

A few months later, we delivered the feature of supply-side Matching and Availability:

Shortly after launch, business priorities shifted towards a focus on a new eCom offering and we had to back-burner re-platforming efforts.

Dec 2019

Given guidance that 2020 might be the year we could re-visit re-platforming, I ideated around what was still lacking in v1.5 and what would need to be built out, creating a project plan and technical roadmap for the go-forward.

I worked with my boss again around planning and prioritization and we again provided guidance to CEO. Ultimately, we could not secure the necessary corporate integration buy-in for further progress and have had to defer any further progress given other priorities.

Results

  • Mentored Lead Engineer towards implementation of first feature for new SOA paradigm.
Categories
Architecture CMS eCommerce SEO

Better SEO

(Decorist : 9/19-9/19)

Challenge

Deliver SEO value faster.

Action

Prior, the dominant in-house paradigm did not realize the potential of Django to serve in a CMS capacity.

I introduced the idea to to leverage Django as a CMS to power Landing Pages, like this one:

Results

  • Empowered Marketing to manage content and reduced time-to-delivery for Landing Pages by 30%.
Categories
Architecture AWS EC2 VR

Cutting Cloud Costs

(Decorist : 3/19-3/19)

Challenge

Given trends in 2018, AWS budget was projected to increase 92%.

Action

  • Worked with full-stack engineer on web team to tweak EC2 configs.
  • Iteratively introducing Reserved Instances to add to cost savings.
  • Worked with VR team to optimize the rendering pipeline.

As part of the VR work, we found that EC2 instances were running unneccessarily 24/7 so we adapted processes to more efficiently utilize those resources.

Results

  • Reduced AWS MoM spend by 40%.

 

Categories
Architecture Backend Chat Cloud demand-side eCommerce Frontend Innovation Prototyping Strategy supply-side

Launched MVP

I was brought on initially part-time into a two-sided marketplace in the holistic services space to assist the team to go from an environment where code wasn’t being shipped to a place that could launch an MVP.

Prior to joining, I commissioned my own Market Landscape (via UpWork) around holistic services potential; one finding: 2015 global revenue = ~$40B

Better Engineering

When I arrived, the POC had been built by an offshore team in WordPress via cPanel and PHPAdmin and transferred from AWS to Digital Ocean. There was no source control. The first thing I did was `git init`.

I spent time attempting to decompose the production instance into a Docker container (of WordPress and MySQL.) I learned how tricky it is when an application is not already 12-factored to spin-up an alternative instance having functional parity. In case you didn’t know, much of the application state of a WordPress site is maintained as JSON config blobs IN THE DATABASE.

Seeing opportunity to prioritize feature creation (in support of product-market fit) in lieu of operational excellence, I put the Docker initiative on hold and spun up dev and staging instances using cPanel and PHPMyAdmin, simply copying the prod DB.

dev instance after trying to decouple

CaaS : Chatroom as a Service

First Iteration

My initial task was to integrate a chat UX with a broadcast streaming experience being built out and powered by Wowza. I settled on Converse.js and ejabberd given decent documentation, an acceptable UX, and (what seemed to be) easy integration; delivering the following POC

chat, working

Next Iteration

With the web server running under CentOS on one Droplet, I had thought it smart to run ejabberd on a separate instance, installing v14 on an Ubuntu Droplet. I ran into issues opening port 5281 from the CentOS VPS to Ubuntu so I doubled-back on my strategy, opting to co-host the daemons on one Droplet (CentOS.) I then ran into package manager issues and wound up having to build and install ejabberd 18 from scratch while upgrading OTP to v20.

While this was happening, the junior engineer was working to get the Wowza live-broadcast video solution working and time wasn’t on our side to get the MVP launched.

(Additionally, at one point, I looked at using the YouTube/Hangout API didn’t find support for our use case.)

Attempt to leverage YouTube/Hangouts

Once I got ejabberd 18 built, installed, and running, we started experiencing timeout issues; manifesting in FE with a spinner that spun for 1.5 mins before the user was finally able to get into the chatroom. I dove into the ejabberd code, and realized that there was something blocking going on server-side. I never did figure out what was happening, but about that same time I realized that the junior engineer had integrated Twilio Video for the 1:1 experience and Wowza Streaming for the 1:many broadcast experience.

Seeing opportunity to reduce waste and consolidate coding paradigms, I researched Twilio Video and realized that we could, for the MVP, likely replace the Wowza experience for both of the 1:1 and 1:many experiences WHILE ALSO leveraging Twilio Chat to replace Converse.js/ejabberd.

Twilio Video, 1:many POC

Next Iteration

I found and customized React Programmable Chat

Twilio Chat, POC

The next step was to integrate with Wowza.

Wowza UX, now w/Twilio Chat

As their were some production issues with the Wowza implementation, I forged ahead creating an alternative Twilio Video React component using React Scripts.

1:1 UX, Twilio Video Chat (desktop and mobile)

At soft (internal) launch, I posited the Twilio solution and the other team members were delighted.

Though the Twilio Video quickstart project was useful, I ran into challenges around the video codecs (VP8 and H.264) between Chrome and Safari, namely getting desktop and mobile video interaction to work as expected. Digging around produced Github links helping lead to resolution (e.g. simply switching to H.264 to ensure cross-browser support.)

On 4/6/18, we had our first successful supply-side (1:many) broadcast, powered by Twilio Video and Chat.

MVP

After helping the team achieve MVP launch and when funding could not be raised in a timely fashion, I moved on.

Results

  • Swooped in when feature-delivery was woefully behind, built out (desktop/mobile) UX, and launched MVP to paying customers.
Categories
Architecture Prototyping supply-side

Not Ready for React

(The RealReal : 1/17-2/17)

When I joined, it was with the understanding that as the company was growing, we would need to be splitting out the codebase into a more service-oriented architecture.

In late Q1/17, seeing an opportuntiy to leverage React components to both DRY up and reuse functionality and in a bid to further decoupling frontend and backend, I tasked the remote Russian team with the introduction of React around signup functionality.

When the project was almost complete, an engineering executive required that we pull out React and implement the functionality in a more vanilla way, citing that “any changes that engineering [made] causing the business to potentially miss its numbers would be bad.”

Results

  • Explored (but had to abandon) use of React at TRR.
Categories
APIs Architecture Backend Collaboration Frontend Innovation SOA SPAs

Next Gen FE

(Bluxome Labs : 7/16-7/16)

Leading the Charge

Upon returning from vacation, I disovered that the VP ENGR gave the recently-joined Team Lead carte blanche around moving ahead with the next phase of re-engnineering the codebase for a further SOA-influenced frontend and backend split.

Being intimately familiar with the current system architecture, in a race against time for Week One (only had a week before VP ENGR wanted Best Practices/new workflows/adoption of new technolgies and because one substanitally differing proposal – likely much more costly from development and operational standpoints – was on the table,) I set out to formulate a concrete strategy towards delivering in the short-term while providing a basis to iterate against a longer-term architectural shift.

Architecting the Solution

First, I advocated for the adoption of the ‘Launch Page’ as the testbed with which to move forward. Then, I reviewed that page in order to reverse-engineer whatever model attributes I might be able to use (in a Backbone model) as exposed by in a simplistic GET request on page load for initial state.

I then modeled that simplistic endpoint using the Swagger Editor

Next, I dumped the YAML of that endpoint and leveraged Swagger code gen tools to create an initial version of the endpoint in Node.js (and Ruby and Java) and fired up that Node.js for serving HTTP requests.

At that point, having proved to myself the utility of Swagger for spinning-up some simple Node.js services, I turned to building out a placeholder SPA using React that would consume a Node.js service. I opted to stay within the Rails paradigm (instead of adopting an approach of statically hosting assets elswhere) and first used react_on_rails to incorporate React and then the react-rails-hot-loader for HMR.

I wound up needing to patch the latter locally in order to get Web Sockets working correctly in my environment.

Having put the Big Rocks in place, I could hand off the SPA POC to the F2E consultant for further refinement and could focus on building more of a case for the overall approach which the VP ENGR then gave his blessing to.

Building the API

During this phase (Weeks Two and Three,) I implemented GET, POST, and PUT JSON-serving routes in Rails (not to have to worry about CORS) while also developing in the context of Amazon’s Lambda and API Gateway, taking the Node.js server stub above and dropping it in as an HTTP Proxy to collate information from existing API endpoints (as microservices.)

I also worked with five backend specialists and my work guided the conversation around establishing Best Practices for API development.

Results

  • Championed bottoms-up approach to decouple microservices, influenced VPE/Team Lead/F2E to adopt, and prototyped using React / Hot Module Reloading
Categories
Architecture Building buy-in Collaboration demand-side eCommerce Frontend Leadership Performance Engineering Process

UI Tech Debt

(Bluxome Labs : 3/16-6/16)

A remnant of the legacy codebase from the company’s origins eight years ago, the two most important routes on the platform for quality assurance had never been moved from the company’s original Merb app to its companion (upgraded) Rails experience (back when a first movement towards SOA happened three years prior.)

They were rightly regarded with trepidation given their dependence on MooTools when the rest of the platform had been moved to jQuery, especially as the Jasmine suite for their coverage had been mothballed about 18 months before and those same MooTools libs were tightly-coupled between two platform applications.

Towards a future of less frontend tech debt, I seized on the opportunity to champion and shepherd the project (as a Q2 engineering goal) through to completion.

Over the course of three months, I led the effort around project scoping, weekly communication around engineering effort, and architecting and leading the implementation, interfacing with Product and Design to ensure quality in light of the absent test coverage.

Results

  • Delivered on decoupling strategy for static asset management / Webpack’d bundles while collabratively iterating with VPE/VP PROD and Sr. Engineers
Categories
Architecture Backend demand-side eCommerce Frontend Full-Stack Innovation SPAs

Demand-side UX Refresh

(Bluxome Labs : 4/16-4/16)

In a unique position given my previous experience with the UX, I took an opportunity when tasked by Product and Design to not only reskin the Listing but also to upgrade it.

Given that no one besides me really knew how RequireJS was working in the application and given its falling-out-of-favor in the general community as a module-loading solution, it was time to upgrade it to Webpack.

Here’s what the Task Listing looked like before

Here’s the mock from Design

In chronological order, here’s what I did

  1. Upgraded DataTables from 1.9 to 1.10
  2. Refactored JavaScript towards more of an OO paradigm
  3. Applied new skin
  4. Ported JavaScript for RequireJS to CoffeeScript for Webpack
  5. Deployed

…and here’s what I delievered

with modal

Results

  • Successfully advocated for adoption of Webpack to replace RequireJS and then ported most-trafficked page, while achieveing near-pixel-perfect re-skinning.