I am expecting my application to become quite big eventually, so I am trying to set-up an architecture that can keep up with its growth from the very beginning. Yet, I am struggling to get this done in a really satisfactory way.
I am already using packages to modularize every function group into a separate modules. This kind of works, but of course there are some interdepencencies between these groups, and I find it quite hard to manage these without turning the whole thing into some kind of spaghetti code.
Here are just two samples to explain what I mean:
-
I am using SCSS (fourseven:scss) and Bootstrap throughout the application. So I have defined a central Bootstrap theme that sets SCSS variables, e.g. for the brand colors of my application. Of course, the functional groups (packages) of my application depend on these central variables. But I did not manage to set-up this without hard-include the package SCSS files into my central application (details here: https://github.com/fourseven/meteor-scss/issues/104). This may be an issue with fourseven:scss (and may be solvable with the new build process that will be available with Meteor 1.2), but thatās just a sample for a situation where some kind of bridging functionality in the Meteor core would help a lot to keep things clean.
-
Regarding namespacing: Nearly all public packages export their own objects to the global namespace. I think this is OK for larger packages or core functionality (like FlowRouter), but for my much smaller application-specific modules I donāt really want to pollute the global namespace that much. Hence, I am using a global āAppMainā object which is defined in one core package all other packages depend on, and then add my package-specific exports to this variable. This works, but in the end this also causes interdependencies I would like to avoid. It would help a lot if it was possible to map package exports to the application-specific namespace instead.
I do not expect anybody to post solutions to these specific problems here, as they should only serve as some examples. Instead, I would be happy if anybody could point me to guides / tutorials / blogs by people who already set-up really complex Meteor applications (i.e. beyond the simple projects included in the Meteor tutorials). The only tutorial I found so far on this topic recommended not to use packages that much; I donāt think this advice will bring me far.
(BTW: I already had a closer look at Telescope. This was the only larger application I found that was available as OpenSource. The structure of Telescope is quite nice and clear, but it is rahter tailored to one specific app. I am looking for an architecture that allows my modules to be easily exchanged across applications.)