What do you want to learn?
Skip to main content
Introduction to MEAN.JS
by Mark Scott
This course introduces web developers to MEAN.JS, a free, open-source, full-stack solution for MEAN applications.
Start CourseBookmarkAdd to Channel
Table of contents
What Is the MEAN Stack?
Why Use a Boilerplate Framework?
We throw terms around the time, like coke when we may generically just mean a soda or a cola, maybe not the specific brand Coca-Cola. So, let's take a short departure and find out what the term boilerplate really means. The origins of the term boilerplate are kind of interesting to learn about, and then to see how that term may or may not apply to software development. Interestingly, the term arose from the newspaper business. Columns in other print pieces that were syndicated were sent out to subscribing newspapers in the form of a mat. Once these mats were received by the newspaper, boiling lead was pored into the mat to create a plate. This plate was used to print the piece, hence the name boilerplate. Knowing that history, we fast forward to software development. In that space, this term and its use are a little murky. It can mean different things to different people but generally just means a block of code that is used over and over again. The original contributors to MEAN.JS used the term boilerplate, so we will use that term in this course as well. But it may be more appropriate to think of this as an application scaffolding tool. Similar to framing in a house or building, we were given the framing and some basic plumbing by MEAN.JS but we get to decide what type of drywall, paint colors, flooring, lighting fixtures etc., we want to put on our new software home. We can also think of this as code generation through the use of templates. Speaking of code generation, and back to our original question, why use a boilerplate framework, let's discuss some of the benefits of generating code versus hand rolling the entire application from scratch. First off, consistency. It goes without saying that if you use a template to generate boilerplate code, you're going to have a consistent start to that code base. Next, fewer bugs. The code in code generation templates is generally clean, tested and proven code. Best practices. A large number of frameworks are open source with wide community involvement and support. When something is poorly developed, or worse, breaks, there's a lot of noise. When something does not make sense or structured poorly, the crowd of open source developers cries and it typically gets fixed. Not always but in a lot of cases you will find clean, well-structured, best practice following code in a well-liked community-supported framework or code-generator template. Support. While this certainly cannot be said for every open source framework out there, popular ones, such as MEAN.JS, have good documentation, good community involvement and helpful code examples. You'll not be out there on your own should you need some support. And lastly, time. Don't waste your time doing the same things over and over again. Use a framework or a code generator. In future modules, we'll see how MEAN.JS utilizes code generation through the use of Yeoman. But first, let's discuss the origins of MEAN.JS, its family tree, if you will.
Comparison of MEAN Stacks
Demo Project Preview
For our demo project, we will be building a website that post the volunteer needs of various charitable organizations. Visitors to the site may click on a particular volunteer opportunity to get more details and then sign up to volunteer for that particular need. As we will see in a moment, the default, out-of-the-box MEAN.JS application comes with a reasonably nice bootstrap theme. But regardless, for real-world applications, you will want to use your own style. So, we will have a look at how to incorporate a custom theme that you may have either downloaded or obtained from a web designer. There are a number of very nice bootstrap and angular-based themes available. Some are free and other professional quality themes are very reasonably priced. For our demo project, we will be using a bootstrap theme called Solid, available for download here at this URL. Let's start out by taking a look at the out-of-the-box MEAN.JS application. I'm going to kick the website off by typing grunt here on the command line interface. Don't worry, we'll talk about this in more detail as the course moves forward. But for right now, we'll just jump right in and see what we have. By the way, I already have MongoDB running locally here. Opening up a Chrome browser and navigating to localhost port 3000, we can see the scaffolded site MEAN.JS initially gives us. It's a bootstrap responsive theme that's not too bad, but again, we're going to want to swap that out for one we downloaded. Moving back over to our command prompt, let's move over to a version of our demo site that already has the theme changed out. Rerunning grunt to kick things off here and refreshing the browser here to see the new themed site. Here's our Solid bootstrap theme. This is also a responsive design. Different fonts and color schemes here. Clicking on the View Current Volunteer Needs button here, will take us to a list of volunteer needs previously loaded in the database. Let's select dog walker to look at the details view for that volunteer need. We can see here on this page, the user is presented with a description of the volunteer need, how many people are needed and who I want to put some authorization around the edit and delete buttons here, so that only those who are logged in, and also in the admin role, can edit or delete a record. On the right side here, users of the site can sign up to volunteer for this need. An email will be fired off to the admin of the site. Let's log in to the site now and create a new record. I'll sign in and enter the username admin and the password. Under the Volunteer Needs drop down, I'm going to select New Need and we are presented with the New Volunteer Needs page where we can add a title, a description, the name of the organization and location and, as applicable, the start and end dates of the volunteer need. Then finally, the number of volunteers wanted for this particular need. Saving the record returns us to the Need Details view and we can see the volunteer need data was saved successfully. Returning to the full list of volunteer needs, our new record shows up there as well. This theme is not going to win any design awards but it will be useful in demonstrating where in the MEAN.JS framework we need to go to swap out our CSS and HTML elements.
Meanie, the cat here, is going to help us summarize each module. He's pretty grumpy, especially since there is nothing to summarize in this introduction module. In the next module, we will go over the tools and libraries that we will need to get our MEAN.JS boilerplate application off the ground. So, join me in the next module on Getting Set Up. I'll see you there.
Getting Set Up
Welcome to this module on Getting Setup. My name is Mark Scott. Let's start this module out by going over a few of the prerequisites for this course.
As noted in the Mean JS online documentation, before we can start, we need to make sure that node JS, MPM, mongoDB, Bower, and Grunt are all installed on our system. Future versions of Mean JS will also support, and give you the option to use Gulp, for your build system and task runner. At the time of this recording, the current version of Mean JS is 0.3.3. And you will notice on the meanjs.org website, under troubleshooting, that the version of Node JS which is supported is 0.10.X. You may be tempted to simply install the latest and greatest version of node JS, but you may run into some odd issues if you do. For example, installing node JS 0.12.0 seems, at first, to work, but there are some compatibility issues with the Mongoose and Mongo Connect packages that are used within Mean JS 0.3.3. Therefore, it would be wise, at least for now, stick with the latest 0.10.X version of node JS. And for this course, I'll be using node JS version 0.10.36, and that can be found directly at this url. That url takes you to a rather nasty looking page that looks a little like this. If you want or need the 64 bit version of node, be sure to go into the X64 folder shown here. Windows users, you'll want the MSI file, shown here. And again, if you want the 64 bit version of this, be sure to go into the X64 folder. Mac users, you'll want to download the PKG file, and finally Linux, Sun OS and others, can download the respective TAR file. Follow the instructions for your particular platform. Installing node JS is pretty straightforward and simple, but please do refer to the online documentation at nodejs.org should you get into trouble with your particular installation. While it certainly is not required that you install mongoDB on your local development box, it probably is a good idea to have it on hand, at least initially while you follow along in this course. You can certainly utilize a cloud based instance of mongo DB, such as mongo lab or compose.io later. To install mongoDB, head on over to mongodb.org/downloads, as shown here. There, you will find the installer appropriate for your operating system. Simply follow those directions. Even though mongo DB version 3.0 has been released, for this course we will be using version 2.6.7. Mean JS has not yet been thoroughly tested against 3.0, it should work just find with mongo DB 3.0, but again, for this course, we'll stay with the 2.6.7 version. Now that you have node JS installed, the node package manager, or npm, is available to you. We'll be using npm to install our other required libraries now. Bower, for our client side package management, and Grunt for our task runner. To install bower, simply enter in nmp install dash g bower into the command line interface. Notice the minus g, which instructs nmp to install bower globally, making it available for use in any project folder location. Next, let's install Grunt by entering in npm install dash g Grunt dash cli. We will start with Grunt in this course, since that is what the current version of mean JS uses by default, but as mentioned earlier, you will see that, in the upcoming version of mean JS, you have the choice of using either Grunt or Gulp. In reality, you have that choice right now. Mean JS is only slightly opinionated, and you are fairly free to swap out and use whatever you want here. Although it is not listed as one of the prerequisites, because we will be using the yo generator to scaffold out our application, we need to make sure that YEOMAN is installed as well. We will do that here by entering in nmp install minus g yo at the command prompt. At the time of this recording, the master branch version is 0.3.3, as mentioned earlier. However, version 0.4.0 is right around the corner and it's also available on the get hubbard pository. By the time you watch this course, it may actually be the master branch, but for now, it's just not ready for prime time yet. We'll be looking at the upcoming 0.4 code in this course as well, in preparation for the changes that are coming. The path to the 0.4 repository is listed here. In the next clip we will use the YEOMAN generator that is available to us in the current version, and again that's 0.3.3, to scaffold out our mean JS demo application. We will then take a quick preview of the scaffolded boilerplate website that was generated for us. So let's fire up our command line interface and get started generating our site.
Scaffolding a Full-stack Application
I'll start this demo out by changing directories into our project folder named volunteer. Now, let's install the YO mean JS generator using the dash global flag, so that this generator will be available to use in any folder on our system moving forward. By convention you will notice that all of the YOEMAN generators begin with the word generator, followed by a dash, and then the name of the generator itself. Okay, the YO mean JS generator is now installed and ready to use. By the way, for a list of all of the YO generators available, head over to the YOEMAN website, found at this URL. YOEMAN.io/generators. If, for example, we enter in the search term of mean here, and while mean JS does seem to be the most popular one right now, which is good since you are taking the time to learn about it, you can see there a number of other YO generators related to the mean stack here. Let's jump back over to our command line and make sure we're in the proper folder before we begin generating our application. We are, so at the command prompt we simply need to run the YO command, followed by the name of the generator that we wish to use. And in our case that's obviously going to be mean JS. Notice that we do not have to enter the full name of the generator, just a portion of the name following generator dash. The YOEMAN generator will begin by asking a series of questions, starting with what would you like to call your application? We will name our application volunteer. For the question, how would you describe your application, let's just accept the default value for now, we can always go back in and change this later. For how would you describe your application, we will also accept he default values here, for now. As we examine the structure of the application in later modules, you will see where these values are injected. Next, for company or author name, we'll enter plural site. Or, of course, if you're following along with me here, you can enter in whatever you'd like there. For this demo, and so that we have something to review in the next section, I'm going to go ahead and say yes on the generation of an example article crud module here. We'll take a look at what that gives us here in just a moment. Now we are being asked about which angular JS modules to include, ng cookies, ng anime, ng touch and ng sanitize. For now, we'll just keep all of these options selected. If you do not wish to include one or more of these, you simply navigate to that option and press the space bar to toggle the selection. After answering the last question, our generator is off and running, stubbing out our new website. Depending on your system, this may take a few minutes to complete. The YO generator is hard at work, setting up our applications folder structure, stubbing in files, using npm and bower to install server and client side dependencies. In the next demo, we will go through and preview the scaffolded out site the YO generator just finished for us.
Preview of Scaffold Site
First things first, and let's make sure that mongo DB is running locally and on the default port of 18.104.22.168. Next, let's launch the site using grunt. So, you may be asking, why run the site using grunt? In the next module, where we take a tour of the scaffolded site's code and folder structure, we will take a quick look at the grunt file that was generated here and explore the tasks that are run for us by default using grunt. For now, to get this site up and running, let's just type in grunt at the command prompt. Here on the command prompt, we can see that our site it up and running now and available on port 3000. Let's open that up and take a look at what we have. Okay, nice, it's pretty basic, but it is a boilerplate scaffolded site after all. You may recall that we told the YO generator that we did want to build out a sample article crud module. Before we can take a look at what that gave us, we need to sign up first on the site. That gives us a quick look at the sign up and authorization that is provided out of the box, too. We'll select sign up, and then provide the first name, last name, email address, user name and password details. One thing to note here, as a brief side, you'll probably want to add an extra password verification field here, to help users avoid typos with their passwords. Great, okay, now I'm officially logged in to the site, and now we see the articles menu option here on the navigation bar. Selecting the list articles menu, I can see that we currently do not have any articles in the database. I'll select create one here, and enter the new title and contents for a sample article. I'll just copy and paste in some sample text from dummytextgenerator.com. Submitting that saves our article to the mongo DB database and returns us to the articles list page. Now that we have an article, we have a couple of additional buttons over here that allows us to edit and or delete this article. This is pretty basic stuff, but really that's the point. You will be building on top of this boilerplate code to make something really great and useful for your own business needs.
In this module we covered the tools and libraries we needed to get our mean JS boilerplate application off the ground. In particular, node JS, mongo DB, Bower, to manage our client side dependencies, Grunt for our task runner, and of course YOEMAN, which we used to actually generate our boilerplate scaffold site. We took a short preview tour of the boilerplate site that mean JS gave us, out of the box, via the YO generator. But in the next module we will take a more in-depth tour of the application's folder and code structure. I hope you'll join me in the next module for that tour. I'll see you there.
Tour the Scaffold Site
Welcome to this module where we will tour the scaffold site. My name is Mark Scott. In the previous module, we used the yo generator to generate out a fairly nice boilerplate site for us. The nice thing is that the yo generator generated a lot of well-structured code for us. The bad thing is that Yo generated a lot of well-structured code for us. As we go through this module together, I'm sure you will understand what I mean. If you had to hand-roll all of that code yourself, you would be very familiar with it, but you would have spent a lot of time doing so too. The main purpose of this module is to give you a roadmap of sorts so that you can navigate through the code and folder structure that was just set up for us. We do not need to understand every single aspect of this boiler plate application, to get started and to be productive. But a good foundational understanding goes a long way in avoiding a fair amount of frustration. We need to start this module off by first looking over the Boilerplate application's structure, discussing how things are laid out and where to find key pieces of your application. Next, we'll move on to discuss configuration. You know, things like connection strings to MongoDB, for example. You're clearly going to need to know where to make those types of changes. Finally, we're going to take a quick look at the upcoming 0.4.0 version of MEAN.js, and do some comparisons between 0.3.3, the current version, and 0.4.0.
Application Structure (Server-side)
When it comes time to customize the Boilerplate code that MEAN.js provides for us, it will be very helpful to understand the folder structure and other patterns that MEAN.js uses. In this section, we will see that files are primarily divided up into two parts, code for the server side and code for the client side. We will start by looking through the folder structure that houses the server-side code, and then move on to our client-side folders and files. Let's jump back into our editor and take a look. The server side code for MEAN.js 0.3 lives here under the app folder. Any time you need to work on a server-side controller, model, route, test, or view, this is where you'll want to go. And as we can see here, those various file types are separated out into their own respective sub folders, controllers, models, routes, tests, and views. We'll start with the controllers folder. As discussed in the course introduction, the E in MEAN stands for Express. Here we find our server-side controllers, which is where your business logic and restful API service code lives. In the previous module, we examined the sample application that will scaffolded out for us, and we created a sample article of record. Now let's take a quick look at the controller code here that was used to create and list those article records. First take note of the naming convention in use here, articles.server.controller. Later when we look at client side code, you'll notice that the same naming convention is in use there with files being named .client and so forth. We'll not go into great detail right now on this particular controller file, but here is the article Mongoose model used to retrieve data from and save data to MongoDB. Next we see the CRUD, or create, read, update and delete functions, as well as a list and article by id function to get a full list of articles or an individual one by its id from MongoDB. We will go in to more detail on these functions and build out our own controller for our volunteer needs demo application as the course progresses. The next subfolder down the list here is models. This is where we find our backend models for the application. As noted earlier, these are Mongoose models, and are what we use to communicate with M in MEAN, MongoDB. We will be building out a custom Mongoose model for this course, but to get more detailed information on Mongoose, please take a look at my other Pluralsite course, Introduction to Mongoose for Node.js and MongoDB. Next we find the routes folder, which contains our server side route mappings. For example, if we open the core.server.routes.js file, we can see that the root of the site is getting core.index. Notice above where the core variable is defined and we can see that we are requiring the core.server.controller file and this is where the index method is located. For another example, let's take a look at the article routes that were setup for us by the generator. Here we can see the various get, post, put and delete routes. As an example here, take a look at this get route. Notice that the articles.list is obtained by requiring the server side controller we looked at a moment ago. Now we'll open up the tests folder. MEAN.js uses Mocha for testing server side code, and while we will not go into any details on testing here in this particular module, we will cover that in the testing and deployment module later on in this course. For now, just know that this is the folder these tests will live in. Now let's take a look at our server side views. There are not many views here, and that's a good thing. Keep in mind, these are server side views. The vast majority of the views in our application are going to be Angular client side views. As you can see, we have views for handling 404 and server side errors. The index view is the shell in which we load our client side Angular views and the layout view file is our master layout, or theme template if you will. We will modify the layout view in a future module when we apply our custom theme. Let's move on down to the server.js file for a moment. You may also see this named something like app.js and other Node.js web applications. This is the main entry point for the application, where everything gets kicked off from. The contributors to MEAN.js have done a good job of keeping the server.js file clean and clutter free. I'm sure we've all seen demos where everything was placed in this file. Here are the main things to take note of in this file. Here at the top is where our node module dependencies are defined. Next we see where we are establishing a connection to our MongoDB database. And initializing the express application. You can see the various places where files are being required from a config folder. We'll be covering configuration and revisiting that folder in that section of the course. Here you can see the MEAN.js utilizes Passport for authentication. And finally we will open up a port and start listening for inbound requests. Now let's open up the package.json file and take a brief look at that. There are four sections to this file, metadata here at the top, scripts, dependencies and development dependencies. When we ran the yo generator in the module on getting set up, we were asked what we wanted to name our application to provide a description, version number and so forth. This is where that information landed for us. So should you want to make some tweaks to that information, here's where you'll find those details. There are a number of node packages utilized in MEAN.js. And those are all listed here in the dependencies section of the package.json file. The last section is where we find our development dependencies. These are the node packages that will not be included in a production build. That was a tour of the folder structure and key aspects of the server side code that were given out of the box by MEAN.js. Now, let's shift our focus on to the client side code.
Application Structure (Client-side)
In a previous module, we generated our new boilerplate application and we took a quick look at the app and what we get out of the box. We headed some sample articles and that all seemed to go pretty well. So we can assume this data was saved to our local running instance of MongoDB, but where is that data connection information stored? What if we decided to change the name of our application or the connection string to MongoDB, or change the keyword details for SEO purposes. Where do we go to configure our application. That is what we're going to talk about next. So let's jump back into our editor and take a look at how configuration is setup in a MEAN.js application. Let's start by opening up WebStorm or whatever editor you choose to use and head over to the config folder and open up the config.js file. Notice in this section of the file that this is where the app configuration files are loaded. One named all.js and the others based off of the node environment variable setting. For example, we are by default set to use the development node environment so we can expect to find a development.js configuration file. Opening up the environment or env folder here, we can see the various application configuration files available to us, and those will be loaded based again off of the node environment variable setting. Well start by taking a look at the all.js configuration file. Do you recall some of the questions asked of us when we used the yo generator to scaffold out our site? Here's where some of that information landed. Our application's title is here, a description, and keywords for SEO purposes are all here as well. Moving on down the list, we can see that we're using swig for our view engine. And here's where the various assets for our scaffolding site are defined. Any future module where we provide our own theme, it's going to be important to remember that this is here. This application configuration file will get loaded regardless of the node environment variable settings. So let's take a quick look at what the development.js environment file gives us. Okay, so you can see now that this is where MondoDB connection string is defined. We're going to leave this as is for now, but should you need to change this to, let say point two Mongo lab or compose.io or some other cloud provider, this is exactly where you'd want to go to make that change. We will not be using any of these other configuration settings in our application. But should you choose to provide authentication through, say, Facebook, Twitter, Google, LinkedIn or GitHub, this is where you would configure that. We will take a closer look at the production configuration settings in the module on testing and deployment. For now, just know that this is where you'll need to go to make configuration setting changes for your production environment. Earlier we were talking about which configuration file would get loaded based upon the node environment variable setting. The question may be how does our application know to use the development by default. Heading over to the net.js file here, we can find that answer. If we had specifically set the node environment variable, this section of code would validate that we indeed have a matching configuration.js file to load by that same name. If, however, we did not set the node environment, then we can see that development will be set as the node environment variable for us, ensuring that the development.js configuration file will be loaded in the subsequent call to config.js, what we looked at first here. So where is all of this configuration loading originally kicked off from you may be asking. Let's take a quick look at the server.js file here. Notice the first two requires are to our config/init.js file and then to config.js. That is what sets this whole thing in motion. While we are here in the server.js file, let's move down just a little and notice one more configuration file that is getting called. The one to initialize our express application, the E in MEAN. Let's take a quick look at what's in express.js file. We will not go through this entire file, but you can quickly notice that this is where the module dependencies are required. The main takeaway from this file is that this is where the express application is defined and returned to the startup server.js file. One other thing to make note of while we're here, is how the contributors to MEAN.js have set this up in such a way as to have several objects automatically loaded during the application Bootstrap process. Let's run down the list of what those are. Here we can see that all the server side model files are loaded, and here we can see the various routing files that are loaded for us. If we reopen our server.js file and move down just a little, we can see the section of code where our passport configuration is loaded up. MEAN.js utilizes the passport.js library for user authentication. A moment ago, we saw the settings for logging via Facebook, Twitter, Google, LinkedIn, or GitHub. Passport uses various strategies for this and depending on the needs of your application, you will want to ensure those strategies are loaded. This is where the various Passport strategies you have defined are loaded automatically for you. For other specific configuration settings you may need to make tweaks to, such as a particular passport strategy, or how to setup custom configuration properties, I would encourage you to visit the MEAN.js site and review their good documentation.
That was a lot to take in all at once. You may want to re-reference this module and also take a look at the online documentation at meanjs.org. The main goal of this module was to give you a roadmap so that you can navigate through the code and folder structure that you will find, whether you use the Yeoman generator as we did earlier to kick off a boilerplate site, or if you simply cloned the MEAN.js repository on GitHub. Granted, there is a lot of code here, but having a foundation of what files go where and how to configure your site, you should be able to get started right away. In the next module, we'll do just that by using the Yeoman generator to generate a CRUD module that we'll need for our demo application. I'll see you in the next module.
Welcome to this module on code generation. My name is Mark Scott. In this module, we will learn about the Yeoman Project and in particular, the Yo web application scaffolding tool that was used in the getting set up module. A number of the MEAN.JS sub-generators will be discussed and demonstrated as well. In the demo, we'll take a look at the CRUD module sub-generator and utilize Yo to generate out code similar to that which was provided to us in the article example from MEAN.JS.
What Is Yeoman?
Most of the time when you hear someone talking about Yeoman, chances are they are actually referring to only one part of the Yeoman workflow, the Yo web application scaffolding tool, which uses generators, or templates if you will, to stub out web projects for you. But there are two other tools that make up the full Yeoman workflow. Those are a package manager, such as Bower, and a build system, such as Grunt or Gulp. None of the three tools that comprise the Yeoman workflow provide a user interface and therefore are used via the command line interface, as you've already seen when we stood up the basic MEAN.JS scaffold site in a previous module. The Yeoman team has done a great job providing documentation, tutorials, and examples on their website, and I would encourage you to visit their site for more details on the Yeoman Project, including a full list of generators that are available, one of which of course is the official MEAN.JS Yeoman generator we used earlier. Just click on the Discovering generators link at the top.
Many of the Yo generators provide the ability to scaffold out additional parts of your web application. These are called sub-generators. The MEAN.JS generator includes a number of these sub-generators, and we will discuss a few of those here in this section of the code generation module. The MEAN.JS sub-generators fall into one of three categories, a full CRUD module sub-generator, those used for Angular, and those used for Express. We will start by demonstrating the CRUD sub-generator. When we first used the MEAN.JS Yo generator, one of the questions asked of us was whether or not we wanted to generate a sample articles CRUD module. We selected yes and have since examined the results of that action. By selecting yes, the MEAN.JS Yo generator actually utilized its own CRUD module sub-generator to create the modules folder and supplemental folders for images, CSS, routes, controllers, and tests. The sub-generators were also used to build on Express and Angular module files to create Angular module views and if we indicated that we wished to add this CRUD module to the navigation menu, the necessary menu configuration as well. In the next module, we will need to utilize the CRUD module sub-generator to add in to our demo application an additional CRUD module to handle our volunteer needs. When you need to generate out a one-off CRUD module like this, simply run the yo command plus the main MEAN.JS generator, followed by a colon and then crud-module, plus the name of the module you're wanting to build out. For example, if you want to generate out a customer CRUD module, this is what it would look like at your command prompt. By the way, should you want to dig into it and look at the actual code behind all of this magic, the CRUD module's sub-generator source code has been made available on GitHub at this URL. In fact, you can find the source for all of the sub-generators on GitHub. One of the first sub-generators the CRUD sub-generator used was one to scaffold out our express controller. In the example shown here, we can see that the main MEAN.JS CRUD module utilized the express controller sub-generator to generate the articles controller. As before, should you need to generate a one-off express controller, you can simply type in yo meanjs:express-controller, plus the name of your controller in the command line interface. And likewise, should you need to generate a one-off express model, you can simply type in yo meanjs:express-model plus the name of your model in the command line interface, as shown here. Our scaffolded boiler plate demo application included a sample article CRUD module. Part of the code that was generated there for us was the express routes, which allow for data to be retrieved from and saved to MongoDB. Occasionally, you may need to build out an individual express route file, and using this sub-generator will do just that for you. As with other sub-generators, simply enter yo meanjs:express-route plus the name of your new route. This sub-generator doesn't do a whole lot. It merely stubs in an empty route file for you. Feel free to use the article route as an example of how you can build out your own route, should you need to. Now, let's take a look at some of the sub-generators that allow us to build client side angular modules, routes, controllers, views, services, directives, filters, configurations, and tests. As with the express modules that were generated for our example articles module, there were a number of client side angular sub-generators that were put into motion for us to generate out angular routes, a controller, a service file, and some tests for our controllers, and finally, the various views to create, edit, list, and view our sample articles record. Should you need to generate a one-off angular module, you can simply type in yo meanjs:angular-module plus the name of the angular module you wish to generate on your command line, as shown here. Let's say for example that we wanted to generate out a angular module named widget. We would enter on the command line yo meanjs:angular-module widget, as shown in the example. The sub-generator will ask, "Which folders would you like your module to include?" Simply toggle the various folder selections on or off as your needs dictate. The angular module sub-generator then goes to work creating the folder structure based on your selections and, for our example here, a file named widget.client.module.js. Taking a look in the angular public modules folder, we now have a widget folder with sub-folders, again based upon the selections when using the module sub-generator. Again, the only file that was generated for us here was the modules file. The config, controllers, services, tests, and views folders are empty at this point. But as you might imagine, there are sub-generators to help us out there, and we'll take a look at some of those now. If you generate a one-off angular module, chances are you may want an angular route as well. The pattern here is the same, yo, followed by meanjs, a colon, and then angular-route, plus the name of the route you wish to generate. Let's take a look at another example of generating a widget route for this widget module. Notice here that the first question the sub-generator is asking is, "Which module does this route belong to?" Use your arrow key to move down and select the appropriate module, which, for our example, is widget. The angular route sub-generator will ask a few more questions, such as, what would you want your route path to be and what you want to name the associated view and controller files. The assumption here is that since you are generating an angular route, you very likely will want and need a controller and view as well. In this example, you can see that the sub-generator created four new files for us, the routes.js file itself plus the controller file and tests for our controller file as well, that's a nice bonus, and then, the view.html file. However, should you need to generate out a separate angular controller, here's how that can be done. Again, the exact same pattern as before, yo, then meanjs:angular-controller, and the name of the controller you wish to generate. Tell the sub-generator which angular module this new controller belongs to, as we've seen before, and the new controller and the test files will be added to that angular module. And to add a one-off angular view, you guessed right. Same pattern here, too, yo meanjs, then angular-view, and the name of the view you wish to generate. In this example, we've already answered the question, which module does this belong to, and what is the name of the controller for this view. But notice the question about adding a route for this view. Much like when we used the angular route sub-generator, it will ask us about generating a view. The reverse here is true as well. If you start with the view sub-generator, you're going to be asked about generating an associated route as well. After answering the last question, what is your route path, the view.html file is generated. As you utilize these sub-generators, you will notice that they are only getting the basic scaffolding done for you, laying out the folder structure, generating some files which follow the name convention we've seen in use here, and stubbing in some basic code and not a lot more than that. It's up to you to add the meat to the skeleton, if you will.
Building out the Scaffold
For our demo application, we're going to need a new CRUD module, one that we will use for the volunteer needs we want to list out on our demo application. Just like the example articles CRUD module we have been exploring already, this module will need to provide us with the ability to create new volunteer need records, or MongoDB documents to be more precise, read in existing volunteer needs, update existing documents, and naturally delete those documents as well. We could copy all of the files originally generated for the articles example CRUD module and start swimming through code, changing names from article to something else, but we're not going to do that. Instead, let's utilize the provided sub-generators to stub in a new CRUD module for us. Let's open up a command prompt and get that going. Here in our command line interface, to get to our MEAN.JS CRUD module sub-generator, we first start by entering yo, followed by meanjs, then a colon, followed by the name of the sub-generator we wish to use, in this case, crud-module, then the name of the CRUD module we want to generate. We'll name this CRUD module need to go along with the volunteer needs that we wish to save and display to our potential volunteer site viewers. The first prompt we see is a question about supplemental folders. Available selections are css, images, directives, and filters. If, for example, you are pretty certain that you will need some custom CSS styling for your module, then toggle that folder selection on. Same for the other folders as well. For this example, let's just say that we may need some custom CSS styles and images, so we'll toggle those two on by arrowing down and hitting the space bar and then moving on to the next question. This next question is asking about the menu system that MEAN.JS provides and whether or not you want this new CRUD module to be part of that navigation or another menuing system. In the introduction module, we saw this menu in use at the top of the page. We do need to give our users a couple of different ways to navigate to our volunteer needs listings, so let's select yes here. And then, accept the default menu identifier of topbar. Before we move on and generate our CRUD module, this question should be a clue to you that we can't have more than one menu and that your CRUD modules can interact with different menus. Say for instance, you only wanted this module listed in a side navigation menu but not the main navigation menu at the top of the page. Here's where you can make that determination. Hitting enter one more time and we're off generating code. Look at all that code that was generated for us. That's really nice. You may not have noticed just now because the code was generated rather quickly, but the CRUD module sub-generator is actually packaging up and running some of the other sub-generators we spoke about just a moment ago, both for client and server side. We can see that we have a server side model, routes, and tests, as well as a client side angular route, controller, service, test, configuration, module, and angular views to create, edit, and list documents, as well as a view to display individual records, all stubbed in for us at the route folder for our project. So unless the creators of this sub-generator have figured out a way to read our minds, and I assure you that they have not, we're going to have to go into these files and work on them a little. So let's jump back into our editor and take a look. For example, let me open up the model file here. This is not exactly what we're going to need for our mongoose model. We will get to that in the next module in this course, where we build out this model to meet our demo application's specific needs, as well as customizing the look and feel of our site. While we are here in our editor, let's take a quick tour of the files we just saw generated. Here in the app controllers folder, we see our needs controller and our routes and tests and over here on the client side of things, we have a new needs sub-folder, with angular routes, controllers, services, views, and tests. And since we said we wanted the css and images folders stubbed in for us, those are here as well.
In this module, we discussed the Yeoman Project and in particular, the Yo web application scaffolding tool that was used in the getting set up module to stand up our boiler plate web application. A number of MEAN.JS sub-generators were also discussed, and in the demonstration, we utilized the CRUD module sub-generator to generate out code for our volunteer needs, similar to that which was provided to us by the article example. In the next module, we will pick up where we left off here and take our application from merely being a scaffolded site to a usable application by building out our mongoose model, styling the application, and adding views and controllers to create and list out volunteer needs from MongoDB.
From Scaffold to Application
Welcome to this module on taking our generated code from scaffold to application. My name is Mark Scott. When this course was introduced, a partially finished version of our final demo application was shown. We saw the replacement Bootstrap theme called Solid which is available for free to download. In this module, we will download that theme, learn where in the MEAN.JS application structure the CSS and new HTML needs to be placed, and test out our new look and feel. Additionally, we will build out a new mongoose schema and model, based on the business needs for our volunteer needs demo application. Once we have our volunteer needs model in good shape, we'll move on to developing our server and client-side controller and our angular views. That will get us in pretty good shape, but we'll also want to visit the various tests that the cred generator built for us, and make adjustments to those as well. Let's get going on restyling and adding functionality to our demo application now.
Styling Your Application
In the Tour the Scaffold Site Module, we examined the folder structure given to us by MEAN.JS, and part of that structure is where our CSS and image files live. Not to mention the client-side views we need to change to match our demo application's specific needs. Let's take a moment to revisit the specific parts of our MEAN.JS boilerplate application that we will need to touch in order to replace our theme. One really helpful thing to understand up front is, where all the various CSS and image files are loaded from in the first place. Let's jump back into our Editor and take a look at that now. If we examine the application's main layout view, there you will see where and how the CSS files are loaded. As a reminder here, MEAN.JS uses the Swig view engine for server-side views. This layout view is a foundational part of the base view that is sent over to the client from the server. If you are familiar with ASP.NET master pages or layout views for MVC, this layout view serves a very similar function. This is the Swig view engine's way of looping through a collection of CSS files, providing a link to each one of them. But where is this collection of CSS files created from, you may ask. To answer that, let's start by heading over to the all.js environment file. Here we see that an array of CSS assets has been set up for us. If we need to point to additional CSS files, we'll want to add those in here as well to ensure that they are loaded. But where is this CSS assets array used at? Let's take a look at the config folder and the express.js file here. Notice here, where app.locals.cssFiles is being set to the return value of config.getCSSAssets, and the getCSSAssets function is found in the config.js file. Here, near the bottom of the file where all of the CSS assets we looked at a moment ago in the all.js environment file are globed together and returned. We then looped through those CSS files in the layout view and load each one. With that all in mind, we have a decision to make. Where do we want to put our new CSS and image files? We just saw in the all.js environment file that we're grabbing all of the CSS files under the public/modules folder, which suggests that each module can have its own CSS file, and images too for that matter. But what about the main CSS file for the entire application? That we find in the public/modules/core/CSS folder. So we can replace what we find here, and that would certainly be acceptable, or we may also choose to simply create a new theme folder that can easily house our downloaded theme. Either approach is fine, so for our demo application, let's just create a completely new theme folder here under our public folder, and copy and paste in some CSS font and image assets from our downloaded theme. I have already downloaded the Solid theme and made some minor modifications to it. But before I copy and paste in those files, let's take a moment to see where the original theme is available from. If you're following along here, feel free to download this theme or any other Bootstrap theme you may find here. There are a number of free themes available, and others are very reasonably priced. Back in our editor and here in the new theme folder, I'll copy in all of the assets needed for our new look and feel. That's great, but our demo application will not yet know about these files. We'll need to go back to the all.js environment file and make some adjustments now. We'll want to use the Bootstrap and style CSS files from our new solid theme, so we need to change out the assets lib CSS section here. Now we also need to add all of the CSS files to the assets CSS section here to ensure that these CSS files get loaded and used. For now, we'll just leave the existing CSS files here to load. We may use some of that styling for things like menus and other core parts of our application. Whether you decide to create a theme folder, as we've done here, or place the CSS and image files under a specific module folder, the process here will be the same. You just need to wire that information up in the configuration files as we've done. Now let's change gears a little and work on the mongoose model for our volunteer needs views.
In the cogeneration module, we use the Yo MEAN.JS cred module sub-generator to stub in our need module. Part of the cogeneration process created a new express mongo model for us. There's not much here. The sub-generator merely set up a shell schema and model with a bare-bones minimal mongoose schema and code to build out the mongoose model based off of that schema. We're going to need a lot more than this. For our volunteer needs mongoose schema, we're going to want to store a title and description, and which organization the need is for, and the location for the volunteer need. These volunteer needs may be ongoing or they may be needs an organization has opened between specific start and end dates, so we'll want to capture that in our schema as well. The organization requesting volunteers may need one person or many people, so we'll add to our schema the number of volunteers needed as well. We need to go back into our editor now and fix up our mongoose model based on what we've just discussed. Let's open up our model file and add the various fields we just defined that we will need for our demo application. Again, this stubbed in model is just not going to cut it. We need a lot more here. Let's clear this out and start building the model we'll need for our volunteer needs. We'll need a title, which will be a required field, a description, which is also required, the organization, and location, start and end dates, which are of type date, and the number of volunteers needed for this. Next, we'll add into the schema an array of volunteers, which will be the object ID from our logged-in user. This array will house the user IDs of those logged-in users that sign up for a particular volunteer opportunity. I've also added in isActive flag here and set its default value to true. Boolean fields such as this can be handy in a number of ways. Let's say, for example, we need to add a volunteer need into this system, but deactivate it because it's just not ready to be displayed to the public yet. Another use could be, say, for a soft delete. Finally, we have the typical audit fields of created on and created by. Okay, I think our mongoose schema and the model built from that schema are now in pretty good shape. If you would like to dive into mongoose a little more, I would invite you to take a look at the Introduction to Mongoose for node.JS and MongoDB course here on Pluralsight.
Views and Controllers
We will first start off with the homepage and its controller and view files. We do not need to change the home.client.controller.JS file or the header.client.controller.JS file either. We can just use those as they were generated for us. Let's open up the angular home view HTML file now and see what we have there. Oh, yes. We've got a lot to change in here. It would take far too long and you may fall asleep on me if I typed all of this new code out that we'll need, so with the help of some video editing, I'll be pasting in HTML code here, and we'll review in the browser what we end up with. This homepage HTML code is a slightly modified version of what you'll get right out of the box with the Solid Bootstrap theme. Now for the client-side needs controller. One of the things that we notice here is that the stubbed-in needs object does not match our mongoose model, the model we fixed up in the previous video. Let's fix this view now to match our model. And here in the clear forms field portion of the code, we'll want to clear out all of the model fields once the data has been saved to MongoDB. If you recall from the introduction module, when a mostly completed demo application was presented, we had a sign-up form on the volunteer needs detail page to allow someone to send an email to the site administrator stating that they wish to volunteer for a particular need. We will need some controller code to handle that, but we'll revisit that in a moment. Let's first move on to the various views that we'll need new HTML code for. The MEAN.JS cred sub-generator stubbed in the create, edit, list, and details view pages for us. That's great, but they did not have the look and feel, nor the correct HTML that we need so let's fix those up now. We'll start with the create view. The only form field we see in this boilerplate code is one for name. In way of review, we'll need fields for title, description, organization, location, start and end date, and the number of volunteers needed. Let's pop that HTML in here now and review it. And here we have our form input fields that match our mongoose model. We'll need very similar HTML for the volunteer needs edit page, too, so let's take care of that now as well. We need to list out all of our volunteer needs and we have a view stubbed in for us there, too, so let's take a look at that now. As before, I have some prepared HTML that will get pasted in here. We can see here that we are utilizing angulars NG repeat to loop through a collection of volunteer needs that we retrieved from MongoDB through our express API service endpoint. When a user clicks on a particular volunteer need, we want to take them to a details view for that need. That will be our view-need.client.view.html page So let's replace this HTML now, too. Besides replacing this boilerplate HTML, we're also going to need to add in our sign-up form on this view, so let's get to it. Okay, there we have it. All of the views we need to create, edit, list, and display volunteer needs, as well as allowing the site users to sign up for a particular volunteer need. Let's kick off node and run our site just to see what we have now. Of course, we need to make sure also that we have a instance of MongoDB running. We already have some sample data in a MongoDB database, so let's run over to the volunteer needs list and see what we find there. Okay, looks good. Now we need to sign in to the site so that we can see the create new volunteer needs view. And there we have it. Going back to the list of volunteer needs, and now that we're signed in, we can click on a need and see the details view of that need, and the form to allow us to sign up for this particular need. In the next video, we will add in the necessary code to actually send off that email.
While we certainly could use a package such as Nodemailer to send volunteer sign-up email notifications back to the admin of our demo site and use our own email server or perhaps a Gmail account, we are instead going to use a really nice service called SendGrid, a cloud-based email service provider to send our email messages. I will not go through the details of signing up for an account here in this course, but if you would like to follow along and sign up for a free account, visit this URL. SendGrid has provided us with a NPM package over here at NPMJS.com/package/SendGrid. To install SendGrid so that we can use it on our application we need to fire up a command prompt and use NPM to install that. And here is what that would look like. NPM install sendgrid and --save. Don't forget to use the --save to ensure that this package is saved to the package.json file. The SendGrid team provides really good documentation on their main site, but recommend that you visit their github repo to view code examples for Node.JS, and that URL is found here. Let's jump back into our editor and add in an API end point to expose this new SendGrid service. Our email API controller needs to live here under the app folder, controllers subfolder, and here in a minute we will create that new controller and name it email. In way of review, do you recall the module on generating code? Why don't we try to utilize the Yo Generator here to stub this controller in for us, and see what we get. I'll open up a terminal window and type in yo meanjs:express-controller, and we'll name the controller, email. You know, while we're here in the terminal window, we're also going to need a route to this new express API controller, so we might as well take care of that as well. To spin that up, let's enter in yo meanjs:express-route, and we'll name this route, email, as well. Let's open up our new route and see what we have there. Well, it's just a basic stub, so we need to fix this up a little, and have it point to our new email controller. We'll open up that controller in a second, and when we do, we'll want to expose a create function to create and send email messages with. Here's what that will look like. All right, a new email server-side control file was stubbed in for us by the Yo Generator earlier, so let's open that up now and take a look. Well, thanks, but not exactly what we need here. While that was a nice review of using the MEAN.JS sub-generators, we do not need create, read, update, and delete functionality here. What we do need is to be able to send emails using the SendGrid service, however. Let's remove all of this code, and paste in some code that was derived off of the SendGrid documentation that we looked at a moment ago. That's more like it and should get us what we need now. Keep in mind that you too can sign up for a free SendGrid account, so don't try using this one later. I've already change the password. So that's our API endpoint controller, and we're exporting create here but what we'll use this function. The sign-up form is on our view need page, so let's open that up again and take another look at that. In the previous video, we just pasted this HTML code in and then viewed the results of that. Now it's time to dig in a little deeper We can see here that NG-submit is calling the sign-up function and passing in a need object. If you recall, that need object was attached to our angular $scope. We will need to add that to the angular controller that this view is referencing here in a moment. Next, we can see that our various input fields are bound to sign-up data. But where is the sign-up data object coming from? Let's open up the angular controller and take a look there. Sign-up data was added to $scope, up here in the find function, while you were not looking, and also so that I could get the previous demo to run. All right, down here, below find one, let's tag onto $scope, the sign-up function our view needs. $HTTP.post is what we're using here to call into our API endpoint. That fires off the SendGrid service by hitting the email route we set up earlier. You can see here that an object with properties of name, email, and message are being passed over to that service. One important step to not overlook here is that we need to add $HTTP to the list of angular dependencies so that it can inject those for us. Let's scroll up to the top here, and add in $HTTP to the dependency list. If we open the server-side email controller file back up, you can see where the values from the HTTP request are being consumed here, off of the request.body object. For example, the from email address and the message body text. Okay, we should be in pretty good shape now to make an initial test run at sending an email message through the SendGrid service from our application. For now we're just logging the results out to the console, but it would certainly be a good idea to notify the end-user of success or failure, and to also clear the sign-up form upon success. Let's fire up Node.JS by using our default grunt task runner and see what we get now. But before we run grunt, real quick, let's make sure we have the SendGrid node package installed by entering NPM install send grid --save. That may take a second or two to install. And now we're good to go with our grunt task to kick off our site. Just in way of reminder here, I still have my local instance of MongoDB running. Let's get logged in here using our demo account and the password, and select a sample volunteer need. And we'll try to sign up for this need now, filling in some dummy data into the sign-up form just to make sure everything is wired up correctly. I'll press Submit and then move back over to the command line interface to see what our console is telling us. Great, we get a response code of 200, and we can also see our email response object here, too. Let's log into the demo email account this message was sent to, and see if that was successful as well. Sure enough, there is the message to the administrator. I think we're in pretty good shape here. The main purpose of this video was not to teach about SendGrid per se, but more to show that you're free to swap out whatever pieces of the MEAN.JS framework that you do not want to use, or add in completely new libraries as your needs dictate.
We started this module off by examining where in the MEAN.JS application structure our new CSS and HTML files are needed to be placed in order to style our application with the downloaded Bootstrap Solid theme. We then fixed up our mongoose schema and model from the schema so that we can begin creating and displaying volunteer needs. Next, we created the new controllers and views to create and list out volunteer needs, as well as a form to allow site users to sign up for a particular need, and we accomplished that by adding in the SendGrid service. We closed off this module by exploring some of the tests generated for us by the MEAN.JS Yo sub generators, both server-side express controller and route test, and client-side angular tests. In the next module, we will go through the steps of actually running our test and learn about getting our site ready for deployment by going through the build process.
Testing, Deployment, and Tools
Welcome to this module on testing, deployment, and additional useful tools. My name is Mark Scott. In the previous module, we built upon the base scaffolded site that was given to us by the MEAN.JS Yo Generator, and concluded the module by exploring some of the unit tests built for us by the generator. In this module, we will pick back up where we left off and run those tests, and then move on to discuss build and deployment steps. We'll wrap this module up by exploring some additional useful tools, so let's get started.
Build and Deployment
Additional Helpful Tools
Tools are a wonderful thing. The right tool can save you many hours and a lot of frustration. We could spend a lot of time talking about hundreds, no, probably like thousands of useful MPM packages out there, but we'll not do that. Instead let's narrow this down to code editors, deployment tools, and database tools. Please keep in mind, I do not work for any of the companies that offer either free or paid versions of the products that will be mentioned here in this section. The only goal here is to expose you to some tools that you too may find useful, and nothing more. As far as code editors go, Web Storm is a pretty great tool, and that's been used throughout this course. However, there are a number of really good editors available, and new ones coming on the market. Let's get started with a quick run through of some of the alternative code editors now. First up is a newbie to the field, Visual Studio Code. In fact, it's still in preview. On the home page, code.visualstudio.com, you'll find a quick introduction video. Take a look at it, you'll probably like what you see there. Visual Studio Code is a fast-loading, easy to use, minimalistic yet powerful editor. Visual Studio Code is available for free on Linux, Mac OSX, and Windows. Next up we find the Brackets editor, supported by Adobe. It can be found at brackets.io. It is a lightweight, quick-loading editor that offers a number of extensions such as Git source control integration, code beautification, code linting, and many more. Brackets is also a free, cross-platform editor that is available on Mac OSX, Windows, and Linux. Chances are pretty good that you've already heard about this one. In fact, if you ask me, the previous two editors we looked at seemed to have taken some lessons from Sublime Text. Version two is still the official version, but version three has been available for a long time now in beta, and seems pretty stable to me. Sublime Text, like Brackets and Visual Studio Code, is available on Windows, OSX, and Linux. However, while you still can use it for an extended period of time for free, it's not really free. The price for a Sublime Text license key has increased from its original price of $59 to $70. At this point, you may want to first consider either Visual Studio Code or Brackets. Now let's shift gears and talk about deployment tools. The first one up here is Flightplan, which is a very interesting and useful Node.js library that you may want to research further on your own. It is used for automating and streamlining application deployments and even system administration tasks. You can find more information Flightplan on Git Hub at github.com/pstadler/flightplan. As you will see there, an MPM package is also available for it, so take a look. If you're looking for something a little more polished and full-featured, you may want to look into CodeShip. With the limited research I've done thus far on CodeShip, I'm very impressed. If you're looking for a good continuous delivery tool, you should at least take a look at CodeShip. It's not free, but if you need a robust, customizable continuous delivery tool, it may be worth the monthly subscription fee to you. They have really good documentation and tutorials on their site, and for me, a lot of times, that's a deal breaker or maker. And the last group of tools in the list are database tools. And since we're talking about the MEAN stack, that would of course be for MongoDB. At the 3T Software Labs website, which is 3t.io, you'll find a suite of rather nice MongoDB tools. Those are shown here on their products page. The first one in the list is MongoChef. If you want a graphical user interface to view and interact with your MongoDB data, then look no further. If you're currently using RoboMongo, which is also a great tool by the way, you owe it to yourself to at least download this tool and give it a try. If you're familiar with, and in particular if you have used Red Gate tools for Sequel Server, specifically their data comparison and syncing tool, the 3T Data Compare and Sync for MongoDB is that same type of tool, and in my opinion, a must have. This tool makes it painlessly easy to compare different MongoDB databases. And the third tool in their suite is the 3T Schema Explorer. Any time you want to deep dive into a complex MongoDB document schema, this is the tool you'll probably want to reach for. All three tools have free trials, and MongoChef is free for personal, non-commercial use. The Schema Explorer and Data Compare Sync tools require you to purchase them after the trial period is over.
In this summary, we could go back over the various topics that were discussed in this module of the course, but if you will allow me to, please let me take this time to re-empahsize the importance of testing your code, especially prior to releasing it out into the wild. Unless you're not concerned about this happening to one of your customers while they're using your site. The MEAN.JS Yo sub-generator stuck in some pretty nice, useful tests for us right out of the box. But as we've seen here, you will need to adjust them to fit your specific needs. I hope you've enjoyed this video on testing, deployment, and tools. If you have a favorite cloud platform as a service provider, or a really awesome tool you can't live without, please feel free to share that information on the comments section of this course.
Welcome to the wrap up module. My name is Mark Scott. We started this course off by briefly discussing what the MEAN stack is and how it came to be. We then explored the origins of MEAN.JS and talked about why you may wish to use a Boilerplate framework rather than starting from scratch. A general comparison of some of the other MEAN stacks that are available was done and we concluded that MEAN.JS was the un-opinionated choice. In the module on getting set up, we covered the course prerequisites and installed the various libraries needed to scaffold out the demo full stack Boilerplate application using the MEAN.JS yo generator. We then took a tour of the scaffolded code in order to gain a better understanding of the Boilerplate application's structure and discussed how things are laid out and where to find key parts of your application. We moved on from there to cover application configuration issues. Things such as the connection string to MongoDB for example. The last part of the tour the scaffold site module was spent taking a quick look at the 0.4.0 version of MEAN.JS. We did some comparisons between the current version, 0.3.3, and 0.4.0. In the module on cogeneration, we learned about the Yeoman project and, in particular, the yo web application scaffolding tool that was used in the getting set up module. A number of MEAN.JS sub-generators were discussed and demonstrated as well. Once things were pretty well laid out, we moved onto the module on taking our generated code from scaffold to application. This is where we replaced the Bootstrap theme provided to us by MEAN.JS with one named Solid, which we downloaded for free. We then built out a new Mongoose scheme and model based on the business needs for our volunteer needs demo application. Once we had our volunteer needs model in good shape, we moved on to developing the server and client site controllers and the angular views. That module was concluded by exploring the various tests that the MEAN.JS yo cred sub-generator built for us. We made some adjustments to those tests as needed. Once we looked over the generated test in the module on testing deployment and tools, we ran the unit test we adjusted to match our business needs using the grunt test task. The ever-so-important build and deployment steps were also discussed and demonstrated. We concluded the module by exploring some useful tools. I hope that you have enjoyed this introduction to MEAN.JS course.
Mark Scott is an experienced software developer with more than fifteen years experience in IT. He is currently the Manager of Software Development for a small group of talented web developers.
Released5 Jun 2015