Codecademy’s course catalog on SQL databases is thinner than those on topics like web front-end development, and their in-browser learning infrastructure isn’t as polished for those courses either. This has caused me frustration, but I was still learning useful knowledge. Codecademy’s PostgreSQL skill path was packed with information I can use and links to where I could learn more. After that, though, I wasn’t interested in anything else under their SQL umbrella of courses, but that doesn’t mean I’m done with databases because SQL relational databases are no longer the only game in town: A few alternative “NoSQL” database designs have recently arisen, and I had been curious about their design tradeoffs. So, the next step is Codecademy’s Learn MongoDB course, which I learned was launched (or at least promoted) recently via a Codecademy mailing list. Unfortunately its technical immaturity caused problems, more on that later.
This course started well, with a review of databases for those who come into the course without a background in SQL relational databases. With that background established, it proceeded to describe how NoSQL databases (there are several subtypes) like MongoDB (representing the “document database” subtype) go about their business. I loved this section, because it answered my question about why these databases exist and when they might (or might not!) be the right tool for the job.
On the course syllabus it said “Built in partnership with MongoDB” which in practice meant many links to MongoDB’s established portfolio of guides and documentation. After Codecademy’s own explanation of SQL vs. NoSQL, we have a link to MongoDB’s own take. Related to that topic is a presentation that describes MongoDB structures in terms of close analogues in SQL, but also implored experienced database developers to free their mind and think beyond relational database conventions. It seems perfectly possible to set up a MongoDB database so it looks and act like a relational database, but not taking advantage of MongoDB strengths risks incurring all the disadvantages of NoSQL without any reward to balance them out.
The MongoDB advantage that really caught my attention is the ability to start working on a project before we know everything about data access patterns. In a SQL-backed project that is a recipe for disaster because incomplete information would lead to a suboptimal schema, and one that we’d be stuck with towards the end of the project. Over in MongoDB land, our data validation can be loose in early stages of the project and tightened as we go if desired. During the course of development, MongoDB can theoretically adapt to changes much more easily than SQL databases could handle schema updates. I wonder if this means it’s possible for an application to evolve their MongoDB usage and end up in a state where it’d make sense to migrate to a SQL relational database.
These features were all very promising, and I really looked forward to playing with MongoDB. Unfortunately, Codecademy’s hands-on lesson backend is broken today. On the first page of the first interactive lesson, I was told to show all databases in a MongoDB instance by typing in the “
show dbs” command, which listed four databases as expected. After this list was shown, I was to click the “Check Work” button to verify my progress before proceeding. But when I clicked “Check Work”, nothing happened. I did not see a successful check, which would have allowed me to proceed. In the absence of success check, I expect to see a red X telling me my answer was wrong and need to try again. But I didn’t see that, either. Nor did I see any sort of an error message. No “Pass”, no “Fail”, and not even a “Oh no something is wrong”.
So Codecademy’s Learn MongoDB course was a bust, but as mentioned earlier, MongoDB has their own collection of learning resources. The reading material so far got me interested enough that I want to continue learning MongoDB. Instead of waiting for Codecademy to fix their backend, I will switch to MongoDB’s learning platform.