Meteor in Production(blog.geekli.st)
blog.geekli.st
Meteor in Production
http://blog.geekli.st/post/66118889218/meteor-in-production
12 comments
Even though I agree with your overall sentiment, one of Meteor's selling points seems to be that it brings more convention to the wild west world of Node. In that regard it shares at least one of Rails values.
he was using real-time in the context of web applications
It is exactly the use of the word real-time in the context of web apps, that I find silly.
It's called soft-realtime. The difference is well known, and you getting offended about it isn't going to do anything for anyone.
It isn't even soft realtime. Go read up on what soft realtime really is. https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f...
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 to begin with, so I'm interested in giving passenger a try for a production app...
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 to begin with, so I'm interested in giving passenger a try for a production app...
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.
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.
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
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
Demeteorizer uses "meteor bundle" internally. What it does differently is generate a package.json file from all of those bundled dependencies. It fixes the case where your development platform is different than your production platform. The native modules need to be recompiled. Using a package.json and npm install makes that really easy. Checkout the big red text in the Meteor docs on deploying[1].
[1] http://docs.meteor.com/#deploying
[1] http://docs.meteor.com/#deploying
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.
As I understand it the former was created before the meteor bundle command was available.
I'm the author of Demeteorizer. Would love to hear what happened so we can get it fixed.
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
[0]https://github.com/onmodulus/demeteorizer
I think the author was only talking about how to make Meteor scale on any hosting service by making it into a raw node.js app, something that more people have experience scaling. The NPM package demeteorizer, which was written by the modulus team, can actually be used to turn any meteor app to a core node.js package, which can then be hosted as you would any other node.js apps and can use any node.js hosting service (nodejitsu, heroku, appfog, modulus.io) or roll your own on bare metal (dedicated/aws).
I ran a meteor app as an entry system for a local design awards show last month. Everything went swimmingly well and people loved the fast app-like interface. The only place I had trouble was on the admin side where large amounts of items were sometimes not loading properly (usually a page refresh would clear the problem though). My takeaway was 1) This is beta software people, of course its not going to be perfect and 2) Deciding what should be sent to the client takes some thought and I could have almost certainly made things more efficient. With time, I think both of those issues will be resolved what with the highly active meteor community and MDG making great progress on the framework, and with me thinking more 'meteor-like' and building my apps more efficiently.
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...
My current gripe is with the spiderable package and phantomjs for seo bots, but that is a different beast...
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).
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.
If you need to strip a lot of boilerplate and modify the code of a large framework in order for you to use it enjoyably, maybe you should look into different frameworks instead? Perhaps a microframework.
I think you misunderstood the article. There is no stripping of any boilerplate, but rather converting the existing project to how meteor runs itself as a native node.js application, in order to run it in production. That way, you can use a number of other tools to keep it running (forever), to load balance it with other instances (http-proxy) or monitor it (newrelic).
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
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
Is it just me or does that page not really work on a touch screen device (iPad)? It loads with width exceeding screen width and the pinch gesture doesn't seem to work. It just scrolls horizontally. Or does that not make sense?
If the Meteor packaging/dependency system can be easily automatically converted to node.js standard...
...this makes me ask why the heck Meteor doesn't just use the node.js standard to begin with?
...this makes me ask why the heck Meteor doesn't just use the node.js standard to begin with?
Because raw Node does not take care of setting up the database and that sort of stuff. That's what the non-Node layer around it is for. Very useful during development.
I made this with Telescope and Meteor: http://usability.userium.com/
It's a bit slow, might be because I can only use one dyno on Heroku with Meteor, because it needs session affinity.
It's a bit slow, might be because I can only use one dyno on Heroku with Meteor, because it needs session affinity.
[deleted]
"If you need video streams like CodersTV. All of these are built with Meteor and are awesome examples of things you can build."
I need video streams in Meteor. Show me where.
I need video streams in Meteor. Show me where.
Hey kirbyk,
Founder of CodersTV here. I'm trying to get in touch with some experts of Meteor to make some broadcasts about it. Already tried to contact Chris Mather to do some casts, but he is focused in http://www.eventedmind.com right now. Go check some of his videos, they are very inspiring! :)
Meteor channel on YT are very inspiring too: http://www.youtube.com/channel/UC3fBiJrFFMhKlsWM46AsAYw
Hope you enjoy!
Founder of CodersTV here. I'm trying to get in touch with some experts of Meteor to make some broadcasts about it. Already tried to contact Chris Mather to do some casts, but he is focused in http://www.eventedmind.com right now. Go check some of his videos, they are very inspiring! :)
Meteor channel on YT are very inspiring too: http://www.youtube.com/channel/UC3fBiJrFFMhKlsWM46AsAYw
Hope you enjoy!
I thought of building something akin to a social network for the sole purpose of letting the users create user scripts to customise their profile in lua.
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