Newzoo Platform

Newzoo

The top one-stop shop for all insights in the gaming and esports industries.

Purpose

Newzoo had been known for their comprehensive data reports gathered from a myriad of reliable sources and collected in their vast data warehouse. However, they would only be able to publish data reports on request or on a scheduled basis. Clients wanted something more real-time for them to access. As such, the "google of gaming and esports data" was born.

Responsibilities

I joined the company shortly after development had begun. By this time a modular administrative section, the general infrastructure, an extension off of a D3 library and a few pages had been completed. The project had been started in ReactJS using JavaScript.

My first tasks consisted of creating components that expected a certain formatted input. Generally these were reusable, but most often they'd be placed on certain component pages. Most components, due to their visual nature, were attached to API calls, which in turn were fetched, the progress and result of which were stored in Redux. I'll get back to why this was a mistake later.

As we expanded the components and built on the pages that needed to take shape, more complex features were needing to be built. This included a collapsible navigation menu, which when expanded also expanded sub-pages of certain sections. Every customer also has access to different levels of data depending on their subscription tier, so filters, queries, and pages needed to be locked and inaccessible to users in lower tiers. Lastly, all graphs needed to be dynamic, so when a user adjusts filters the graphs animate and adjust their data.

The user needed to also be able to create custom queries that they could monitor, if our existing queries weren't enough for what they were looking into. Being able to do research on taxonomies was essential for game developers to monitor and identify competitive opportunities. This essentially became a game of plotting existing parameters into a query, and based off of what they're looking for render different UIs.

Once the product was fully launched around August of 2020, some much needed maintenance was shortly to follow. To keep evolving our tech stack, I began an initiative called Frontend Sprints, essentially creating a backlog for Friday devday initiatives to enhance and improve the tech stack and identify areas to improve the infrastructure. Immediately two points came to our attention as needing to address ASAP.

Type-safety was a constant crux of our bugs that would be spotted throughout a sprint. Considering we were a data application, understanding how data flowed throughout the codebase was of upmost importance. So I led the migration efforts to implement TypeScript. We started off by adjusting small components, and working our way up the chain into our queries, states, utility functions, etc. as we discovered new areas where the data flowed, fixing bugs along the way. This also allowed us to get much more control over the experience.

Lastly, the biggest frustration that we were experiencing is performance issues around our graph filters. While diagnosing the issue, we realized that we were using Redux poorly, and basically creating a secondary caching environment that was poorly optimized. Instead of refactoring our Redux, we found a stronger and more future proof solution in React Query, which would allow our calls to be cached more performantly, as well as getting more comprehensive call status information. As we migrated this structure into the codebase, we noticed immense improvements in performance, most notably as the user browses the platform more and more the rate at which our frontend would update would go from seconds to milliseconds.

While there were plans to also implement Jest in testing, unfortunately due to the financial burden put on the business by COVID, my time with the company was cut short.