I tend to agree that the payback probably wouldn’t be worth it, but it would be cool I used to love cloud9 because it meant I could play with Meteor even inside my corporate firewall when I had a spare 5 mins…
Cloud9 and cloudpebble are both on github, so might be a good starting point if it ever was attempted.
Deploying from github and a free-tier on Galaxy would get you almost as far with much less effort.
Trying to integrate with JSFiddle/Codepen/CodeSandbox would be an interesting challenge though. CodeSandbox has a node template, so that is prbably the best starting point. Looks like someone has already succeeded… Maybe continue that conversation is this thread…
Was not only talking about the publishing part but the coding part as well. As of today if I wanted to develop a react-native app with a meteor backend I’ll be a bit lost where to start. Lot of packages seem not to be maintained and react-native has evolved a lot. That’s why I really am hopeful and happy that a big refresh of documentation for all the main technos to be used with meteor (react-native, apollo, SSR…) will bring lot of newcomers as well and tempt people to use Meteor for lot of different cases
This just reminds me of all the nice showcases and examples for several packages on *.meteor.com, until it was switched off by MDG. It was a real good way to see the packages in action before adding them to my own project.
BTW, it would be great if Tiny would return *.meteor.com free hosting with some advertisement or anything. They are currently spending budgets on promoting meteor via ads but live Meteor web-sites would be better advertisements.
Would love to see better support for managing multi-region deployments. We handle the hosting for a telecommunications app (sitting at ~$30K/year spend) that uses Meteor heavily & where availability is critical down to the second. We ended up having to roll a custom solution on top of MS Azure to facilitate the parallel deployments to each region.
We would probably be able to build something similar to wrap meteor deploy but the current per-region separation of the management interfaces is a pretty major blocker for us (not sure if this was done to save dev time or if there is some technical limitation here that lead to the split).
YES please?!? we really need autoscaling. We are, actually, looking to other hosting based solely on this issue! There is obviously a financial incentive, but also a environmental one: it makes no sense to run a maximum number of containers “just in case” - wastefull!
If you can fix this, you will keep our business!
For some of my Deployments I use Nodechef, things that I like about their hosting are:
Static hosting, easier to setup SEO ready landing pages and have the app separate.
Bash scripts to add or adjust plugins such as wkhtmltopdf - which is WAY out of date.
included mongo database, for those projects that don’t need a huge setup
smaller containers on the cheap with database and static hosting
only thing that I wish they had was the ability to create a container via CLI, I would love the ability to create dynamic projects. Other thing is no Database interface but Robo 3T works fine.
The deal-breaker for us, literally, with Galaxy, is the performance of the app. Using small containers on AWS just blows any Galaxy container out of the water for raw speed, which we need for a lot of reactive updates and heavy crunching in our simulation. I wish there was a performance tier available on Galaxy, or that the containers themselves were burstable, that is probably the biggest problem.
I used to love cloud9 because it meant I could play with Meteor even inside my corporate firewall when I had a spare 5 mins…
we really need autoscaling. We are, actually, looking to other hosting based solely on this issue! There is obviously a financial incentive, but also a environmental one: it makes no sense to run a maximum number of containers “just in case” - wastefull!