Hacker News Reader

Comment by debaserab2 | Hacker News Reader

Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks.

The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you do when your app blows up and suddenly the hosting costs of meteor is too much of an overhead?

View on HN

So... as it happens I have a lot of experience deploying Meteor apps to servers that don't belong to Meteor. In fact, I may have a greater variety of such experience than anyone.

As the lead developer of Sandstorm.io, I have deployed Meteor:

* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.

* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).

* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.

* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).

I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.

I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.

> On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps.

What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)

In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?

The easiest way to understand what Sandstorm does is through the demo: https://demo.sandstorm.io

Try installing Wekan, which is a Meteor-based app.

The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.

We are, of course, building tools for other stacks as well. It just takes more work.

You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more.

I use Digital Ocean with MUP and it works great with minimal efforts.

What options did I miss?

What kind of load does that app you host on digital ocean have?

Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.

Reply on news.ycombinator.com