I am facing dilema whether I should bundle node js app from meteor or just run meteor --production.
I am mostly interested in performance impact. I have found some explanation on here, but it is not clearly stated that meteor runs in production mode.
Running just meteor --production will simplify my deployment process a lot.
I would like to know are there any reasons to stick to bundle?
I think when you run meteor --production, you are still running as if you are in development-mode, only using "production" settings and such. You are still getting an internal/local MongoDB, you are still burning CPU time monitoring files, etc.
If this is true, then the end result is that you will not scale at all. I doubt that running local MongoDB uses optlog, which is a HUGE performance boost for Meteor apps.
Your best bet would be to look at some automated build/deploy tools. I have personally used mup and mupx. The latest version of mup builds your app, sets up MongoDB (if you want) and nginx, builds them all as docker images, and deploys them. You can even setup SSL certs w/ nginx (although no Let's Encrypt support yet :(). Or, you could easily script the deployment yourself using any number of tools, including just raw scripts. I think in the long run you will be in much better shape than trying to run the app using the meteor command.
Related
I have a node.js application that run as a application server.
It is deployed on an Ubuntu 20.04 machine running on AWS, uses nginx as a reverse proxy and PM2 as a service starter.
Everything seems perfectly configured.
What looks strange to me, is that I have a React application, in a similar environment, but, before to move it on the server, I run build it, so creating a sort of packed and not easily human readable application.
My question is: Is there the need to do the same with a node.js application?
And, in case of positive answer, How to 'build' a node.js application?
There is no need to build a normal nodejs application.
What you mean is the use of a bundler e.g. webpack and a javascript compiler e.g. babel. To create a react application, you usually use a tool like create-react-app that sets up all this stuff for you. For react you need the compilation beacause you use the jsx syntax that browsers do not understand. In addition to that a bundler has some more advantages.
Check out this video if you want to know more about it:
https://www.youtube.com/watch?v=5IG4UmULyoA
No you don't have to build anything for node.js you just have to run the server. for client side apps you need to build and serve the Dist through web servers like apache or nginx.
I have a Java Spring Boot backend and React.js frontend. I need to place compiled Node.js app into folder "static" of my Spring Boot application so it can be served as static content. This is done using the command npm build.
The problem with this is the compilation is quite slow and consumes several seconds before it's done. On the other hand, when I run my frontend app directly with "npm start" then projecting local code changes into my webbrowser takes only one second.
It's not acceptable for me to wait 10s or more until build into my Spring Boot is done. Is there a way to "link together" node.js project files without any optimisations, or to speed up the build?
You're referring to a common pain point for repeatable builds, dependency installation consumes too much time. The only known workaround is to use a cache. Here's an example. Well, some people checkin node-modules, but that's just shooting yourself in the foot.
If you're feeling adventurous, you can also consider adding squid as proxy in your production build environment, which will help with faster docker image downloads in addition to just npm installs.
I've been searching around the web to see what's the best/simplest way to deploy a meteor app, and have found that Meteor Up has been the easiest way to do this.
However, I've been noticing that this works pretty awesome on small apps, now that one of our apps has grown larger than 250mb, Meteor Up has to build and deploy the whole 250mb app again and again for even the smallest change.
With other node applications we have on digital ocean, a simple git pull does the trick without having to re-upload the entire application.
Is there a way to maintain a meteor application with a github/bitbucket repository?
Thanks!
Well, I have found a solution for this.
Reference: PM2 + Meteor Environment Setup
Using meteor build and following the README that it generates, I was able to run the bundle without using meteor up.
This helps at deploying since it skips the process of uploading the entire bundle to the server, instead, just use git pull in the server to pull your code changes and use meteor build to create the build and run it with pm2.
I'm running a NodeJS app on Openshift using Jenkins for building deployments (and I'm pretty new to both Node and cloud-based servers). My app depends on a package that has a binary component, so I can't just check it into git - it fails when it's executed on the server. I'm wondering what's the best way to deploy these sorts of dependencies. I see that there is an $OPENSHIFT_DEPENDENCIES_DIR (as well as $OPENSHIFT_BUILD_DEPENDENCIES_DIR), but I can't find any information about how (or if) these can be utilized for node modules. It would be great if I could keep all my dependencies on the server and out of my source tree.
Thanks!
Update: I forgot to mention that I need to apply a patch to the package in question, which is why I can't just rely on it being auto-installed via package.json. Plus, it seems awfully redundant/slow to rebuild all your dependencies on every deployment.
I'm also new to nodejs. I've been playing with nodeJs for about 6 months from now. As for my personal experience nodejitsu is the best cloud-hosting service for nodejs. As I said so due to the following reasons.
You can simply install jitsu command line in your terminal
Your app can be deployed with all the dependencies and databases using the package.json file
They support all the types of sockets either
A very good alternative for jitsu is heroku But sometimes heroku fails with Socket.IO and stuff.
Can someone with actual experience explain how these layers interact with each other and how a working setup (dev to production) should actually be, well, set up?
I understand there are buildpacks that serve to install Strongloop on Heroku. And that deploying the actual app is done with git push.
Some specific points that you could address...
How can I have (more or less) the same environment locally and at Heroku.
After setting up Strongloop Node, does the server environment stay in place? Or is it recreated every time I deploy an update? (if yes, how so?)
How does slnode fit into the picture
Can I connect to a db hosted at Heroku from a dev machine?
I hope answers to this question can serve as a guide for people like me who are struggling to understand how all the pieces go together.
I understand there are buildpacks that serve to install Strongloop on Heroku. And that deploying the actual app is done with git push.
You don't need our buildpack, and yes, you deploy with git push.
How can I have (more or less) the same environment locally and at Heroku.
How much more or less? You can develop on your mac laptop, and push to Heroku, using same version of node, or you can be more like Heroku, and use Linux, or ... what exactly about the Heroku env do you want to reproduce?
After setting up Strongloop Node, does the server environment stay in place? Or is it recreated every time I deploy an update? (if yes, how so?)
Not sure what setup you are referring to.
How does slnode fit into the picture
It doesn't.
Can I connect to a db hosted at Heroku from a dev machine?
Don't know, sorry, try Heroku support pages for this kind of heroku-specific tech question, perhaps?
I followed docs on bottom of page at http://docs.strongloop.com/display/DOC/Heroku, look for "Create Procfile and deploy", and it worked OK for me.
Fast answers
Use Vagrant, download a Debian 6 box, and install whatever you need in it, remember to check what version of Node.js Heroku uses.
It will be partially rebuilt, your npm dependencies will be redownloaded, your application gets rebuilt and so on.
You can use slnode on your dev machine. However if it is necessary to use slnode on a dyno, fork a build pack and install slnode as part of it.
You can connect to a database hosted on Heroku from any network connected server or pc, you will be provided with an ip and credentials.
Build packs
I'm not sure about actual constraints of a build pack, but it can do almost anything that you can do in an Debian 6 virtualized environment with shared kernel. ( An Debian 6 instance in a OpenVZ VPS )
Think of build packs as low level dependency managers which solve dependencies like node.js, Redis, Apache2 and so on.
They also build an environment like file system structure, ENV variables and so on.
Heroku infrastructure
Heroku is using AWS as it's raw hardware provider, AWS provides a fresh installation of an OS in a virtualized hardware ( VPS )
Heroku builds dynos on top of raw OS, by guess, it shares one OS between at least 128 dynos.
Each dyno is isolated from others, it has common software built in like ls, but it's build pack's duty to install any other software like Node.js for your application.
Heroku's node build pack, installs Node.js, and runs npm.