eureka!

Here we are in the home stretch! I can’t believe we’re already in week 8, this quarter has absolutely flown by! At this point, my major contribution to our project is complete, and I’ve ended up pretty proud of what I’ve accomplished. In my last blog post, I talked a bit about beginning to integrate the GridFS specification of MongoDB into our codebase, but I had yet to progress much past the research phase. Actually integrating GridFS ended up being an enormous learning experience for me, with quite a bit of trial and error before truly understanding the best way to utilize the specification. It all came together when I had a breakthrough about the way the code was structured by previous teams that had worked on the project, and how I could change that structure to streamline the process.

I don’t want to go into too much detail about the actual structure of the code – no NDA violations from me! – but I can talk a little bit about the overall structure of what was being stored in the database. Originally, we had a C# object that stored a MongoDB ID and another C# object containing the actual data we wanted to be recorded in the database. When using the standard MongoDB interface, this object would be stored in the database, and MongoDB would populate the ID field in this C# object. It was when I started really digging into the structure of this object that I realized it was obsolete when GridFS became involved. You see, GridFS doesn’t simply store the object you feed to it as is. It created two new objects – a file object and a chunk object – automatically. The file object stores information about the data you are storing, such as its MongoDB ID, its length, chunk size, and any metadata you assign to the data to make it easier to identify. The actual data being stored is converted to binary data, and stored in the chunk object, along with its own unique ID number, and a reference to its corresponding File ID number. Because of this, the actual data being stored is abstracted away, and isn’t usable for filters or searches. It was at this point that I realized that our C# object was unnecessary, as its only purpose was to associate a MongoDB ID with the C# object containing the actual information being stored.

The next part was the tricky part. The team who came before us had heavily utilized this now-obsolete C# object. After talking with our project sponsor, we decided to remove the object from the code entirely, and so it was my job to comb through the code for every reference to this object, and change it to a reference to the object that stored the actual relevant data. It took some doing, but I was able to successfully accomplish this in just a few days. It involved restructuring several classes, all of our CRUD endpoints relating to MongoDB, and many lines of code that created and referenced this object type. It was pretty nerve wracking, making changes to the code on this scale, and I ended the process extremely proud of myself and my abilities.

This entire experience was a great opportunity to prove to myself that I can make changes to an existing codebase. The code we were given was a bit lacking in the documentation department, and our whole team was feeling nervous about our abilities to understand the code as a whole. It was incredibly empowering to realize that I do have the knowledge to take an under-documented codebase and make sense of it all, even if I was unfamiliar with the tech stack at the beginning of the process! This project has certainly boosted my confidence as I move forward into my career.