I just created a simple web app using the MEAN stack, and I want to host it online somewhere (I'm brand new to the MEAN stack). I have done this with static pages (using only HTML and CSS) using other sites such as BitBalloon, but since this is my first deploy with the MEAN stack, I really don't know how to get it online. I'd prefer using a free service for now since I just want to test my app, and share it with friends. For example, BitBalloon will give you an address like http://stoker-neutrons-12345.bitballoon.com/, which is perfect for testing your app, and sharing it with others. Is there a similar method/hosting site available for apps built on the MEAN stack?
This question will probably be closed quickly for being a "recommendation question", which doesn't fit SO's target, but still, here are two recommendations:
RedHat OpenShift provides a free tier with plenty of functionality.
Heroku's "free" package might also work if you're just testing. However, your container will go to "sleep" after 30 minutes of inactivity.
Be prepared, that both options require some effort on getting things rolling (steps are different than simply FTPing some files). But at least Heroku provides some quick start instructions (RedHat probably too, but I haven't checked)
Related
First of all, I'm not really sure if this question goes here in stackoverflow or if I should ask it on another place. Please if that's the case, indicate me in the right way :)
So, for context, this is an app that I was asked to develop for my job. At first I thought in doing a webapp and host it inside the company servers and domain (intranet), but it isn't possible due to external issues that I can't control.
Is there another way to achieve this? The app must have a database and should be accessible for a bunch of users at the same time.
Of course we want to spend the least amount of money possible to make this happen. Also, using a workstation of our own to host everything is not possible either.
Edit: I didn't finish developing, but for now I'm developing it in Python Flask.
The number of users is small really, just up to five people.
OK - I guess a lot of what you'll get in response to this is your definition is too vague. Things such as scale, number of users, programming languages used to create the web app etc are important when talking about hosting.
However, for me, there are three very good options out there for free hosting, up to a certain amount of traffic.
1.) Heroku - Heroku.com
A world known web hosting platform. You can publish code through GitHub, and it has some extensive coverage for different types of web apps. Definitely worth a look.
2.) Netlify - netlify.com
Similar to Heroku, but used by some major companies. Allows you to host for free to a point, and is relatively simple to get started with.
3.) Vercel - vercel.com
A bit more technical in my opinion - but again, very similar to the above two and has a free tier.
All three are great options, and I'd recommend looking into them in more detail to see what option is best for you. Can't go wrong with any of them.
I had a similar problem: A Python-Flask-SQLite app for me and my office pals to use together.
The solution was creating one .exe file with pyinstaller, hosting this and the database files in a network drive (one that everyone that will use the app has access). As everybody (~10 people) sees the same db, things works fine!
I mean that it doesn't need git to init or deploy. It's purely standalone with its own CLI or something like it and it's free.
It seems nodejitsu is gone or something and convox wasn't sure what they were doing.
Oh, and this is for small apps with no large scalability in mind.
Any good ones out there? Thanks.
You will not get a good free server to deploy your apps. But you can get close to free. Some VPS providers can give you several months of their servers for free if you register with coupon links (e.g. see coupon links for Digital Ocean and Vultr) but it will not be as convenient as Heroku or nodejitsu. With a VPS you will have to manage your own system, but it will fit your need for: "purely standalone with its own CLI or something like it and it's free" at least for few months and then you'll have to pay something like $2.50 per month which is almost as good as free, especially considering that you can host hundreds of small websites on a single VPS.
EDIT: STILL NOT ANSWERED. I appreciate the advice I have received so far, but I still have not found a proper way to test the amount of resources my server is using. I decided to use GCE instead of GAE but I still want to measure the resource usage.
I have searched all over google as well as SA and can't seem to figure this one out.
I would like to deploy my (very small) node.js server to either Google App Engine or Google Compute Engine (not sure which to use yet).
I see that they charge based on how many resources you use, but how can I check this before I make my decision? Basically what I would like to do is find a way to analyse my server and see what CPU/DISK/NETWORK/RAM/Etc it uses, and then possibly make some refinements to my code to get the usage down as low as possible.
I am a hobbyist programmer and this server is just for personal stuff so I don't need anything fancy. I just want to get it hosted on google and not my home server. My real fear is that, since I am not a professional, my code might be doing some crazy background stuff repeatedly that would rack my usage up for nothing.
Quick rundown on what my server does:
Basic node.js express template that IntelliJ made me, then I added my code to sit and listen to a Firebase. When the firebase gets a message (once or twice a day maybe, text message equivalent size) the server sends a quick GCM/FCM message to a few devices. Extremely simple server, very little code. Nothing crazy.
As a little bonus for me, if you have a suggestion as to which platform I should use, I am all-ears.
If you do not need this server to run 24x7, use App Engine. It stops an instance if it is not being used for 15 minutes. The startup time for new instances depends on your code, but for Node.js instances it should not be long.
Generally speaking it is easier to run an app on App Engine than Compute Engine, but if you use a single instance and don't change code often the difference is negligible.
App Engine has a generous free quota. You may end up paying nothing until the usage gets over a certain threshold.
You can run some diagnostic tools on your existing server, but even then you will get an approximation - a server with a different combination of resources sitting on a different network may use resources differently. You may be able to get a rather accurate estimate of memory usage, though.
If this is a small app with not too many users, even a small instance should be able to handle it. There is no harm in trying - start with the smallest instance, test, go to the next instance up if tests fail. Your key concern should be to have enough memory to handle a small number of requests.
As for the number of requests your server can handle, you can configure automatic scaling. It is a default option in App Engine and can be enabled for flexible runtime. Then you can have the smallest instance (i.e. your server does not crash due to the lack of memory) running, and another instance will be added if and when that small instance is not enough.
Well, after over a month I figure I might as well answer this myself.
What I ended up doing was creating a basic instance on Computer Engine (the micro. Smallest one available) and letting it just sit there for a few weeks. I looked back at the data to see what some good baselines were and took note.
Then I took my server code and ran it on the server. I left if there for a few days, changed it, updated it, etc. Just tried to simulate the things I would be doing. Sent messages on my client app (that's what this server is doing after all is said and done) and I let this go on for a few more weeks.
The rest is history. I looked at the baseline then looked at my new memory, CPU, network and disk usage and there we go. Good to go. My free trial still isn't even over so it was a free experiment.
The good news is that my server is more 'lightweight' than I thought.
I'm working for a small company on something like a new PHP environment for future projects. I'd like to cram in as much modernization and automization as possible (while I can).
The thing is, I always come across solutions that require Node.js (Grunt, Autoprefixer, ...). None of our customer's hosting providers support Node.js (not even our own managed server). Most of the time I don't even have shell access.
I come across npm this and npm that so often, almost as if it's some always available quasistandard. Do I have some misunderstanding here – or is this simply only usable by people hosting their projects on their own servers? Am I just out of luck if I have to support a wide range of (sometimes questionable) shared hosting providers?
Comparing most PHP applications and most Node.js applications is apples and oranges.
Most PHP applications are fairly self-contained and intended to be used with web servers and a mostly stock PHP configuration. Most Node.js applications have a ton of NPM dependencies that need to be installed, and while HTTP is used to connect between the web server and the Node.js application, it isn't always clear what port that will be on. Plus, the Node.js application may require extra configuration, command line parameters, etc. Some hosting for Node.js is smart enough to look at the package.json file (Elastic Beanstalk for example) and figure out how to start your Node.js application.
These days you will find PHP going the same way. A lot of software is built with Composer packages that must be set up and installed. You won't find many folks getting that working on shared hosting either. Many Node.js applications have nothing to do with the web or web servers. That is increasingly becoming the case with PHP as well, but you won't find shared hosting for PHP applications.
Basically, you're looking at two entirely different ecosystems.
I think that your company needs to realize that you're sacrificing an awful lot just to stay compatible with cheap crappy shared hosting. These days you can get a $5/mo. VPS to run whatever you want, and that's often the same price as your shared hosting. Why waste time and resources while building a substandard application if you can pay $10 more a year and do what you want/need to do?
Use the technologies that you need to get the job done. If what you can do works fine in a normal PHP web application framework, then use that. If you need to build a persistent server application and feel that Node.js is right for you, use that.
I've been reading up on a few node tutorials but there are a couple of best/common practices that I would like to ask about for those out there that have built real node apps before.
Who do you run the node application as on your linux box? None of the tutorials I've read mention anything about adding a node user and group so I'm curious if it's because they just neglect to mention it or because they do something else.
Where do you keep your projects? '/home/'? '/var/'?
Do you typically put something in front of your node app? Such as nginx or haproxy?
Do you run other resources, such as storage(redis, mongo, mysql, ...), mq, etc..., on the same machine or separate machines?
I am guessing this question is mostly about setting up your online server and not your local development machine.
In the irc channel somebody answered the same question and said that he uses a separate user for each application. So I am guessing that this is a good common practice.
I mostly do /home/user/apps
I see a lot of nginx examples so I am guessing that is what most people use. I have a server with varnish in front of the a node.js application and that works well and was easy to setup. There are some pure node.js solutions but for something as important as your reversed proxy I would go for something that is a little more battle-tested.
To answer this correctly you probably have to ask your self. What are my resources? Can I afford many small servers? How important is your application? Will you lose money if your app goes down?
If you run a full stack on lets say one VPS then if there is a problem with that VPS then only one of your apps is affected.
In terms of maintenance having for example one database server for multiple apps might seem attractive. You could reason that if you need to update your database to patch a security hole you only need to do it in one place. On the other hand you now have a single point of failure for all the apps depending on that database server.
I personally went for many full stack server and I am learning how to automate deployment and maintenance. Tools like Puppet and Chef seem to be really helpful for this.
I only owned my own Linux servers for the last 3 months and have been a Linux user for 1.5 years. So before setting up a server park based on these answers make sure you do some additional research.
Here's what I think:
Using separate user for each app is the way I'm doing this.
I keep it in /home/user/ to make sure that only user (and root of course) has access to the app.
Some time ago I've created my own reverse proxy in Node JS based on node-http-proxy module. If you don't want to use reverse proxy then there's no point in putting anything in front of Node. There's even more: it may harm the app, since for example nginx can't use HTTP/1.1 (at least at the moment).
All resources I run on the same machine. Only when I actually need to distribute my app between separate machines I start thinking about seperate machines. There's no need to preoptimize. App's code is a different thing, though.
Visit the following links::
nettuts
nodetuts
lynda nodejs tutorials
Best practice seems to be to use the same user/group as you would for Apache or a similar web server.
On Debian, that is www-data:www-data
However, that can be problematic with some applications that might require higher permissions. For example, I've been trying to write something similar to Webmin using Node and this requires root permissions (or at least adm group) for a number of tasks.
On Debian, I use /var/nodejs (I use /var/www for "normal" web applications such as PHP)
One of the reasons I'm still reluctant to use Node (apart from the appalling lack of good quality documentation) is the need to assign multiple IP Ports when running multiple applications. I think that for any reasonably sized production environment you would use virtual servers to partition out the Node server processes.
One thing that Node developers seem to often forget is that, in many enterprise environments, IP ports are very tightly controlled. Getting a new port opened through the firewall is a very painful and time-consuming task.
The other thing to remember if you are using a reverse proxy is that web apps often fail when run from behind a proxy - especially if mapping a virtual folder (e.g. https://extdomain/folder -> http://localhost:1234), you need to keep testing.
I'm just running a single VPS for my own systems. However, for a production app, you would need to understand the requirements. Production apps would be very likely to need multiple servers if only for resilience and scalability.