Last week I had the pleasure of attending Node Summit 2016 in San Francisco. I am eager to share some of the new cool technologies and concepts I learned about while I was there.
The one hardware workshop at the conference proved to be perfect office hackathon fodder. Particle.io is a platform for interacting with internet of things devices, and using node and their Photon microcontroller we were able to program a row of lights to act as a scoreboard for a game of tic-tac-toe. As someone who deals strictly with software, it was a welcome diversion to play around with breadboards and resistors for a few hours.
One of the most insightful and fun presentations I attended during my time at Node Summit was on security. This talk featured a lot of great examples of trying to hack into or disrupt a locally hosted web application. Of course, the main thrust wasn’t to teach people how to hack–though I can’t say I didn’t learn a thing or two–but to show how out-of-date node modules can bring security vulnerabilities to your codebase. The presentation concluded with a stern warning that actual hacking was illegal and an insight into a current company for those in need of a fix:”bugcrowd” a platform that lets companies pay bounties to hackers to break into their systems so that they can close any security gaps.
The main buzzword at the conference was micro-services. Every sponsor from NASA to Netflix gave talks on how they have transformed their entire systems over to use this architecture concept.
Micro-services are not specific to node, but node’s flexibility means that it lends itself well to the concept. The micro-service pattern refers to breaking out all of the functionality of your product into independent pieces, instead of housing them within a single unit–known as a “monolith”. This way, when you make changes to your app, you don’t have to redeploy your entire codebase. Instead you’re deploying just the parts of the app that were affected by changes. This works especially well in node because you to pull in only the modules you need for each individual micro-service, and there are tons of node modules out there designed with communication between micro-services in mind.
Looking back at the conference as a whole, I was inundated with the vastness of node itself. Every year for the past four years the numbers of new node users has doubled, and there are 300+ new modules published every day. This has inspired me to try them all out and bring cool new technologies back to Shockoe.
The last few weeks we have focused on web service design using Node.js with Express. So far we have covered getting started with express, using EJS to create web pages, and creating a push notification server. Today we will go over how to save data on your node project by using MongoDB.
This post will assume that you have MongoDB installed on your machine already. Check out the MongoDB Installation page if you do not have it setup.
First, let’s go over MongoDB a bit. MongoDB is a document oriented database. This allows you to just shove whatever JSON you want into it. You don’t have to declare a table structure like you do in SQL. You don’t even need to declare your collections at all. If you try to use a collection that doesn’t exist it just gets made for you immediately. Documents are stored in collections that you define, but documents within a collection don’t have to be similar at all. MongoDB also features an amazing query system. Imagine we want to store information about fruit. We could do the following:
We now have a fruit collection containing one fruit: an apple. Let’s add a few more:
Now we have a strawberry and an orange in our fruit collection. To get all fruits in our collection that come from trees we would do:
If we wanted to find all fruits that are red we would do:
And to find all fruits that are yellow or orange we would do:
Now apples can be green too. Let’s modify our apple entry to reflect that:
There are a few interesting things to be aware of when updating a document. By default, mongodb will only update the first entry it finds. You can set the multi option to force it to update every entry that matches the query. Also, note the $push operator I have included in the update object. That is telling mongo it will be adding an entry to an array on the document. If you left off push and just did:
You would be very disappointed. Setting no update operator will replace the document completely:
So what if you wanted to update a field that isn’t an array? You use the $set update operator:
MongoDB is very powerful and an excellent document store, but it lacks the join power that SQL brings to the table. You can join documents together by their _id field using MonoDB’s populate, but it’s not nearly as fast as what you can do with a few SQL joins. I encourage you to explore MongoDB as an option for your databases, but it’s important to approach your database design differently with MongoDB than with SQL. Be sure to check out the documentation for all you can do with MongoDB.
So how to we start using Mongo with Node? There are several libraries available on npm for connecting to Mongo, but I will be focusing on Mongoskin and Mongoose.
Let’s go ahead and get Mongoskin out of the way. Mongoskin is what you want if you just want to run basic MongoDB commands and nothing more. To get started add Mongoskin as a dependency:
And then in node:
Mongoskin is very easy to use and most MongoDB commands are supported. It has its issues, but if you want something simple to connect to a mongo database look no further. If you want the best MongoDB experience you can find with Node, keep reading!
On to Mongoose. As they say on their website: “Mongoose provides a straight-forward, schema-based solution to modeling your application data and includes built-in type casting, validation, query building, business logic hooks and more, out of the box.” Mongoose is a delight. To get started add Mongoose as a dependency:
It’s nice that MongoDB doesn’t need to have schemas, but it’s great that Mongoose gives them to you. Let’s put together a schema for our fruit collection:
Most of the schema above should be straight forward. Name must be a string or Mongoose will remove the property from the object before using it as a model. Color must be an array of strings. Source must be a string, and if it’s not present Mongoose will automatically set it to “tree”. Default values will not get stored in the actual database, but they will be applied when Mongoose pulls them out. The virtual “numberOfColors” will add a property automatically. Virtuals are great for properties that can be calculated based on the existing data on the model.
To use the fruits model:
The examples above barely scrape the surface of what you can do with MongoDB and Mongoose. Do yourself a favor and explore the possibilities of a document oriented database backed by MongoDB.