Is Node.js mature enough to make entire web applications in it? I mean entirely in Node.js. I read somewhere that for some reason there should be (for example) nginx behind Node.js. Is it true? Can't Node.js stand alone? Are there any online websites built on Node.js?
in my opinion this isnt true anymore.
you can do two things:
use script like "forever" to monitor your node instance.
use this:
http://nodejs.org/docs/v0.4.12/api/process.html#event_uncaughtException_
to catch all exceptions that are not catched earlier
In the express link, it shows a lot of good applications written by Node.js.
In my opinion, it is mature enough that node.js can be a standalone web application server. There are lots of lib modules supported different things in Nodejs already.
Its absolutely mature enough. There are dozens of companies now that are using it in production for major features, and some that are even building their entire stacks with it.
If you want a well-rounded web framework, check out Express.
There are hundreds of modules that cover almost every type of feature you need, and they're mostly all easily accessible via npm (node package manager).
Over the summer I built a high-traffic Facebook app for a client using Node. Handles everything just fine.
node v0.6 introduced cluster, allowing multiple processes to fork and listen to a single socket. This allows node to take advantage of multiple cores/cpus. This was one of the big reasons to use something like nginx, as before cluster, a single node process would hog up an entire ip/port.
Related
I am planning to start making my first big web project. I am currently at the point where I am trying to visualize everything but some of the technologies will be learned on the run. I recently picked up JavaScript and learned a bit of Node.js.
I wanted to make a rest API in java, that connects to a Mysql database. After doing some unwanted research, I came across a statement which to me seem bold. That node.js can in some way completely replace java as a backend?
For what i know Node.js is a runtime envioronment based of chromes JavaScript engine, with some libraries like NPM. (which I yet have to look into some more)
That was a long introduction, the core of my question is: Can Node.js replace Java in my case, and if so why and how?
Some personal thoughts:
Can Node.js replace Java in my case, and if so why and how?
Definetly. Nodejs is not just V8 with some libraries, but also ships with a lot of ways to interact with the IO, which means you can run http(s) servers, connect to databases and other servers, spawn threads, write/read files among others. If there is some low-level thing that the JVM supports that Nodejs doesn't, you can just write a native binding in C++ (or take one from NPM, there is probably already one for your exact usecase).
The main benefit of Nodejs is that you just write JavaScript, and you don't have to change languages. That makes development more easy and faster (at least for me).
We're starting a new app on Google App Engine with node.js. We also decided to go with Cloud Datastore.
I've found that in the other available languages you can do local unit testing:
https://cloud.google.com/appengine/docs/java/tools/localunittesting
I haven't found anything available for node.js. Do you know if there's something like the above link? If there's not, we're probably going to change to Java or Go.
Thanks!
EDIT: I've just found this
https://cloud.google.com/datastore/docs/tools/datastore-emulator
Has anyone tried and knows if this could solve my problems?
The difference between what you're looking at is about App Engine Standard vs App Engine Flexible (formerly known as Managed VMs). NodeJS is only supported on App Engine Flexible.
App Engine Standard has some advantages (faster deployer times, ability to "scale to zero" so you pay nothing for idle apps), but it's much less flexible in that many libraries are not available in the runtimes and so you rely more heavily on App Engine APIs. To provide a way to test it locally, the local development server was provided.
Standard supports Python, Java, Go, and PHP. However, even with those languages, you still might choose Flexible if you want to do something like use Java 8, Python 3, or custom libraries like imagemagick.
App Engine Flexible is a pretty different product, although on the surface it looks similar since it has similar tooling and configuration, and they are both scalable platform-as-a-service products. But the concept is that you bring whatever environment you're familiar with it, and it runs it in a container (which is hidden from you. unless you use Custom runtimes to builds your own Docker runtime for it).
Since you're bringing your standard development environment to App Engine, the idea is you test your Node app the same way you would test any other Node app, and run it like you would run other local Node projects locally. There's not supposed to be too much special about the App Engine flexible environment, by design, so there's no need for a special local testing server.
However, if you're using Cloud Datastore, emulators are provided so you can run tests more quickly and without paying any money. So the emulator is definitely what you're looking for to do local unit tests. If you have any problems or issues with it, you should followup with more questions on Stack Overflow.
If you haven't seen already, there is a Getting Started with Node app that uses App Engine Flexible, and demonstrates a variety of tasks using Cloud Datastore, as well as MongoDB and CloudSQL (managed MySQL).
https://github.com/googlecloudplatform/nodejs-getting-started
I have an application and I have a debate with my peers on if we need to use node.js or not.
Our decision is to use angular.js for the front-end and to communicate via REST api with the app server. The application server will not be in node.js. It could be in .net or Java
Nginx will be in front as it is better for serving static files, gzip etc..
There are many options to boilerplate your angular application and many of them includes nodejs. My first approach was to use node.js as the primary web server and scale it out for solving performance issues. Although, it wasn't a good approach as node's roles isn't to act as web server. Well, here my question arrives.
By keeping in mind the two aforementioned points are there any reasons to generate the front-end including node.js ?
Is there something that I could benefited by that I haven't think of?
Here's the short answer: If you are set on using nginx in front of a .net or Java back end, and you're just looking for a deployment tool for angular.js, then just choose whatever javascript deployment tool makes sense, which may well be built with node.
What follows is a little more exposition:
I'm not quite sure what you mean by "node's roles isn't to act as web server"... if you mean in general, then that's precisely how it's generally used, if you mean your application server will be .net or java, but not javascript, then fine.
Generally speaking, nginx will perform faster for static files, but the margin of improvement over node.js is likely to be meaningless for pretty much anyone. If you need to (or it makes sense to) include node as part of your stack for angular deployment, then it could make sense to use it as your reverse proxy and just eliminate nginx altogether. The odds that you'll get measurable benefit from using nginx instead is vanishingly small.
That said... if you've already got nginx set up and moving to node instead represents extra work that you've already done once, then it loses its primary appeal.
What node.js has going for it more than any other project I'm aware of is that it's extremely capable at every level of the web stack. But it's not necessarily more capable than individual projects used in their appropriate level of the stack, and if you're not going to use it to reduce the complexity of your stack by homogenizing the technology and applications involved, then it just comes down to preference.
If you are caring about performance especially for static files, you could add caching layer as a proxy in front of your backend nginx or a server of your choice .. Varnish-cache is a good choice.
If you want to serve static files at large scale, there is yet a better solution through which you could host your static files in CDNs that will be much better solutions for your live deployments .. Clouding services are built for ease of use and also cost effective for example fastly.com is a good choice for hosting static files with a very persistent cached layer that is built on top of Varnish-Cache .. Cloud front is also another choice if you are fan of Amazon services.
More resources that might help is a comparison benchmarks having popular servers, also another benchmark existshere
I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?
Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.
It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.
Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.
Based on my understanding, only I/O in NodeJS is non-blocking. If we do, for example, lots of heavy math operations, other users cannot access to the server until it's done.
I was wondering if there is a non-blocking way to do heavy computation in NodeJS? Just curious.
If you have long-running calculations that you want to do with Node, then you will need to start up a separate process to handle those calculations. Generally this would be done by creating some number of separate worker processes and passing the calculations off to them. By doing this, you keep the main Node event loop unblocked.
On the implementation side of things, you have two main options.
The first being that you manually spin off child processes using Node's child-process API functions. This one is nice because your calculations wouldn't even have to be javascript. The child process running the calculations could even be C or something.
Alternatively, the Web Worker specification, has several implementations available through NPM if you search for 'worker'. I can't speak to how well these work since I haven't used any, but they are probably the way to go.
Update
I'd go with option one now. The current child process APIs support sending messages and objects between processes easily in a worker-like way, so there is little reason to use a separate worker module.
You can use Hook.io to run a separate node process for your heavy computation and communicate between the two. Hook.io is particularly useful because it has auto-healing meshes meaning that if one of your hooks (processes) crashes it can be restarted automatically.
Use multiple NodeJS instances and communicate over sockets.
Use multiple node instances and communicate over node-zeromq, HTTP, plain TCP sockets, IPC (e.g. unix domain sockets), JSON-RPC or other means. Or use the web workers API as suggested above.
The multiple instances approach has its advantages and disadvantages. Disadvantages are that there is a burden of starting those instances and implementing own exchange protocols. Advantages are that scaling to many computers (as opposed to many cores/processors within a single computer) is possible.
I think this is way to late, but this is an awesome feature of nodejs you've to know about.
The only way abot multithreading is by spawning new processes, right so far.
But nodejs has an implemented message feature between spawned node-forks.
http://nodejs.org/docs/latest/api/child_processes.html#child_process.fork
Great work from the devs, you can pass objects etc. as message to your childs and backwards
You can use node cluster module.
https://nodejs.org/api/cluster.html
I would use JXCore - it's a polished nodejs based engine which runs your code but has several options including the multi threading you are searching for. Running this in production is a charm!
Project's source: https://github.com/jxcore/jxcore
Features include:
Support for core Node.JS features
Embeddable Interface
Publish to Mobile Platforms (Android, iOS ..)
Supports Multiple JavaScript Engines
Multi-threading Capabilities
Process Configuration & Monitor
In-memory File System
Application Packaging
Support for the latest JavaScript features (ES6, ASM.JS ...)
Support for Universal Windows Platform (uwp) api