Recreating the travel booking application

Create a new MeteorJS application using the iron create BookMyTravel2 command. Remove the autopublish and insecure packages using the iron remove <package name> command. Visit the directories and files created inside the BookMyTravel2 directory. As I said, iron-cli wraps the MeteorJS app inside itself and in this case, it is the app directory. The app directory is the actual MeteorJS app. If you want to run any MeteorJS-specific commands, you have to go into the app directory and run the commands. Both the mongo database and the .meteor directory reside inside the app directory. The unfortunate thing is that this scaffolding is tightly coupled to iron-router. We have to do some rework if we wish to use any other routing solution such as FlowRouter. However, this is not a big deal if you know what to change and where to change. For now, let' stay on track and build the application with iron-router itself.

Run the iron run command in the terminal and it will start the application. If you watch the directories and files created, you will find that the home page-related scaffolding has been done already. Route, controller, action, layout, and the template for home are created in different directories. Let's get familiar with those directories. You can ignore the .iron directory.

At the root level of the application, there are the app, bin, build and config directories. The app directory is the developer's concern. The bin and build directories are for iron-cli's internal work; and the config directory is where we can define environmental variables and other platform settings.

The app directory

The app directory has sub-directories and files where we do the real coding. We can find sub-directories such as client, lib, packages, private, public, and server, inside the app directory.

Client

As you know, the client directory is where we do the client-side stuff. The client directory has the collections, lib, stylesheets, and templates directory. You can make out for yourself what these directories are meant for. Inside the template directory, there is a home directory where the home template, home template handlers, and CSS are present. You will see the skeletons inside those files. Similarly, the layouts directory has master_layout that has a master layout template and its handlers. We can create various templates inside this layouts directory and use them in the application. It is well organized, so anyone who searches for layouts will just have to look into this directory. The shared directory has a loading template and a notFound template. We can keep any template or a related piece of code that can be shared across the application inside this directory.

lib

The files under this section will be run both in the server and the client. The iron-cli creates the collections and controllers directory here. When we use iron-cli to generate collections, it will create collections inside the collections directory under lib. The controllers directory will have to hold all the generated controllers. These controllers are extended from RouterController, which is a part of iron-router. These controllers are invoked from the router handlers. Inside the controllers directory, we can see that home_controller.js is already created for us by the iron-cli. If you look at it, you can understand for yourself as to what is going on. The routes.js file is connected to the controllers. In each route, we can specify which method of which controller to invoke when the route is visited. As per the routes.js file and the home route, when one hits localhost:3000/, it will call the action method in HomeController. Before the action executes, the subscriptions method will be invoked. Finally, methods.js is the file where we can define methods that can be used both in the server and the client.

Private and public packages

The packages directory is for the custom packages that we create for our application. We will cover this in greater detail in an upcoming chapter. The private directory is an asset directory for the server and the public directory is an asset directory for the client.

Server

Here, we have the collections, controllers, and lib directories. Server-only collections will reside in collections, server-only controllers will be in controllers, and other code can live in the lib directory. The bootstrap.js file has a hook for the startup callback. If some code needs to be executed during the application startup, we can put it inside this file. The methods.js file is where we put all server-only methods. Finally, the publish.js file is where we put all the publish registration-related code.

Now, we are familiar with the directory structure that iron-cli has created for us. The last thing that we need to know to kick-start scaffolding is generators. The iron-cli provides generators with which we can create skeleton code for our application anytime. The following are the generators that are available:

iron g:scaffold <entity>
iron g:template <optional-directory/template>
iron g:controller <optional-directory/controller-name> --where "<server/client>"
iron g:route <route name>
iron g:collection <collection name>
iron g:publish <publication name>
iron g:stylesheet <stylesheet name>

The iron g:scaffold command will generate collection, templates, handlers, controller, route, and publication. If you wish to do it in a customized manner, you can use other commands to generate specific components. For example, in our application, we need to create a collection called reservations, but we don't need the controller, route, and templates for that collection. So, we can just use the iron g:collection reservations command that only creates a collection inside lib/collections.