Package based architecture for a Meteor application

5 months ago we launched the first version of our webapp Ayni, our code-base grew since then and is now pretty complex.

To keep the complexity under control, We are using a package-based architecture, greatly inspired by the open-source Telescope app, built with Meteor.

As I will be joined soon by new developers, some that don't know anything about Meteor, I felt like I could need to write a wiki/doc for them, and ended up writing it here : I figured out I would have to be crystal clear if this was public,

So here it is : Ayni's Package based architecture

Every feature inside the app is a package, and every package follow the same architecture :

  • Package
    • lib
      • both
        • collections
        • modules
      • client
        • templates
        • stylesheets
        • modules
      • server
        • methods
        • modules
        • permissions
        • publications
    • tests
      • client
      • server
    • package.js

Explanations :

  • We used to have a 'i18n' folder for internationalized strings, but we ended up putting the strings in one Json at the top-project level, rather than divided into differents packages

  • The collections folder contains the model layer of the app, written using simple-schema package

  • We are using Tinytest for the unit tests, It's pretty minimal but quite useful.

  • The modules directory contains the definitions for the package global, with the Client/server/both code depending on the package

  • Methods are never called directly from templates, we rather use modules global

Ex : Messages.insert() rather than Meteor.call('Messages.insert')

  • For each package, we try to export only one global.

  • Methods name follow the following naming conventions :
    'Todos.methods.updateText'

Privacy Policy