Hi,
Couple of questions for folks:
- Within our Meteor app we have a scheduled job / background process that runs which is pretty separate and removed from the core web experience. We’d like to run this job on a separate dyno. Anyone have experience cutting up the meteor app and having it run different places? Is this even doable?
- I believe this will involve doing some stuff in the Procfile - but am struggling to figure out what to do!
- Also wondering about the “buildpack” - given the need for “sticky sessions” which one is the best to go with? Horse? Other?
I hope we are on target enough that these questions even make sense!!!
I don’t know what Background jobs you are talking about but if the payload is small deploy another meteor app with a method (Job execution) and connect it from the first one via ddp. and call the method for scheduling that job.
i hope that helps!
Hi H,
Thanks for the response! Making sure I’m tracking…
- Are you suggesting creating 2x Meteor apps? 1x for the main site, then a separate one specifically for Job execution?
- And then, I’ve never done this next part, but somehow get 1 app to talk to the other using ddp?
2b. And if that is the case, I presume I could work that all out in local dev before trying to deploy it to heroku?
Ya you could! Create two meteor apps and run two of them together.
And since the second one Doesnt have a front end remove blaze and such packages. Will make your app lighter and built times faster. :
Not trying to put words in your mouth - is this what you were saying? Or was your recommendation to do something else?
Reading further on Heroku:
I think this really captures it. Can you do this w/ a Meteor app? Specify specific .js to be run independently?
Or maybe these questions are just totally obtuse - does someone have experience approach to efficiently scaling a Meteor app on Heroku?
1 Like
Hi guys,
@tewksbum: Are you still on heroku? Did you get this solved? Can you share some insights? 
