Working @Fandom.com: CATS

Published in

Fandom Engineering

11 min readOct 15, 2021

Howdy! 🎉

From Star Wars to sandwiches, from Elder Scrolls to Swedish band Sabaton. There are at least 250,000 chances you’ll find something interesting on our Fandom Community Platform (FCP), because that’s how many communities we have here. That’s also 250,000 places where you can spot an incredible passion and effort our users put into building the greatest and most accurate databases about a particular topic!

To explain what the FCP is, let me borrow a great piece of writing from the previous blog post of this series (which I will quote at least a couple times more):

Everyone can create their own community — for free. At Fandom we believe in open access to both creating and consuming content! Most popular communities on Fandom are about pop culture (games, movies, TV shows, anime, comic books). Some examples: Star Wars, Harry Potter, The Witcher, Lord of The Rings, The Office, Elder Scrolls, Marvel, Game of Thrones. A community on Fandom has multiple components to it:
- A wiki — central place of the community where users can create a knowledge base in the form of articles, based on the MediaWiki framework, used by e.g. Wikipedia.
- Discussions — a place where users can interact with each other — share news, debate on various topics and take part in polls
- Customization — Fandom has built the customization tools like ThemeDesigner to allow each community to build its own unique identity, but users can also directly use JavaScript and CSS to customize their communities even more

And wait, it gets even better! Our Community Platform is visited by over 300 million unique users, who generate over 2.5 billion page views every month! And what’s best — you do not need thousands of people to manage such huge traffic. It is the stability of the platform and the fact any engineer in Fandom has the ability to touch every single part of our codebase that makes it easy for us to maintain it. To be the most performant, our teams are divided to have a specific set of features in their ownership. We, we also collaborate a lot on a daily basis to share experiences and help each other solve the challenges life/users/business are throwing at us. And in this week’s episode of “Is there anyone @ Fandom?” I’d like to introduce you to one of those teams!

Enter The Kitten

Gamers have F.E.A.R., TV fans enjoy M.A.S.H., and some of you may have heard about the band called R.E.M. They all have two things in common: firstly — they’re great, secondly — their names are acronyms. I guess you know where I’m going.

CATS stands for Creators, Admin Tools & Staff and is a result of us trying to pick a name describing our ownership in a reasonable way while giving us a reason to put lame GIFs into every presentation we do, as you may have already noticed. As it stands — we are responsible for Fandom’s power users — creators, administrators, moderators and everyone involved in making the best possible content on the FCP. We provide many features and experiences for them and here are the most important ones:

Visual & Source editors — on Fandom you can create your content in two ways, using WYSIWYG mode or raw textual mode, by using MediaWiki’s syntax called Wikitext
Wiki creation — what’s a simple process for our users, is a complex mechanism under the hood, taking care of setting up everything
Moderation & patrolling tools — there are multiple tools our moderators have to make sure their community is a safe, curated place — list of recent edits, newly uploaded files or contributions from a specific users to name a few
Admin & staff tools — theme your community, send notifications to your users, manage their rights and many more. Due to the private nature of those pages I can’t give you any real-life examples — you need to create your own community 🙈

And just to be clear — we didn’t build all of those things from scratch as many of those are provided by MediaWiki core by default. We’re responsible for their maintenance and future improvements.

Meet The Team

So how would you know you’d be a good team fit?

Firstly, we don’t have a strict division of responsibilities nor specialization. We value versatility and flexibility. Some of us have a backend-ish background, others are frontend-oriented and there’s always plenty of work on both sides, but you need to have the courage and passion to learn new things as eventually you will be exposed to various pieces of our tech stack. And fear not — you will get all the help you need to understand every aspect of it.

We fully embrace Fandom’s “We not I” value. We’re a team for a reason thus we strongly prefer clear communication and collaboration over individualism. If you are stuck with something, you will get the hint or the answer. If you want an opinion about something — you’ll have others commenting. And if you’re working on something that’s outside of your primary area of expertise, there’s always someone willing to help you understand it by conducting a pair programming session. There’s only one rule here — don’t be afraid to ask for help. This always works both ways — if you can help others with anything, you go for it.

The next big thing is proactivity which can be manifested in multiple ways. Spotted an issue? Fix it if it’s quick enough or create a Jira ticket for the future. Found that old ticket that from your perspective is important enough to handle it immediately? Bring it on the table so we can talk about it (and likely put it near the top of the current priorities). Or maybe you realised there are some missing requirements in the task you’re currently looking at? Feel free to propose the solution on your own, regardless of its complexity! If you want to have an actual impact on the product you’re working on — you’ll find a good spot here.

We have a pragmatic approach to all the things we do. We always make sure everything we do is well-tested, well-designed and well-coded. But working on a platform that big means there’s always a lot of things that are broken or imperfect. And that’s totally fine, because we will never have enough time to fix them all! Instead, you need to be realistic about the amount of perfectionism you put into a task, and you need to understand that good enough is sometimes more valuable than spending a lot of time covering all the edge-cases.

And in the end, as much as we love to solve technical challenges, we are all fans of something. From cooking, cycling, sailing, FPV drones, chess and music festivals to Star Wars, Dune, Friends, The Office, Quake and God of War. And that’s just the tip of the iceberg as everyone in the company has something they are passionate about. This attitude helps a lot when working on our Community Platform as there are millions of people engaged in creating the content there and psyched about that new thing coming up next week, so it’s like we’re building a platform for ourselves.

