Overview of the MEAN Stack App Structure Day 1

This video is part of the 30 Day MEAN Stack Honolulu Challenge

We’ll go through an overview of the key files and folders in the MEAN App Structure.

Transcript for the Video

Hi guys and welcome to what I’m calling the 30 Day MEAN Stack Honolulu Challenge.

The Challenge

I’ve set myself a challenge for the next 30 days. To go through the MEAN Stack that we’ve created and actually turn that into a functioning app. The idea will be that I’ll post everyday for the next 30 days, keep it nice and short, under 10-15 minutes and you can take everything that we do and include it in your own app.

Alright, so let’s get right into it, in the first video that I did, I went through and actually installed the mean stack, and that’s what I’ve got open in front of me here.

One of the things that we had to do as part of the installation process was get the database set up, that was the MongoDB that we set up using Compose.io to actually get that up and hosted.

A couple of things for this particular video that I’m going to show you are things like: What is the mean stack? What are the different folders? What do they mean and why do they exist in that way?

We see that we have 4 folders. 4 high level, definitive folders as part of the stack, and then we’ve got a whole heap of random files that are sitting in here. I’m not going to go through all of them, but I will talk about a few important ones.

The package.json file

We’ll start off with package.json. If you’re familiar with Node, and any Node related projects, they all have this package.json file. I mentioned when we were going through the installation process that the name of the app and the description will end up here. These are the details that we put in and selected when we were going through the Yeoman generator setup process for the stack.

Things like the name, the description, the author they came in through the pre-population process.

We’ve got versions of Node and NPM, and these were what we used when we installed the stack. The scripts are things that happen when you actually start the app, or things that happen when you’ve completed the installation process, such as postinstall. Don’t worry too much about those, you can leave them pretty much as they are.

The key things I want to draw your attention to in the package.json file are things that live under the dependencies and the devDependencies sections.

The dependencies are all the packages that npm has gone through and installed when we actually set up the mean stack. We’ve got things like Express, so that’s our middleware and that’s set up as part of the installation process.

We’ve got things like Passport. Passport is the authentication mechanism that we’re using as part of the mean stack.

We’ve got things in here like Forever. Forever is the package that keeps your app up and running. So, if Node died for some reason, it would restart it, and get it back up and running.

What we’ve got down the bottom here is devDependencies, So, dependencies are the packages that are used by the app and the numbers next to them represent the version, the latest version of the dependency that your app uses.

devDependencies are additional packages that are actually used in order to use your app when you’re developing it. Things like Grunt and Karma.

Karma’s used for testing. For the test scripts that you write and you run as part of your app.

Grunt helps you in the development process by validating and minimising parts of your application for you as you’re developing.

So, why is this process important? The reason that these dependencies and these devDependencies are important is because these are the things that your app uses to work and to run, and without these, there is probably something that would break and it wouldn’t quite work.

When you need to add additional packages to your app, you’ll usually add them in here as well.

The things that are defined here, all these dependencies and devDependencies they’re installed somewhere in your app. The place that they’re installed are in this folder here called node_modules.

Everything in this folder coincides with a package in your package.json file. That’s very much a Node standard to have this node_modules folder, and you’ll see that in almost every Node project that you come across.

To show you some examples, if we look at these Grunt dependencies here, there are a whole heap of Grunt packages here. They will all coincide.

There may be in some instances, where more packages are installed in your app than what you’ve defined, the reason for that is that each package that’s defined here has it’s own package.json file and it’s own set of dependencies.

There may be times in your app where you actually have a package installed more than once because it’s used by different packages, if that makes sense.

The Karma and the Grunt files

Moving on up, that was the package.json file. The Karma and the Grunt files are used for testing configurations, Grunt is used for identifying the tasks that we want Grunt to run, when we run it.

We talked about in the first video, when we wanted to run our app, we just typed in the word ‘Grunt’, and it would go through and run a whole heap of different tasks. There’s a lot going on here, but it’s actually not that complex.

The bower.json file

The next one I’m going to look at is this bower.json file. I mentioned in the last video that Bower is another package manager, we have two key ones. We use NPM, which is Node’s package manager for the server side related packages. We use Bower to manage our client side packages.

We’ve got Bootstrap and we’ve got all of our Angular modules. This isn’t the full set of Angular modules, there are more than that. But these are definitely the key ones to get us up and running.

You may want to know where these packages are actually installed, they’re not in the node_modules, that’s just for the package.json file. We can tell bower where we want the packages to be installed. That’s done using this .bowerrc file, so in this file here, we actually point to the directory where we want to install the Bower files.

If we go to public > lib, we’ll see that the files that had defined here in the bower.json file, are installed in the library here.

The .jshintrc file

Lets see what else we’ve got here. We’ve got a couple of files around .jshintrc, so these are configuration files for things that you want to, things that you want to provide hints for as you’re writing your code.

It’s used to try and keep your code consistent. If you’ve got a lot of different developers working on the code, everyone’s using the same consistent formats.

The .gitignore file

.gitignore, these are the files or the folders that you want Git to ignore. Git’s the source control tool.

The Public Folder

Moving on, I won’t go through each of these folders, but I will just tell you a little bit about what’s behind them. So in the public folder is all of your Angular specific code lives here.

This is all about what happens on the client, on the computer itself, so all the Angular stuff will live in here.

The Config Folder

The config folder, this includes your connections to MongoDB, if you’re running any APIs, it’s really about your configurations for your app, primarily it’s server side configurations.

The App Folder

Then you’ve got at the top here the app itself. Not to be confused with the public folder. Public is all about your Angular, your client side related code.

App is all about your server side related code, and that’s split into that MVC model with your model, views and controllers. These are all the things that happen on the server side.

So you don’t have a lot of view here, for example you’ve got 404, 500, error related views, and these are the types of things that live, they are overarching, they live outside of your Angular app. So they surround it and package it.

We will have a look at these in more detail in another video.

The idea of this video was really just to give you a really, really quick introduction to the structure of the app, and what we’ve got, just again to reiterate:

The Summary

App folder is all your server side code, it’s got your models on there, we’re using Mongoose as our model structure – to talk to MongoDB. We’ll have a look at that in more detail.

We’ve got config which is all our configuration related data, our connection strings, and things like that. That’s primarily used for your server side code.

We’ve got node_modules, and they’re installed based on the packages that you identify in your package.json file.

Lastly, where the guts of the app lives is in this public folder, and that’s where we’ll be putting all of our Angular services and controllers and views, and making our Angular magic work.

So, I will leave you there for today, and I’ll pick it up again tomorrow, where we’ll actually start building out parts of the app.

Thanks for joining me, please subscribe to the YouTube channel or check out www.bossable.com for more details.

Thanks again!