Me and my team are building a large meteor app for our organisation. Realtime, lots of data, many users. We started Meteor’s old way of structuring a while ago (no other choice). This was basically a package based approach.
We are progressing gradually into meteor’s proposed way of structuring apps as described in the guide. For us this already is really beneficial in terms of not having to re-invent the wheel and also we have more control over the load order and it drastically improved the application’s performance.
One of the things I’ve learned is to only use realtime reactivity where it is actually needed. In Meteor it is very easy to make everything reactive, but all great magic comes at a cost. Take a chat-app: For a list of profile-pictures that changes maybe once a month, use the return of a method call to get the list of your pictures once at page-load. And for the actual chat messages, use pub/sub reactivity. The fewer reactive parts, the snappier they will be.
I have been using React front end (inc. React Router), mobx as state manager on front end, and Meteor for data management, with Mongo as database. I now reuse this basic pattern on any new apps as it means I can implement an app very quickly. You can see the architecture here:
The package based architecture is actually very good, and still highly relevant. It helps you make your application very modular, and easy to update or split into services later (https://github.com/TelescopeJS/Telescope/tree/master/packages). There’s nothing stopping you from adapting it slightly, to take advantage of imports, or using ES6 Modules instead of Meteor packages.
Once you go the package architecture route and your app size increases it will become difficult to move to an architecture using /imports.
The package architecture works very nice, but tooling is horrible. Package imports aren’t recognized by your ide or eslint or other awesome stuff like walibyjs. It’s just not supported outside of Meteor. So I have a love/hate relationship with Meteor packages
With some discipline you can create nice isolated packages within /imports, but because Meteor won’t force you in that scenario it’s easier to make a mess.
That’s a very valid point. I was a bit biased by our own use case when suggesttung the package architecture. Our packages are very decoupled, and we use the Observer pattern a lot. Changing some of them into modules hasn’t been a problem in our case.
As for the packages that can’t be migrated in this way, why not rewrite them as NPM packages? You can import anything from node_modules. And one is not so much at risk of creating a mess with NPM, like with modules.
Yeah, I agree, the tooling is terrible with packages.