I’m not sure what you’re doing there but it seems to be the wrong approach. Complicated?
Here’s what I do to set things up on a Debian Minimal Installation:
a) Grab the build tools with apt-get
b) Build the proper version of Node and MongoDB, install them
c) Install nginx
d) Set the right environment variables so Meteor can find the MongoDB installation (it’s in the docs)
e) Configure nginx to act as a proxy (easily found on SO)
f) Use forever or similar to keep Meteor up.
This is on a dinky VM I’m not paying very much for. And yet I’m seeing this:
I’m not complaining. Simply telling that I’m not seeing the multiple-seconds response times.
And those were files I put into Meteor’s public folder, i.e. files which are served by the Meteor app. When I access files I put into my /static folder which is served up by the nginx process (bypassing Meteor), it improves a bit but not by much.
And comparing it to other websites out there, the figures are pretty much run-of-the-mill.
I can only conclude that you were doing something very weird to get such slow response times.
I would agree with @rhywden@sbr464, deploying with Meteor and Node requires some basic technical expertise. PHP may be idiot-proof at start (and this is why Wordpress and Joomla! took off), but a high traffic website or app will eventually face the same issues you are now facing with Node (need proper configuration, firewall, CDN, etc.).
Meteor and other Node-based frameworks make basic assumptions about technical expertise, not the framework’s fault. Good luck with Wordpress – you should check out Ghost, but again it’s node-based , so you are likely to complain about that too.
First of all, never use Apache with Meteor. Node is asynchronous in nature and Apache is the complete opposite, i.e it’s a blocking process, while Node is non-blocking and completely async. The way Apache works is like an anti-pattern for Node.I think that’s your biggest problem.
Second of all, I agree with your assessment that Meteor is insanely difficult to deploy. This is especially true if you do it yourself. I’ve done so myself for a while and it’s always a pain in the ass. I can’t imagine how I would deploy my app without the existence of Mupx.
I’m curious - what are you people doing that makes your deployment “insanely hard”?
My deployment of a new version looks like this:
a) git pull
b) meteor build
c) moving the tarball over to /var/www, untar and npm install
d) forever stop / forever run
All of which can be easily handled by a shell script.
Also, creating a completely new server isn’t really hard. I’ve had way more difficult stuff - ever tried to create a Mapnik server to serve map tiles from? Now, that is a head scratcher if you don’t run into the proper instructions…
Agreed, we build and redeploy in under 2 mins and load times less than 1s for the entire app bundle. So … don’t know what to say.
@SkyRooms, I noticed on your blog that you complain about WebRTC on iOS. We are implementing a video / audio chatting tool in our Meteor app with Cordova and one of the WebRTC native plugins (they expose the same API as the standard one from Google), so your code would be portable.
But since you moved away from Meteor, you will have to code all this by hand … for us it’s a matter of a day to have WebRTC working on all platforms.
@SkyRooms it looks like you may have been using the wrong tools for the job as well though. Apache isn’t suitable for node apps (as others have mentioned). In fact, Apache isn’t very good in general anymore. NGINX is the way to go for any serious website or web app these days.
I’ve deployed large and complicated node apps (and a couple of meteor apps) with sub 1s response times. You’ll always need to host mongo somewhere though. How’s that different to WordPress where you need to host either a MySQL or MariaDB database anyway?
@thea can this be closed? Seems like a pointless thread.
I think the same as you… It’s super easy to setup the development platform and then deploy it. Setting up *AMP is kinda easy but we’ve had very hard times with platform specific parts, LESS compilations and the likes when using PHP that we had to run everything inside a VM just to have the same folder tree and what not…
With meteor it is painless to configure and set-up any environment.
If you want to get picky and all that, you might want to set-up your whole environment under docker containers which brings some complications but in a whole day I had set up CI/CD pipelines and all that for an application that uses three separate Meteor applications (2 front-ends, 1 service-like). All that runs as a full cluster and can be scaled with a push of a finger.
Have you tried to scale horizontally a PHP app? Even though Meteor is not out-of-the-box ready and bulletproof about horizontal scaling it still is easily achievable.
My guess is either you did something awfully wrong with your deploy (such as leave autopublish on) or Meteor was just not suited for your use case at all! But the point here is, use the right tool for the right job… AND use it properly?
For the Apache detractors, I’m running multiple Node apps on my LAMP box without issue.
The Javascript engine is completely synchronous. It executes code one line at a time. Events are asynchronously placed on the event queue, but are only executed when the Javascript execution stack is empty.
I’m not saying Node can’t be deployed with Apache, but there are other benefits to NGINX apart from easier node app deployment (such as dead-simple HTTP/2 support, excellent built-in caching etc)!
I also find it easier to debug issues and get up and running, but I’m aware that’s quite subjective
I think the issue is, to a LAMPer, the database is hosted on the same box. The idea of a database as a platform made me recoil too. We can debate the merits of database PaaS… but it does shock the system initially when you’re used to rolling the hosting costs into one.
UPDATE @korus90 makes a good point below… you can host Mongo on the same box. Us cPanel/EasyApache dorks get spoiled with the push of a button full stack set ups. So when we figure out that you can still host Mongo on your box, we regress to “we can’t do it with one button” crying. Then again, that integration is one of the reasons we’re here… try running a modern version of Postgres with cPanel. What a mess.
Depending on how you host (ie, not on Galaxy) then you can install MongoDB on the same box if you want. I ran a Meteor app with MongoDB on the same $10 DO box for over a year
, so you are likely to complain about that too.