Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meteor in Production

blog.geekli.st

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Meteor in Production

#11

Post by wc- »

mcrider wrote: post #9
aioprisan wrote: post #6

Earlier quoted context omitted.

did you make sure that you don't have the insecure package installed, that pushes the entire database to each client, and instead are subscribing to the data? this is reminiscent of how one one of proof of concept apps was acting a few months back and that was the cause.

Sure, thats Meteor 101 ;) Still, as a developer you need to decide what collections you want to publish (and which parts of each collection) so as to make the application run blazing-fast but also make sure you're only publishing stuff when its needed. This, IMO takes some finessing to get right.

This was definitely my biggest scaling painpoint. I used meteor for an app that throws a lot of data points at the client (interactive realtime timeseries data) and it required trying a few different approaches until I was happy with the amount of data I was sending over the wire on first load vs making the client's first experience as interesting as possible.

My current gripe is with the spiderable package and phantomjs for seo bots, but that is a different beast...

Re: Meteor in Production

#12

Post by mcrider »

aioprisan wrote: post #10
mcrider wrote: post #9

Earlier quoted context omitted.

Sure, thats Meteor 101 ;) Still, as a developer you need to decide what collections you want to publish (and which parts of each collection) so as to make the application run blazing-fast but also make sure you're only publishing stuff when its needed. This, IMO takes some finessing to get right.

ah ok :) interesting, could you share some of the code in question, or is this a closed source app? I'd be happy to take a quick look

The project was based off of the CMS I've been building in my spare time: https://github.com/mcrider/azimuth. There are probably a lot of things I could do to optimize collections with lots of data but i've been focusing more on functionality for now.

Re: Meteor in Production

#13

Post by mcrider »

wc- wrote: post #11
mcrider wrote: post #9

Earlier quoted context omitted.

Sure, thats Meteor 101 ;) Still, as a developer you need to decide what collections you want to publish (and which parts of each collection) so as to make the application run blazing-fast but also make sure you're only publishing stuff when its needed. This, IMO takes some finessing to get right.

This was definitely my biggest scaling painpoint. I used meteor for an app that throws a lot of data points at the client (interactive realtime timeseries data) and it required trying a few different approaches until I was happy with the amount of data I was sending over the wire on first load vs making the client's first experience as interesting as possible. My current gripe is with the spiderable package and phant…

I've gotten spiderable to work okay but yeah it does kindof suck. According to the Meteor roadmap, MDG is looking for a better solution but its slated for a 1.1 release (i.e. server-side rendering).

Re: Meteor in Production

#15

Post by 616c »

systemtrigger wrote: post #7

Author asserts Meteor scales poorly, which inspired his script "demeteorizer" which helps only if the project is deployed to author's hosting service "modulus.io"

As pointed out by another user, I was annoyed as you reading the article, but the script can be used outside of their PaaS and the source is on Github [0], even though the author did not link to the repo. Typically, I have noticed the prevalence of Github and free repo hosting means people link less and less, and expect you to auto-magically find their code via Google search, or by just clicking one of the social buttons (even though the nerdier you are, the more you hate them and refuse to use them).

[0]https://github.com/onmodulus/demeteorizer

Re: Meteor in Production

#16

Post by FooBarWidget »

wc- wrote: post #3

I didn't use demeteorizer for https://lawyermatch.me , but after making a meteor bundle you just get a node app anyway, so deploying to production didn't really hold any surprised in store for me. Related to production-meteor, I guess phusion passenger supports meteor now, does anyone have experience with the pluses or minuses of passenger over node/forever + nginx? LawyerMatch has been a way for me to test new tech…

Phusion Passenger author here.

Passenger does more than only providing process supervision. It automates the reverse proxying rules for you so that you don't even have to configure that.

It automatically launches Meteor on a right port so that you don't have to think about which port to choose, and whether it conflicts with something else.

It adds administration tools so that you can see what your app is doing; node-forever doesn't do this.

The list goes on. The point and goal of Passenger is to make production deployments significantly easier and less complex. We have future plans to support per-app daemon management too so that you can manage your background workers etc with minimal hassle, and plans to release full-stack images so that you don't even have to setup the machine.

Re: Meteor in Production

#17

Post by FooBarWidget »

systemtrigger wrote: post #7

Author asserts Meteor scales poorly, which inspired his script "demeteorizer" which helps only if the project is deployed to author's hosting service "modulus.io"

I don't get it. There is the "meteor bundle" command, which as far as I can tell does the exact same thing. "meteor bundle" turns your Meteor app into a regular Node.js app. It does not bundle Node.js itself and it does not bundle MongoDB.

The author mentioned that Demeteorizer allows a Meteor app to be able to run on any Node.js hosting provider. "meteor bundle" does that too. In last week's announcement about the Phusion Passenger app server + Meteor support, I documented how one can use Meteor bundles with Passenger. If you look at the instructions[1] you'll see that the instructions for deploying a Meteor bundle are the same as deploying a Node.js app.

So how is Demeteorizer different from "meteor bundle"?

[1] http://tinyurl.com/mj9ex3y

Re: Meteor in Production

#18

Post by FooBarWidget »

The author says that Meteor is a framework that is "pretty similar" to Rails, but that is not true.

Meteor is totally different and strongly geared towards "real-time"[1] responses, unifying client-server code bases and automatic state propagation to all connected clients.

Rails embodies convention over configuration and the don't-repeat-yourself principle. It's ecosystem is generally geared towards server-side processing, although there is nothing inherent in Rails itself that would make it a bad choice for single-page apps with "real-time" responses.

Meteor is much more useful than Rails for certain classes of applications, but likewise Rails is much more useful than Meteor for other classes of applications.

[1] I don't like this word. This is what "real-time" should mean: https://en.wikipedia.org/wiki/Real-time_computing

Re: Meteor in Production

#19

Post by arunoda »

One note on the Meteor's Scalability. Meteor cannot be scaled with the traditional way we scale apps. Adding more instances does not leads to a scalable meteor app.

Since Meteor gets updates from Mongo. Since one write happens, every instance needs to be get that change as well. In Order to have that, we need to use the Mongo Oplog integration. See more info on that.[0]

Official Mongo OPLOG integration comes with Meteor 1.0 (early 2014), Since then you can use my Smart Collections[1] for Oplog Support.

[0] - http://meteorhacks.com/lets-scale-meteor.html

[1] - http://meteorhacks.com/introducing-smart-collections.html

Re: Meteor in Production

#20

Post by mbenjaminsmith »

FooBarWidget wrote: post #17
systemtrigger wrote: post #7

Author asserts Meteor scales poorly, which inspired his script "demeteorizer" which helps only if the project is deployed to author's hosting service "modulus.io"

I don't get it. There is the "meteor bundle" command, which as far as I can tell does the exact same thing. "meteor bundle" turns your Meteor app into a regular Node.js app. It does not bundle Node.js itself and it does not bundle MongoDB. The author mentioned that Demeteorizer allows a Meteor app to be able to run on any Node.js hosting provider. "meteor bundle" does that too. In last week's announcement about the P…

I never did get Demeteorizer to work so I can't compare them but yes the meteor bundle command gives you a Node.js app that can be deployed like any other.

As I understand it the former was created before the meteor bundle command was available.

Post reply on HN