How MongoDB Gives Us Superpowers

TL;DR – We’ve been using MongoDB for all kinds of crazy awesomeness, to include indexing, drive charts, search, stats, and analytics. Here’s how.

In case you haven’t already checked out our site, here’s what we do. Feel free to skip this part if you’re already familiar with Krossover and our services.

Let’s say you coach a sports team. You record video of your team – maybe an actual game, maybe practice – and upload it to our site. We then take that video and index it, generating, analyzing and storing data about every event that occurs in the game. A short time later, you can log into your account and play back the game, see all of the plays in the game and the events that made up each play, search plays for specific events (like a tackle or run), see plays visualized on a drive chart (in the case of football – other sports use other charts), and see a complete statistical breakdown of the entire game. I know. Awesome.



You can get to our football demo product from here and play around with it to see what I mean. Demos are available for other sports by clicking the sport you want to see under the “What We Offer” dropdown.

A humongous part of our product, from initially indexing the game to when the coaches get to interact with the end result, is driven by MongoDB. No matter what part of our application you use, you’re interacting with Mongo.

When a game film is being indexed with our Video Indexing Tool (VIT) – a separate application we built for us to use in-house – there are a limited number of tags available to the indexer. Our app knows, based on the last tag or tags the indexer chose, what the possible next events are and makes only those tags available. All of this – the tags, the next events, play summaries, lookups for event titles, etc. – is pulled from Mongo collections and into our app’s interface for the indexers to use when breaking down game film.

For our drive charts, we are storing the svg data used to render the field in a single document in a single collection called “field”. We then pull this data out and render the field with JavaScript.

Our search uses three Mongo collections: one for event types, one for events, and one for search filters. We pull as much data as possible client-side so that when a coach wants to search for plays matching certain criteria, we only have to make a trip to the server for a very limited amount of data. This makes the search experience snappy and keeps us developers happy by making it easier to maintain.

The boxscore and topline stats are generated by our server-side code in the background and stored in two Mongo collections behind the scenes. Once they’re stored, they’re available to the application and to any analysis we may want to do.

All of our sports have completely different, highly complex data sets that are constantly changing and evolving, and this data has to be represented in the interface in an intuitive way, making it a perfect match for MongoDB.


Leave a Reply