Our Workflow

We are a cross-ocean team but that does not mean we work late hours. In fact — our meetings are usually condensed around 3 PM CET time which gives you all the rest of the day to focus on what’s important. Ah, and there’s also a no-meetings-on-Friday policy. We created our own mix of Scrum and Kanban, to shape our Jira board in the most useful way. That gives us enough flexibility to set reasonable weekly or bi-weekly goals and adjust the scope and priorities if the situation changes.

We are fully remote, using Slack for messaging and Zoom for meetings. We have flexible working hours so everyone starts their days by simply sending “👋” to let others know they’re available. We do our daily stand-ups in a mixed way — discussing things in person and writing notes on a dedicated Slack channel.

We host our code on Github and conduct a code review of every pull request we create. We write all kinds of tests and on top of that we manually test every change before it will be merged to the main branch. Despite having a Quality Engineer in the team, all members also test those changes mutually on their own, which increases our awareness and independence.

The FCP is deployed regularly every day, many of our smaller apps are deployed automatically in a CI/CD manner. We trust our people and our processes, that’s why every engineer working at Fandom has all the powers to deploy every application we have as well as to break them completely. It’s simple and useful. You don’t need to create a “deploy ticket”, ask the “build team” for it or fulfill a complicated checklist every time you need to release a hotfix to production. All you need to do is a couple of clicks in Jenkins.

The Toys CATS Play With

Remember that blog post I mentioned earlier? Time to steal something once again:

This is the (almost complete) list of technologies we use at Fandom. You won’t be equally exposed to all of them as it spans across multiple teams and ownerships, but you’ll definitely be able to work with the majority of it.

To name the most important ones:

PHP (+ MediaWiki framework) — the big one that powers our platform and it’s impossible to miss
TypeScript — we have a lot of JS code written using latest ES syntax, but a while ago we started the transition to TypeScript which now acts as a default solution for all new features
React — we have many separate React apps that are a vital part of our platform. We don’t have a strict set of helper libraries to use so there’s always a possibility to try something new in the next project
Java (+ our internal microservice framework) — MediaWiki is responsible for a lot but there are certain pieces of our architecture that we decided to extract and host as a separate services
Webdriver.io — the primary tool we write our functional tests with
Docker and Kubernetes — all our apps are containerized and automatically orchestrated
Grafana and Kibana — to know the logs and health status of our apps

On top of that we contribute to cross-team initiatives. We support Fandom’s monorepo for all FE apps and libs we internally created, we also take our part in the major upgrades of the MediaWiki framework that happen every year. And there’s always a chance for everyone to jump into other teams’ work for some time to help them with their projects.

Past & future projects

We discussed tech first, so let’s now talk about the practical ways of using them:

Theme Designer 2.0

Our biggest project this year.

The background

A few years ago Fandom joined forces with Gamepedia, which created the ultimate wiki-based fan community platform on the Internet. After spending some time unifying our tech stack (both platforms were running on different, in-compatible versions of MediaWiki) we were able to start unifying the visual layer of the platform. These efforts were led by the SiteX team and were described in more detail in a previous post of this series.

The stack

Theme Designer (TD) is the tool originally created around 2010 that allows admins to (surprise, surprise!) theme their community, so it’s quite obvious it wasn’t prepared for all the changes. All the above meant the new TD had to include:

Theming support for historically Gamepedia communities
Two themes for each community — light and dark one (previously we only allowed one)
Dynamic preview allowing you to see the changes on any page on your community, instantly (previously we displayed a default, predefined article)
Completely rewritten backend approach due to all of the above which included new storage, new on-a-fly theme config generation and
On-demand DB migration to allow importing of old themes

The application was completely rewritten. We incorporated React to build the client side of it, adding some abstractions on top that allowed us to update the embedded preview easily and re-implementing server-based theme config generation to reduce API calls. We leveraged MediaWiki to handle the server side, which eventually led to a massive theme migration for each community (we wanted users to have as much of their old theme as possible), integrated into the main UCX migration.

The result

At the end it was finally okay to proudly say we’re now in the 2020s rather than stuck around 2005. You can read the deep analysis of the changes here, but for now just look at it:

The old one:

The new one:

Interactive Maps

The background

Our users tend to be very creative when it comes to custom additions to their communities. And we are constantly looking at the effects of their work and listening to their requests. One of these additions are maps. You can find dozens of them in many of our communities, and in many cases, despite being a little piece of the art on their own, it is not easy to work with them effectively.

The stack

That’s why we decided to invest our efforts into adding a tool that introduced a new kind of content type for our creators — highly customizable, interactive maps done in modern fashion. It was a prototype-like project, used by us to validate the idea quickly. We plan to invest more time in the future by expanding its capabilities with WYSIWYG-kind of editor and different types of entries.

When it comes to tech — we used React mixed with Leaflet.js and its plugins for map-related logic, storing all the configuration as JSON object by using MediaWiki capabilities for creating custom content types. This also allowed us to incorporate the source editor (mentioned in one of the sections above) for basic (yet fully validated!) editing.