Sorry for the rather ignorant question, but I'm a bit confused regarding these two technologies. I wrote a webserver in C# that uses Fleck and everything works great but I realized I probably couldn't find a hosting provider that would run .NET applications.
I want to use websockets and I found socket.io to be really popular but I'm not sure exactly what it is. Correct me if I'm wrong, but, is it just like writing a server in javascript and you run the javascript file with the node.exe application and then the server is running? How do people find hosting providers that will provide that sort of service?
Lastly, is socket.io just an extension of nodejs? Do you have to code your server in javascript when you use socket.io? Again, sorry for the very novice questions but I'm just trying to understand a few basic things before I continue. Thanks.
There are a few companies that will host your node application. Its not the same as your transitional web hosts where you provide them with files and they serve the files for you. When working with node you're writing the actual web server.
Some of the popular ones around are below:
https://devcenter.heroku.com/articles/nodejs
http://nodejitsu.com/
http://nodester.com/
#Roest: A virtual server sounds intriguing. What are the pros and cons
of such an approach? Also, considering how popular nodejs is how can
its webserver hosting support be so limited? How do people use it?
When working with a virtual server you have full rain over what your running on the server.
Pros
Freedom, you get to pick all the software you want to run on your machine. A lot of the times when working with nodejs you're going to want some custom software to be running along side your application. Most of the time this is your database layer, which ever you choose.
Cons
YOU have to maintain it. Like #Roest stated, this isn't much of a con for most people as this ties directly into the freedom a virtual server gives you but it is something you need to take into account.
I think the reason you see limited support for nodejs is because its relatively new, and its so easy to setup yourself.
I want to use websockets and I found socket.io to be really popular
but I'm not sure exactly what it is. Correct me if I'm wrong, but, is
it just like writing a server in javascript and you run the javascript
file with the node.exe application and then the server is running?
That's pretty much exactly what nodejs is, or at least how you use it. Nodejs itself is Google's V8 javascript engine running on your server, along with a large number of libraries and C bindings that allow you to interact with your server in a way that the V8 engine won't let you.
This is an example of a webserver in nodejs (A very limited one)
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
It just responses Hello World to every request and always returns a 200 status code.
Going from something like this to a simple file server is fairly easy and quick, but a few people have already tackled this problem for you.
http://expressjs.com/ - Very powerful web server, but still gives you a lot of freedoms.
https://github.com/nodeapps/http-server - Simple web server, I use it mainly as a command line tool to instantly server files over http.
Lastly, is socket.io just an extension of nodejs? Do you have to code
your server in javascript when you use socket.io? Again, sorry for the
very novice questions but I'm just trying to understand a few basic
things before I continue. Thanks.
socket.io among many others is a module of nodejs. Depending on your definition of extension it may be the wrong word to use. Most of the time when using socket.io you'r going to be using an existing http server and then extending, or wrapping your server with socket.io. I wrote a previous explanation of how nowjs does this. My guess is socket.io is very similar.
To answer the bulk of that question: Yes, you will still be writing your code in javascript. You will just be utilizing the socket.io API.
#travis has already covered everything you need to know about node and socket.io
I'd only like to say that you don't have to buy a special hosting dedicated for node.
My game is hosted on VPS with Ubuntu
I find it really easy to deploy and maintain. There is a package for Ubuntu and instalation takes literally four lines of copy/paste
https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
ps: I am not using socket.io but einaros/ws library which I find much less overblown.
Related
I am a beginner to web development - I am building a website that requires some entries from the user, does some complicated mathematical processing on those entries, and returns the result to the client. I was thinking of implementing the mathematical stuff in another separate application which is better suited for such work (like in Java or C++ where there are good math libraries and the implementation would be more robust and faster). I was wondering what is the best way to do this, architecture-wise.
The "dummy" approach would be spawning a process from the Node.js application and waiting on its output from stdout, parsing it (probably in JSON) and then processing it before sending the result to the client. I have trouble believing that this is the best way to do this (it seems too error-prone, no proper error handling, dependent on the output, and just plain bad practice). A slightly better approach would be to have the Java or C++ application listening on a specific port and waiting for requests from the Node.js application. However this requires more thinking in terms of load-balancing (how would it scale with the number of requests?). Finally, the last approach I found online was to use a queuing system such as RabbitMQ as a way to communicate between the Node.js application and the Java application.
Typically (in a "traditional" software), implementing a separate library that holds all the math magic to which we can make calls would be a good way to go.
What is the best approach to achieve this with a Node.js/web application? There must be good practices/models/architectures/designs for such a problem. Thanks!
The best approach I can think of is writing a native nodejs module, you can use C++ and any library you have to write the code and export some APIs to be called from node's javascript.
This also allows you to package your native application as a module for nodejs, which can then be distributed and compiled/installed with npm.
Here's the official tutorial from node's website.
It isn't the easiest approach, but certainly the more elegant and mantainable one.
IF your problem can be structured in a stateless way -- i.e. you send a request out with the data and the associated task, and then later receive the result as a response, I would probably create one angular app for the front end, and multiple node servers for the back end (IF you needed to handle many requests simultaneously).
As pointed out in the first answer below, you can put whatever parts of the problem that you want to into native code, BUT what might be much easier is to use sockets to connect to a server to do the computation, in any language, etc... In one project I use a socket.service to handle all the communication back and forth to the servers. (The angular-fullstack generator in the next paragraph has such a skeleton socket.service piece.)
In terms of the frontend in combination with a node backend, The Yeoman generator (http://yeoman.io/generators/) for creating MEAN stack applications, using MongoDB, Express, AngularJS, and Node - lets you quickly set up a project following best practices. And the angular-fullstack generator will give you a framework that is light years ahead in so many ways. You can use yeoman to generate a sample application frontend (angular, express) and backend (NodeJs, MongoDB) with support for sockets, etc...
This too is not very simple, but in the end, with a few months of work, you would have a structured problem and solution that you would never outgrow. When I first wanted to work into this space, that was the path I took. And in truth the front-end was/is the harder part and the backend, connected with sockets, http, or whatever has gotten to be much simpler. In terms of servers, AWS, or even just nginx on Linux through DigitalOcean or many others is inexpensive and flexible.
I hope this helps.
So I am generally quite new to the MEAN stack and had some questions regarding compression with the NodeJS / express combo.
After digging around I noticed it is not feature that is widely used and it had some issues in the past (zlib) and also has now been separated out in Express 4.0
Having also spotted the documentation for the compression module: https://github.com/expressjs/compression
I have to say, the 'Server-Sent Events' code example raises an eyebrow with the setInterval method. I guess that is mainly for streaming the data rather than giving it one go but still seemed a little strange at first.
So for those who are using this set-up and stack with the above module, can anybody notify me of any gotcha's or issues to be aware of as searching around hasn't given me anything recent.
FYI, I am primarily looking to use it for large amount of JSON transfers and maybe smaller HTML static as well later.
I would also be interested to know what else people are doing for compression if they are not using the above.
I wouldn't put zlib compression on within my application. I would leave it at the web server level where it is highly optimized.
A lot of folks make the mistake of using their Node.js server's HTTP server as their primary serving method. This obviously works, but you can make things more efficient by putting a proper web server, such as Nginx, out in front. Why tie up your application with spoon-feeding slow connections, compression, caching, authentication, etc.
Think of the HTTP server in Node.js as a replacement for CGI/FastCGI. While it can be used as a general purpose HTTP server, you're better off using it as the communication protocol between your application and your web server for most web applications.
(Obviously there are exceptions to this... not all Node.js apps even have anything to do with web serving. Use your best judgement when architecting your app.)
I found node zlib to be quite slow for my intended use.
This is what I tried to use it for:
take a multipart form post with attached files
pipe it through zLib and crypto (aes-128-ctr) to Amazon S3.
After some timing experiments I found out that the encryption part is quite speedy. It adds only about 5-10% to the total transfer time from client to S3.
ZLib on the other hand adds about 50% to the transfer time. I ended up not compressing the files. Storage on S3 is cheap.
im looking forward to build RT web apps with NodeJS. Coming from Rails, I've felt in love with NodeJS and Async JS programming.
Run a few experiments with Node, and then as I search tools and resources to get used with, I got overwhelmed with the lot of stuff over there.
I found lot's of libraries and components over there, and pretty much got confused on how a large-scale well-writen and implemented RT web app should be built.
So the app will run over NodeJS, using Express framework.
I read about knockout.js, a client-side library to provide realtime stuff like automatic UI refresh, and I guess I could conbine it with jQuery.
Also, I found socket.io.
The author says:
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript.
So socket.io is about compatibility.
What about backbone.js? Where does it goes to?
With so much stuff, I got shocked. What should I learn? Which modules worth studing?
Im focusing on NodeJS and Express but most books/screencasts covers old versions of nodejs. So im being guided by its official API.
Now im here asking your advice and to organize somehow all the info out there.
Correct me if my assumptions are not precise, please point me to the right direction and feel free to suggest any other module that could help on my learning.
Thanks in advance
It might be useful for you to separate the node.js server side libraries (via npm etc...) from all of the client side (browser) libraries and technologies like jquery, backbone, knockout etc... when you think about it. Even socket.io which exposes a persistent socket connection between the browser and the server (to avoid polling) does not dictate what client side technologies you use.
Focus on exposing a solid web-api ( random example ) from your server and your client technologies can be swapped, augmented etc... with no effect on the server. The only place they intersect is if you're using a view technology like Jade. It's also an option to have a pure separation where the server is just serving up the client files and your client is a thicker javascript application (using knockout, jquery etc...) calling a good server web api.
Some folks try to unify the client and server models - for example, this article using backbone and node. It depends on how much data you work with to say whether that's feasible but it does couple the client and server and makes the server stateful which can have downsides (scale out, requires affinity etc...). Personally, I get wary of that much magic (binding, state, syncing etc...). Node is about keeping things simple, light and fast. It's a fast front end network server.
My 2 cents (and some may disagree). Start with node on the server and pick your storage (mongoDb etc...). Design a solid RESTful (hypermedia) API - a good webapi regardless of the client. Then start with a basic html/css/js, maybe jquery client and add things like knockout etc... as you expand your client skills. That will allow you to replace your client technologies independent of your server as the new technology winds change (and they will).
That's the hallmark of a well designed system - the ability to replace componets/sub-systems without rewriting everything :)
Hope that helps clear up some of the fog :)
You may want to look at Meteor if you are focussing on real-time Javascript apps: http://meteor.com/
I know that node.js is said to be "event-driven I/O" server-side javascript hosted on V8 Javascript engine. I visited the node.js website, and then read the wikipedia entry, but cant quite get the whole idea of where to use it and how it will be useful. "Event-driven I-O"? "V8 Javascript engine"? In some context though, I see that using "server-side" javascript as a little overkill..I take for instance this piece of code in the wikipedia entry of node.js:
var http = require('http');
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello World\n');
}).listen(8000);
console.log('Server running at http://127.0.0.1:8000/');
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks
The node.js server is, in simple terms, a replacement for something like the Apache web server - but it is largely written in JavaScript which runs on the server (executed by the V8 engine) rather than on the client side. It can be extended with 'native code' modules (written in e.g. C++) wrapped in a JavaScript interface to add functionality, but AFAIK most node.js modules are pure JavaScript.
"Event driven I/O" is just a term that describes the normal asynchronous callback mechanisms you're used to in JavaScript. In node.js you supply callbacks for all sorts of things, and your function is called when the relevant event occurs.
Depending on how many modules you add, a node.js server is relatively lightweight compared to something like Apache, and in some ways a lot simpler.
The two main advantages to node.js I see are:
It allows you to write both the server-side and client-side parts of a web application in the same language. In some cases you can use the same code on both sides.
It makes server-side coding accessible to all those web developers out there that know JavaScript without having to learn a more common server-side language like PHP or Java.
Here's an article I just came across that might also shed some light: What is Node.js?
While I can't add much to what #sje said, I will repeat that blog link he shared, as that is the best resource that I've found to explain nodejs quickly:
http://radar.oreilly.com/2011/07/what-is-node.html
Also note that it's from OReilly, who most of us know as being the publisher of the best references for programmers on the market in general ;)
I have been thinking, is there really a significant purpose in running a server that particularly serves javascript files that are executed in the front-end part of the application?
This is totally wrong. This is the most wrong assumption about node you could make. Node runs the javascript on the server much as ruby or php or asp.net code is run. The fact that the browser can also run javascript has no bearing on node.
Granted, you can share modules between the server and the client (for instance, validation routines for form data) but by and large the codebases are different as they are intended for different things.
I also forked the node.js repo in github to learn more about how it works, and it turns out that some of its modules are written in C++. So it is not a javascript after all then?
Yes, node is a server that interprets javascript using the V8 engine. It has to be written in something. I'll give you a comparison: Microsoft .NET code is mostly written in .NET on top of .NET, but the main code that actually does the work, the runtime (the CLR as most people refer to it) that manages the managed-code, that code is written in C. The same thing with node. Yes, most of it (as you saw) is written in javascript, but the core libraries that run everything else are written in C.
Can somebody give me a clear explanation about all this? Sorry if the question is not clear or something, I am just a beginner. Will appreciate any input/suggestions. thanks
I hope this helped clear it up in part. There's a lot to cover, and without going into evented-io (which involves understanding processes and threads and io access and a lot of other stuff) this is pretty much the basic high-level answer to this question. I invite you to the nodejs room on the chat server here if you like, for more random discussions that are fluid. https://chat.stackoverflow.com/rooms/642/node-js
As to the first question you asked:
Where does it fit in?
The same place ruby and php and perl and python and asp.net do. On the server, generating code that the client receives.
I haven't seen anyone give a simple answer to this yet.
Node.js is:
the v8 javascript engine
an event loop
some c++ bindings, among other things, that give v8 IO capabilities (both network and file IO)
It's important to note, Node doesn't necessarily have to be used for web development either. It's purpose is, "evented IO".
Could anyone that has used both share his/her experience? What are the main differences and which one do you prefer? Thank you.
Different socket.io vs APE:
socket.io is coded in javascript(node.js) while APE is coded in C. I believe that is a big difference when you want to contribute. Maybe because you like the project or maybe because you want some more functionality. I think it will be easier to contribute Socket.io because you program Javascript, which is easier to grasp according to a lot of people(I Agree, although C is also very cool language).
I believe socket.io supports a lot more browsers/transport compared to APE, but I am not sure. Socket.io information vs information from APE page:
APE Server is an Comet server
implementing the POST and GET methods
of the HTTP protocol. It does not
replace a regular Web Server (such as
Apache, Lighttpd or Nginx), however,
the APE Server is only used for AJAX
Push.
So I guess APE supports less transports then socket.io.
Like Raynos said it is difficult to compare those two products and I believe you should play with them both and then decide which one you like more.
Same Socket.io/APE:
You can both code in Javascript to communicate with the server. I think you will have more freedom using socket.io because everything is exposed via Javascript.
Experience:
I only have experience with socket.io and I like it a lot.
Having spent some time developing with Node.js, I can't say that APE appears to be better than node. Based on sheer popularity, it seems that Node.js is probably the developer's choice -- and node.js appears to be more versatile as well.
Node essentially is you making a full on HTTP or TCP/IP. So, all of the mime type handling, data buffering, response headers, and server side routing are all things you'll have to do with your code. Node does streaming as well. I'm not sure about whether this is considered less problematic than normal ajax long polling at this point.
After googling around, I've found that people consider APE to be more of just a plain ol' push server, in which comet functionality is already there to be consumed, rather than Node, which would have you write your own. Don't be afraid of the prospect of writing things out with node though, they've got a very thorough documentation, and their methods are very easy to learn. I had some serious functionality written out in minutes.
Check this out also: http://groups.google.com/group/nodejs/browse_thread/thread/9d9b301479851b1f?pli=1
I played a little bit with node.js, tried out socket.io - but in the end did a big project with APE.
I think, as always, there is the question of what you want to achieve.
Only comparing the server parts: With node.js you get a machine that won't do anything on it's own, you need to write it yourself (or use libraries)
With APE, the handling of channels and connections is already built in (compiled C). Still you need to build parts of your own logic on top with JS - or use the examples.
On the client side, socket.io provides a client framework with three commands - and APE has it's APE_JSF that handles the connections (which brings more functionality than socket.io regarding channels)
Personally, I prefer APE, even though there is a lack of documentation for beginners.
However, keep in mind that APE won't deliver files/images, it's not a full Web-Server but optimized for real time push where it can handle ~10K concurrent users