Hot swap of local meteor package / production-ready architecture

packages
1

This is perhaps a newbie question, with intermediate and advanced questions/suggestions in the bottom :slightly_smiling:

I am using local Meteor package for my app (not posted on Atmosphere.js).

When I update this package elsewhere, I proceed with the following:

  1. Update version of the package.

  2. Delete old package from /packages/ directory of the live app.

  3. See my program search for packages 3(?) times and then crash:

    Your app is crashing. Here’s the latest log: Errors prevented startup:

    While selecting package versions: error: unknown package in top-level dependencies vladimir3000:testpack

    Your application has errors. Waiting for file change.

  4. Copy new package with new version.

  5. See my app picking up the changes and going live again:

    vladimir3000:testpack upgraded from 0.0.2 to 0.0.3 =>Meteor server restarted

Is there a way to avoid step 3 and more elegantly instruct meteor to replace one package with another. Meteor update would not work as the package is not on atmosphere.js.

Intermediate question: is private package repository similar to that npmjs offers is available or planned in Galaxy?

Advanced question: is hot swap is something from SOA world not from blood and fibers of Meteor javascript? What about modules in ES2015, how they fit in Meteor? As far as I understand the principle of decoupling packages with distinct features is that when you update some feature, the most user should see is sign “Feature xxx”/“Plugin xxx” is unavailable right now, please, try later for couple of seconds. An d only in the part of the program relevant to that feature. But at the moment I see program crash on any single error in any line of code. How it can be prevented for production?

To sum up, while most of apps currently built with meter do not suffer much from 5-15 downtime, I would be grateful for recipes and experiences of running serious business apps with 0 downtime.

1 Like
2

Have you tried using a symlink instead of deleting/copying manually your new package version?

3

Could not find any helpful info on that. Could you please, paste some short Meteor-related example?

4

you should avoid this copy paste process by creating a symlink as suggested by @hellstad

just type ln -n /your_source_package_folder /your_destination_pacakge_folder

1 Like
5

Just in case OP or other readers don’t know what a Symlink is: https://en.wikipedia.org/wiki/Symbolic_link

1 Like
6

Thanks, guys. I did not know that sysadmin stuff and thought it is something specific to Meteor, not Windows.

7

Thanks, will test it now. Still, I guess that’s workaround. I mean, that’s more elegant way but it is a kind of Windows way, not Meteor way. And the application will still need to be recompiled with downtime for the whole app. That’s perfectly okay for Android or iOS app but no good for Web-SaaS.

8

I have found good answer to part of my questions - https://forums.meteor.com/t/domain-driven-design-and-meteor/9744

My guess is that CodeAdventure also have experience with enterprise apps and that’s really precious addition to Meteor ecosystem :slight_smile:

So the question now is the following: Is Space add-on is the only way to hot swap packages (not 100% sure Space does that) and add features (looks Space can do this) without recompiling whole Meteor application?

9

I don’t really understand what you mean by hot swapping packages. You can use a microservice architecture and separate your apps into different Meteor projects if you want, but you’ll still have to rebuild your project(s). Even if you are just re-deploying a single monolithic app in production, it takes less than 5 seconds for the nginx and meteor daemon to restart.

1 Like
10

Microservices. Great. That’s what I have meant, so I have been searching in the wrong place, i.e. in the wrong layer.