Hi,
I am a newbie at Meteor and non-that-newbie at SPA (MEAN, etc). I am learning Meteor while writing an application and I am not sure what would be the best approach for the design.
The application will have two parts, a “dashboard” for admin for configuring data (not really just a simple CRUD-Mongo interface) and the actual app for the users. If I would use MEAN, I would show or hide parts depending on the role of the user. With Meteor, I am not sure how to do that, so I was thinking to maybe create “2 apps”, or actual “2 sub-apps”, one for the dashboard and one for users and redirect the user at login according to role.
Any better suggestion? Or resources? (I am currently reading Discover Meteor, great book, but it does not offer me a direct response for this particular plan 
)
We did exactly that. We refactored a single app into two. One is the public-facing app, and the other is our backoffice app for internal business functions. Each app connects to the same mongo database. There presently really isn’t another way to control which templates/logic get loaded unfortunately. I hope this is something MDG addresses in the future. In our case 80% of the code is never used by the customer, so it makes little sense for it to all get transferred down to them on initial page load. Our app is fairly large, has dozens of features and interacts with nearly a dozen APIs, but there are a lot more features and complexity in the ‘backoffice’ app than in the customer facing screens. Both customer-facing and backoffice apps have a dashboard themes too. (We are using HOMER in one of the apps. It was a bit of working getting it working in Meteor, but it’s looking very nice.)
If you have shared code between the two apps we recommend refactoring that into packages or git submodules. We actually found the whole process of splitting our app very useful as it’s forced us to refactor some feature-sets to make this more sharable, which has resulting in high-quality codebase in many areas.
You may also enjoy this presentation about managing large meteor apps
http://meteor.redandivory.com/
Cheers!
Thanks Max. So you actually have two completely separate apps, sharing just the DB?
BTW, the redandivory “site”/presentation looks like the next century to me, impressive…
Disclaimer: Self Promotional 
May be you can try this.
BulletProof Meteor : https://bulletproofmeteor.com/packages
–
Answering Your Question.
Yes. You can have two apps and use the same database for that. May be you can include both the admin and front app in the a single app.
That’s way, you may can re-use some stuff.
If you believe, there is very little for re-use them simply use two apps.
Anyway, there are some admin packages for meteor as well. Try them as well.
See: https://atmospherejs.com/meteoros/standard-packages?q=admin
If the app is not very large, there is maybe nothing very wrong with making it an all-in-one solution. That is popular and common. But if you anticipate that the admin app may become much larger than the customer app, you might think to split them. Also you can always split them later, so you might want to just proceed as a single app until you have a more compelling reason to split them. Splitting them will slow down your development velocity a bit as there are a few more moving parts.
Yes we have two separate apps, each with the same MONGO_URL environmental variable–so they point to the same db. For shared code they both contain a shared private package which is maintained as a github submodule repo.
So in both the client app and admin app there is a “wreShared” git submodule package which contains shared things like entity schemes, enums, prototype functions, etc which are used by both apps.