Selected work

Verizon Media / RYOT · 2020 to 2022

A 3D creation tool used by the NFL, HuffPost and Yahoo

RYOT at Verizon Media needed a web tool for 3D content that works on phones as well as desktops. I led the team of 9 engineers that built it and designed the backend from scratch. Synchronous API calls stayed under 300ms, and deploys went from days to minutes.

engineers led, across time zones
9
synchronous API responses
<300ms
to onboard an engineer, down from weeks
Days
Role
Lead software engineer
Team
5 backend, 3 frontend, 1 platform
When
2020 to 2022

The problem

Creators at the NFL, HuffPost and Yahoo made 3D content in the browser. A model that rendered fine in desktop Chrome could choke iOS Safari or an Android WebView, and raw creator files came with huge polygon counts and 4K textures.

Every file needed a lighter version for each platform, with no human in the loop.

My role

I was the lead engineer on a team of 9 spread across time zones. I designed the backend from scratch as microservices, and wrote GraphQL services in TypeScript and Go.

Constraints

  • Blender was never built to run as a production service.
  • One team spread across time zones.

Decisions

  1. Let Blender do the cleanup, headless

    Context
    Raw creator files were far too heavy for a phone, and the tool had to fix every one of them automatically.
    Decision
    I built a server-side pipeline that runs Blender headless. It decimates meshes, compresses textures, bakes materials and outputs a version for each platform. Blender isn't built for production, so the pipeline also handles hung jobs, memory blowups and queueing.
    Consequence
    Huge creator files render on iOS Safari and Android WebViews, with no human in the loop.

  2. Put each workload where it fits

    Context
    API calls are short and stateless. Running Blender on a big file can take minutes, hang or run out of memory, and sometimes needs a retry. Synchronous calls between layers had been causing cascading failures.
    Decision
    Stateless APIs run on AWS Lambda and the heavy processing runs on Kubernetes (EKS). Layers talk through event-driven queues instead of calling each other and waiting, and each service uses the store that fits it: PostgreSQL, DynamoDB, Neo4J or Redis.
    Consequence
    A slow job can't drag the API down with it.

  3. Make the team quick to start and safe to ship

    Context
    The team was spread across time zones, and getting a new engineer set up took weeks.
    Decision
    I built a Docker development environment and published documentation for every service. Test coverage stayed above 70%, with Jest, Vitest, K6 and Cypress.
    Consequence
    New engineers got set up in days instead of weeks.

The result

Creators at the NFL, HuffPost and Yahoo used the tool, and their files rendered on phones with nobody fixing them by hand. Synchronous responses stayed under 300ms throughout.

Stack

  • TypeScript
  • Go
  • GraphQL
  • AWS Lambda
  • Kubernetes (EKS)
  • Blender
  • PostgreSQL
  • DynamoDB
  • Neo4J
  • Redis
  • Docker