Meteor Structure

          index.js                      # import client startup through a single index entity
          routes.js                     # set up all routes in the app
          useraccounts-configuration.js # configure login templates
          fixtures.js                   # fill the DB with example data on startup
          index.js                      # import server startup through a single index entity
        lists/                          # a unit of domain logic
            publications.js             # all list-related publications
            publications.test.js        # tests for the lists publications
          lists.js                      # definition of the Lists collection
          lists.tests.js                # tests for the behavior of that collection
          methods.js                    # methods related to lists
          methods.tests.js              # tests for those methods
        components/                     # all reusable components in the application
                                        # can be split by domain if there are many
        layouts/                        # wrapper components for behavior and visuals
        pages/                          # entry points for rendering used by the router
      main.js                           # client entry point, import all client code
      main.js                           # server entry point, import all server code

    Taken from Meteor Structure

    Inside imports is where we store all units of functionality for the HTML5 client.

    Inside API is where we store the collection data that we use, sort of like a model.

    Inside UI is where we store what would be the view for the models.


    Located under /imports/api

    Each sub-directory here will either be a data collection, or some service we use in the client.

    The name of the subdirectory should be in lower-case representing the name of the Mongo collection, or following typical programming collection it will be PascalCased representing a class name.

    Differing from the Meteor Structure is that for security purposes we want the majority of our functionality in the /server directory, which keeps it from loading on the clients.

    The main export or class for the API component should be in index.js, which allows for easy importing. So to import the Polling collection for example, we can use the following code import Polls from 'imports/api/polls/'.

    Since it is index.js we don’t have to specify that file since it is default.

    Naming files this way can conflict with certain conventions where the file name is named after the main class inside it. To go about this we simply have a default export for the collections, and in the case of a collection we export the new instance.

    Inside the /server directory of every API component we have a named file named publications.js. This is where we put the Meteor publish callback for the collection.

    We now have 2 more sub-directories inside the /server directory– methods and modifiers.


    Inside /methods we have one file per method. These methods are where we declare the Meteor.Methods for the collection– which are Meteor server methods that can be invoked from the Meteor client. We have one file per method, and they are named in camelCase. They shouldn’t need an export because of how they are registered in Meteor. They will however have to be imported on the server (at startup) to execute the code.


    Inside /modifiers we have one file per method. These functions that go in here include the functions that modify the collection/data/class, from the server side. We have one file per method, and they are named in camelCase. There should be one export per file. And these will be imported wherever needed. These are almost all functions that will be called from Redis message listeners.


    Inside imports/api/<collection>/server/ we have a file called eventHandlers.js. This file will contain all the event handlers for the collection.


    Inside /ui we will have sub-directories for

    • components

    • services

    • stylesheets


    will have /api/index.js. Which is where we will store client-side-wide services and helpers. The functions and data in here will all be exported on the last line of the file in one export statement. This allows someone to just look at the last line of the file and easily see what the file exports.


    Inside this directory each sub-directory will represent a React Component. The name of the sub-directory is what the name of the component is. They are all lowercase, with dashes (-) between words. The standard file are

    • component.jsx

    • container.jsx

    • service.js

    • styles.scss


    -> /whiteboard

       -> component.jsx

       -> service.js

       -> container.js

       -> /slide/component.jsx

       -> /cursor/component.jsx

       -> /shape-factory/component.jsx

       -> /shapes

           -> /ellipse/component.jsx

           -> /triangle/component.jsx

           -> … <the rest of the shape components>


    All components will be React ES6 style classes (not React Classes). A component should only need to have one export and it should be the default export. Refer to the official React documentation on how to structure a component class. The component file will be named component.jsx.



    A container is a React ES6 class that will pass data to the component. The container will also be in control of whether or not the component should render. A container should retrieve data from the service and pass it into the container class.

    The container file will be named container.jsx. The file should have only one export and should be the default export. The export should be the result of the createContainer() function.


    The service file should be named service.js.

    The file can export as many function, objects, or other pieces of data as it needs. The service can interface with other collections as well. There should only be one export statement in the file. The last line of the file should export all the functions and pieces of data in an object. Restrain from wrapping everything inside a function and exporting the function wrapper.


    All styles should be written in SASS when possible.


    All configuration files are located in sub-directories within /private/config. The file configuration method utilizes .yaml notated file types.

    Default configuration files:


    The default configuration can be overloaded and their values changed based on the selected environment. These overloaded configuration files are located in sub-folders with their corresponding environment name.

    Development overload configuration files:


    Production overload configuration files:


    During Meteor.startup() the configuration files are loaded and can be accessed through the Meteor.settings.public object.

    As an example of it’s usage we can do:

    import { Meteor } from 'meteor/meteor';
    const APP_CONFIG =;
    if (APP_CONFIG.httpsConnection){
      baseConnection += ('S');