Meteor Developments: Worlds Inside Worlds

I’m looking more carefully at Meteor development. Again, Meteor is a fullstack NodeJS framework. While there are many many options and packages within Meteor, the framework seems more rigid than some other frameworks. That might be good or ill, but we’ll find that out later. I certainly don’t have the expertise to take advantage of tremendous flexibility which is more likely to confound than help me.

In general, you can create pretty involved web apps with meteor with just a few lines. These three files are a decently-featured, authenticated, persistent, MVC ToDo list app.

wmodes$ ls -l simple-todos/
-rw-r--r-- 1 wmodes staff 1745 Jan 17 20:40 simple-todos.css
-rw-r--r-- 1 wmodes staff 1077 Jan 17 21:52 simple-todos.html
-rw-r--r-- 1 wmodes staff 3271 Jan 17 21:52 simple-todos.js

I created this with the Meteor tutorial.

File Structure

However, a more involved app would have additional installed packages, libraries, separated templates, client files, server files, and public files such as images and so on.  The simple question of how I might arrange the internal directories of a simple barebones Meteor app revealed worlds within worlds.

Just looking at boilerplates for Meteor left me overwhelmed. Three good ones I found were

I also found this helpful Unofficial FAQ that suggests a Meteor file structure significantly different from the above boilerplates:

## Note that js files in lib folders are loaded before other js files.
lib/                       # <- any common code for client/server.
lib/environment.js         # <- general configuration
lib/methods.js             # <- Meteor.method definitions
lib/external               # <- common code from someone else
collections/               # <- definitions of collections and methods on them
client/lib                 # <- client specific libraries (also loaded first)
client/lib/environment.js  # <- configuration of any client side packages
client/lib/helpers         # <- any helpers (handlebars etc) used often in view files
client/application.js      # <- subscriptions, basic Meteor.startup code.
client/index.html          # <- toplevel html
client/index.js            # <- and its JS
client/views/<page>.html   # <- the templates specific to a single page
client/views/<page>.js     # <- and the JS to hook it up
client/views/<type>/       # <- if you find you have a lot of views of the same object type
client/stylesheets/        # <- css / styl / less files
server/publications.js     # <- Meteor.publish definitions
server/lib/environment.js  # <- configuration of server side packages
public/                    # <- static files, such as images, that are served directly.
tests/                     # <- unit test files (won't be loaded on client or server)

I found that the examples created by the Meteor Kitchen code generator were closest to this suggested file structure. But it is just one of many many confused and conflicting structures.

In fact, this useful article, “In Search of a Meteor Boilerplate,” which compares numerous boilerplates and code generators (including the ones above) wails about this lack of structural guidance. “Although it can be argued the merits of one file structure over another, I really doubt there’s such a great advantage either way, and we just need to shit or get off the pot.” The author does a side-by-side comparison of a shit-ton of boilerplate directory structures:



As for directory structure, I guess I will just pick one that seems sensible to me.


But what was overwhelming about the boilerplates was not the file structures, but the number and wide range of packages included with the boilerplates.  Here are the included packages from just two of them.

Included Packages in meteor-boilerplate by matteodem

Included Packages in meteor-boilerplate by BeDifferential

As you can see, if you start clicking on these packages that each developer considers fundamental, you see there is a universe of things to know about each. (I’m still not even sure what “collections” is.) And for the one on the left, the github page suggests you install the “orion-cli tool” which is used to create a new boilerplate installation. Ack, I’m still getting used to NodeJS’ npm installer and Meteor’s “meteor add” command.

Many of these seem pretty useful. Do I learn all of these and decide which ones are going to be essential to me, or do I Eyes-On-The-Prize and concentrate on the features I want to implement?

Okay, for now, I am just going to install packages as I need them.




Leave a Reply