My Meteor project has become a big monolith, so for (mostly) performance and healthiness reasons I’m considering splitting it up into several packages.
I’d like to have separate meteor instances accessing the same DB, but doing their own specific thing (admin, client type 1, client type 2, for example).
So the “core” I would need everywhere includes DB simple-schemas, proprietary JS functions, some config/theming options, a few generic front-end components and meteor methods (server-only and server-client).
How would you approach something like this:
private npm modules?
atmosphere packages?
git submodules?
Especially considering server/client separation in a meteor app, this has proven to be a bit trickier than I thought. Also how does meteor minify/strip external modules? Can you use server/client folders?
The first step to split your app would be to use the ES2015 modules system
it includes the import and export system.
like its name says, you will split your app in modules.
wanna go a step further? check how Rocketchat structures their app, they call their system Rocketlets https://github.com/RocketChat/Rocket.Chat/issues/6890 and allow them to add buttons and addons to their system vía packages on atmosphere, very modular and functional.
what recommendations do you have on modularizing meteor? what practices are you following?
Brilliant, I had never read the “Splitting into multiple apps” paragraph of that tutorial. It provides a simple solution I hadn’t even thought of yet, which is to essentially set an environment variable and decide which “Router” to instantiate.
Currently, the app isn’t modular at all, I have my admin and user apps all loaded, whoever is visiting, which makes every visitor download a big bundle of unnecessary code!
yeah we went this route. Our backoffice “admin cp” app is several times larger than our client app. Both talk to the same database. We actually have three apps. One for service A, one for service B, and the “admin cp” app which allows us to do our work–order management, account management, purchasing, receiving, fulfillment, shipping, bookkeeping, etc. for both services
So yeah, the client app doesn’t need to load a bunch of code which they will never see or execute.
Also splitting the app allows you to use different UI frameworks and different technical approaches. i.e. our admin app is iron-router, blaze, but the customer-facing app is react + redux + react-router (or it could be Vue, or whatever).
important: you’ll probably have some shared code which is used by both apps, such as schemas. We worked using git submodules for a while. But now we recommend this: commit both projects to the same repo
enterprise(repo)
\admincp
\client
\bin
\shared
also, I keep the production keys in a separate repo
enterprise_production_keys
then each app references them in the deploy scripts
meteor deploy --settings …/…/enterprise-production-settings/admincp_production.json www.yourdomain.com
now you can have various remote contractors working on your app, and you get version control for your keys, but you can maintain separate permissions for the production key repo so that only a few trusted people can deploy your app or view/edit those settings.
I don’t think that having your production keys in github is a good idea, unless you encrypt them of course. Otherwise you will share them with many github employees and also rarely, repos get hacked. My 2 cents.
Regarding services: I have worked with both mono-repos/symlinks and git submodules. I prefer submodules at this point. Although they are a bit more work, I like the modularity
Yeah and if you wanna work on just one tiny part/mircroservice you have to download the whole repo I guess that probably is one reason why it feels more modular to me.
Anyways, as I said it’s less hassle for sure, I give you that. Other than that, I fail to see how any one of your bullet points applies to mono-repo and not submodular structure. Though I havent read your sources yet
We had three apps sharing a submodule, so it was a pain because if you edit the submodule you have to be sure and advance it in each project independently–or else you can have different apps running different versions of your shared library functions or schemas. It was headache. We are very welcoming to anything that reduces complexity.
If you are doing active development, git will just download the deltas, so once you clone the repo once, you usually don’t have to transfer the whole repo each time. (Our three-project repo is 14GB, but pushes and pulls usually just take a few seconds).
But I understand now everyone has fast internet. It’s pretty nice running a startup in Japan!
I guess that probably is one reason why it feels more modular to me.
