34
A MongoDB Learning journey
This is my tale of fumbling and tumbling into love with MongoDB, as the data store for the product, we are building at Introvoke, to power right scale branded virtual and hybrid event experiences for organizers, OEMs and enterprises.
Most of professional life while developing applications using different technology stacks, I have primarily used RDBMS as my data store. Many times it was Microsoft SQL Server as I was primarily a .NET/C# developer working at Microsoft. I had the pleasure of working with MySQL, PostgreSQL, IBM DB2 and yes, Oracle as well, working for start ups, software vendors, educational institutions and large enterprises. Good and robust products, for the solutions they power and price points they offer.
Until I joined my new role at Introvoke in late April 2021, my primary exposure to NoSQL technology was via Azure Cosmos DB. To appeal to enterprise developers like myself, Cosmos DB offers a SQL like query language and that is what I defaulted to when I used Cosmos DB.
The choice to use MongoDB and in a hosted fashion using MongoDB Atlas was done prior to my arrival at Introvoke.
My primary responsibility at Introvoke is to build and manage analytics, integrations and API for the platform.
The first task that I was pulled into was to make calculations of consumption on our platform perform better and more precise, so I had to dive right into learning MongoDB, right away. (Ahh... I only heard of tech intensity as an industry buzzword from Satya Nadella, when I was at Microsoft and now I was feeling it).
This is the path I took. As anything else in life, there are always more ways than one and varies by learning style.
The reason I jumped in here was primarily - HABIT. As a engineer at Microsoft, this was one of many learning resources that was available to me and over the years it became the good starting point.
The courses which helped me on my path were:
Foundations of Document Databases with MongoDB by Pinal Dave: Pinal Dave has been a well known expert (See: SQL Authority) in the SQL world as well, so I trusted the content authored by Pinal would be high quality. It also seemed to me that Pinal would have insights into both SQL and NoSQL worlds, so easy choice there.
Aggregating Data across Documents in MongoDB by Axel Sirota: Aggregation is a powerful feature in MongoDB. I rave about it in the later section. This course is a good premier to what is possible with it.
Using MongoDB with Node.js by Jonathan Mills: Since I was building applications at Introvoke using Node.js, this course was good fit to combine them.
There are tons of other courses on Node.js and MongoDB on Pluralsight to explore, but I found these relevant immediately to what I aiming for and course content was up to date.
What better place to learn MongoDB but from the people who made it. Here is where MongoDB University comes in.
Easy to learn courses and well defined learning path and best of all at no cost! I believe, the end goal for the courses, would be obtain MongoDB certification. I started getting links to this via e-mail after signing up for a free MongoDB Atlas account.
Believe it or not, MongoDB documentation is very good. It is very rich in examples. I was able to follow the documentation in most cases easily and apply the examples in my queries.
I came across this four-part article and YouTube series on using Node.js and MongoDB by MongoDB's Developer Advocate Lauren Schaefer, while looking for a way on how to react to changes in the data in MongoDB collection. That would be change streams in MongoDB similar to Change Feed in Azure Cosmos DB or Change Data Capture in SQL Server.
I loved Lauren's style of delivery, her deep technical expertise and how beautifully she explains advanced topics with ease and lots of examples. The video, I started out with was last in the series, but I liked it so much, I went back read the previous three articles and watched the full video series.
This is probably a no-brainer but worth mentioning anyhow. MongoDB has a rich developer community backing it. If there is anything you are thinking about, the chances are someone has asked or has solved it for you at Stack Overflow. The only caveat is sometimes, the solutions relate to older versions of MongoDB, but I have seen the community very good about making that distinction while responding to queries, especially between MongoDB 3.x and 4.x.
As with learning new technology, I had to unlearn some old habits. Among them was how to think about storing data differently from the world of
SQL JOINS.At Introvoke, I did inherit a very de-normalized data store with various collections. But where there was gaps, I was trying to create JOINS, which was not always easy to pull off syntax wise for a newbie. Over past two months, I have gradually become better.
The same thought process also influencing me on how to store data in a normalized manner focusing on storing ids and instead of embedding documents.
One of the articles, which has help me design better and think more in terms on how data is to be accessed versus trying to store data concisely was this article - MongoDB Schema Design Best Practices by Joe Karlssson.
I think, it is a learning curve, most developers will face coming from the RDBMS world. As I discovered, getting a optimal solution does take some experimentation.
The MongoDB Query Language (MQL) is very powerful and in most instances very intuitive, though it can be verbose at times.
The aggregation framework, in my opinion is the most powerful feature in MongoDB and I use it on almost every functionality, I am building to return data. It can help you shape the data down to how your APIs need to return it as their data contract. Almost zero ORM. Imagine that doing it in SQL world.
The only place where I have not been able to use aggregation pipeline is data has been stored across different MongoDB clusters. That is where the Node.js application has to stitch results from different queries together, which to my amazement is real fast. That is probably a discussion for a different article.
I discovered this feature of the aggregation framework - facet, two weeks into writing queries and tying them into the API. I found it especially useful in places, where I started with the same filtered data but had to run multiple different grouping calculation on it (dimensions for data warehouse folks out there). Prior to that I was writing multiple queries for it and calling it from the application.
In the SQL world, for queries with incorrect names of the tables or columns, the schema enforcement would prompt an immediate feedback. Not so in MongoDB, it returns empty result, which can become a head scratcher at times.
There have been instances where I have misspelled the collection or the field name. For example, in some collections the unique identifier for a Company entity is called -
company and companyId in others. Another one is misspelling a collection named
EventsAggregates, as EventAggregates or EventsAggregate. I do wish at least for the collection name, there was some validation, which could alert the developer of the error. The one with the document structure, the responsibility lies with the developer (or the development team) to establish naming patterns for columns across collections.
I found the following tools must-haves for my developer journey learning how to use MongoDB and building queries for my day to day application
If you are developing using Node.js or Typescript, the chances are you are using Visual Studio code. There is an excellent VS Code Extension for MongoDB which provides connection management, browsing MongoDB collections with VS code, syntax highlighting for MQL code.The only limitation I found with the plugin, is I have not been able to get the it to return more than 20 documents for a query. There is a setting when viewing document collections but it does not seem to apply to the custom queries.
At the time of writing this article in June 2021, it has been only two months into learning this fantastic technology. I am sure, I will have more to say in the coming days.
DISCLAIMER: Opinions expressed in this article are solely mine and do NOT represent those of my employer.
34