× {{alert.msg}} Never ask again
Receive New Tutorials
GET IT FREE

How to Structure a Meteor Application: 3 Things You Should Know

– {{showDate(postTime)}}

This Meteor tutorial will teach you how to structure you application to keep it organized. The article was originally posted at David Turnbull’s blog.


 

In this tutorial, we’ll cover the basics of how to structure an application. You won’t learn everything there is to know but you will have an easier time:

  1. Keeping your files and folders organised in a logical manner.
  2. Navigating the source code of other developer’s projects on GitHub.

I’ll include some links at the end of the post if you want to dive deeper.

1. There Are No (Strict) Rules

Meteor doesn’t enforce any style of structuring your files and folders. If you have experience with Rails, you’d know a thing or two about the Model-View-Controller approach, but Meteor doesn’t actively encourage anything similar.

There are some things to keep in mind, which is what we’ll cover through the rest of the article, but in general:

  1. Every project will differ based on that project’s needs.
  2. You have total flexibility based on the way you like to work.

But if you’re not careful, this freedom of choice can cause problems. Your projects may become difficult to manage. Therefore, it’s a good idea to:

  1. Start projects with the fewest possible files and folders, then let them grow organically. Don’t create some intricate structure unless you precisely know what you’re doing. Less is more, etc.
  2. Take inspiration from other people’s projects. Look at open-source projects on GitHub and pay attention to structural decisions made in books, tutorials, and screencasts. You can learn something from everyone.
  3. Be flexible. There’s no use in setting any decisions in stone. You may have certain preferences but let those preferences bend as Meteor changes and as you become a more proficient developer.

Personally, I prefer having the freedom to work how I want to work — as a beginner, it means you don’t have to think too much about structure when just playing around — but don’t let that freedom get the better of you.

2. Certain Folders Have Certain Meanings

As I’ve covered before, code in a Meteor project runs on the client (in the user’s web browser) and on the server (when the project is hosted) by default. This is a core part of Meteor’s “magic” but we have to be careful because:

  1. Not all code is meant to run in both places.
  2. When we try to run code where it shouldn’t run, we’ll get an error.

The simple fix for this is to use an isClient conditional:

if(Meteor.isClient){
    // This code will only run on the client
}

Or an isServer conditional:

if(Meteor.isServer){
    // This code will only run on the server
}

But for larger projects, it’s not elegant to use these conditionals over and over again. We don’t have to though since Meteor provides a simple convention:

  • All files in a client folder will only run on the client.
  • All files in a server folder will only run on the server.

So, for example, since your helpers and events only need to run on the client, you could include them in a JavaScript file (or across multiple files) within the client folder. Then you’ll no longer need to use the isClient conditional.

There are also a few other conventions to keep in mind:

  • All files in a private folder will only be accessible to code running on the server (either in the server folder or in an isServer conditional).
  • Alternatively, the public folder is where you place public-facing files like images, favicons, and a robots.txt file.
  • Anything in a lib folder will load before all other files in a project. (I’ll talk more about the load order of files in another tutorial.)

If this feels like a lot to remember, now you know why I choose not to cover it during beginner tutorials. None of this is particularly difficult but it is more to juggle in your head, so it wouldn’t be strange if you found it overwhelming.

For the moment, just remember that:

  1. Certain folders have certain meanings attached to them.
  2. You don’t have to use these folders (but they are convenient).

The details will start to stick when you need them to but, until then, you can continue to work the way I’ve outlined in the other tutorials.

3. You Can Spread Your Project Thin

In general, it’s not a good idea to stuff as much code as possible into a single file. You want to keep files relatively “skinny” so they’re easier to navigate (and so unrelated code isn’t simply mashed together into one hellish mess).

Meteor makes this easy since you can spread your project as thin as you want.

You could, for instance, create a templates folder inside a client folder, and have a blog_post.html file that contains the following template:

"myBlogPostTemplate">
</template>

You could then reference this template in any other HTML file:

{{> myBlogPostTemplate}}

That’s not to say it’s always a good idea to have a separate HTML file for every template that you create, but if your templates are particularly “heavy,” then it might be the best way to work.

This applies to everything in a project though — events, helpers, collections, etc — and not just templates, so you might like to:

  • Create a collections folder with a separate file for each collection. Just make sure this folder sits outside the client and server folder.
  • Create a router.js file in the lib folder to store your project’s routes. If you don’t know what “routes” are, I’ll be covering them in another tutorial.
  • Create a helpers and a templates folder inside the client folder as any decent-sized project will have a lot of templates (and even more helpers).

But these are just ideas. There are no rules and, again, I suggest starting with as few files and folders as possible and letting a project grow based on its needs.

Conclusion

I thought about making this The Complete Beginner’s Guide to Structuring a Meteor Application but, honestly, I don’t think beginners need to know every detail about the “proper” structure of an application.

For now, it just helps to know enough that you’re not caught off-guard by other people’s code and that there is a (somewhat flexible) science to good structure.

If you crave this sort of theory though, feel free to read:

David Turnbull is the author of “Your First Meteor Application” and the founder of Meteor Tips.




Questions about this tutorial?  Get Live 1:1 help from Meteor experts!
John Kennedy
John Kennedy
5.0
Full Stack Engineer
Full stack engineer with experience writing clean, testable and efficient code. My interests include **C#**, **JavaScript**, **Python**, **Swift**,...
Hire this Expert
James Collin
James Collin
5.0
R, Data Science | Senior Full Stack| Node.JS, Django, PHP | React, Next | Matlab|Scraping Expert | Three.JS | Wordpress | Algorithmic Trader
I am 2010 graduate batch from Michigan State University with Bachelors degree in Mathematics. From then I have worked with a breadth of companies...
Hire this Expert
comments powered by Disqus