I have just began working with node.js and have gotten the hang of the basics.
Right now I'm trying to see if I can create my very first real-time web application using node, during my research I have seen modules like "express.js" and "socket.io' pop up very often as frameworks used for node web apps.
My question is; do I really need to learn these two in order to make real-time production level node.js applications?
Also, what other things should I look at? I heard about tempting engines being an asset, but 'm not sure of their use.
You don't need to use any modules but you give up a lot when you don't. Express.js is a great place to start. It has good documentation and makes the whole process much easier. I use jade and stylus for my css and templates.
Socket.io is again optional but if you are doing real-time updates it sure makes things a lot simpler. Socket.io deals with all of the browser differences with one api and the client will always connect using the fastest technology.
Socket.IO is mandatory for real-time applications. If you have to implement a chat, a broker, a server status tool or something like that and other natural real app, you must consider use this Node package. If your site do not require something real-time bi-directional message handler you just avoid the usage of this tool.
In case of all application needs to be made in real-time situation, you can see a more appropriate framework to approach it, like Meteor
Related
I'm new to the full stack javascript application development, have read a lot of posts and documentation to all sorts of things but am a bit stuck on the following issue:
There are two frameworks that seem to offer quite similar functionality but are never contrasted against one another on the internet (as far as I could tell)
SailsJS - server side MVC framework built on Express
BreezeJS (+AngularJS) - client side MVC
Apparently I can combine Sails with Angular, there are a few attempt in NPM but none using Breeze in addition, is that due to redundancy or is it just a stupid idea?
I was thinking of developing a SPA that has computation intensive backend processes ( e.g. machine learning on large data sets ~ millions of mongo documents ) on something like
Mongo - Node : { Express - Sails } - Breeze - Angular
I'm looking for feedback on whether this kind of stack (particularly the Breeze / Sails part) is a bad idea or not. Also I'm really thankful for any advice / links to advice on javascript full stack architecture design decisions.
Thanks!
Basically, all the software you have mentioned can be used in one product. It's the important though to understand the purpose/strength of each component:
1. MongoDB
This one is pretty clear: database engine.
2. Node.js
This one too: server-side Javascript which will power your API.
3. Express.js
Now it's getting more interesting. Express is a server-side web-application framework for Node.js, but a very minimalistic one, which means it provides some basic functionality, no hidden magic and other fancy stuff.
4. Sails.js
On the contrary, Sails provides a lot of magic, starting with the API out of the box and ending with sockets. Even though it's built on top of Express, Sails is a server-side Javascript framework which follows a completely different approach, with convenience over simplicity. If we talking about a SPA, then the most useful thing Sails has to offer is, definitely, API out of the box: you'll be able to get it up and running in less then 5 minutes.
5. Angular.js
Here we are getting onto the client side. Angular helps you better organize your client-side Javascript and easily perform some pretty complex tasks in the browser. And, of course, Angular (or a similar framework, like Backbone, Ember, Knockout, etc.) is a must-have nowadays if we are talking about rich client applications.
6. Breeze.js
Finally, Breeze provides you with a way to organize / access data from your thick client Web application. Whether you are using Angular, Backbone or Knockout, Breeze will help you manage your data in a way similar to ORM / ActiveRecord concepts.
So, all these components can easily work together, no doubts (sometimes people are talking about MEAN, MEANS, BMEAN stacks, where every letter is a first letter in the name of a framework / component). But ultimately, it's up to you to decide how many of them you should use in your product. As an example of approach, you can start with Mongo / Node base, and then choose necessary frameworks by asking yourself for the each one, whether it simplifies your life (especially, long-term-wise) or complicates it.
We have a grails application in the wild. We'd like to give users using current browsers a better experience and provide some auto-updating of pieces of the site. Looking into all the options and specifically with Grails, I'm not impressed.
I really want to use WebSockets and from the investigating I've done up to this point I believe our best option is Node.js. But obviously we can't redo our application. I like Grails.
So my idea is that we use Node.js along side Grails to basically act as a READ-ONLY proxy between the client and the data. All the Node.js application will do is pull data from the database and deliver it to the client over WebSockets.
Does that sound like a valid approach? Is this something anyone else has done?
Certainly sounds reasonable; I'd suggest using socket.io to implement your transport (it will use WebSockets if the browser supports them; otherwise it will transparently use various fallback mechanisms). You might want to use a reverse proxy like nginx to avoid any cross-origin problems, though socket.io is fairly good at avoiding them.
Node is very much about letting you use the right tool for the right part of the job, rather than being a Golden Hammer.
We aren't using websockets, but we have an Angular app that talks to the grails via REST calls, which we expose using controllers.
I want to create a chat app which would use php/codeigniter to do the views and user interface. I've been reading lots of posts on stackoverflow which recommended node.js or socket.io. Yet I've also run across APE(Ajax Push Engine). I don't really know much about either and was wondering which to use.
I read up on node.js and saw lots of good things about it, but the major thing about it that worries me is that it's relatively new and doesn't have lots of real world websites testing/using it.
On the other hand, APE does. And it looks similar to node.js. But like I said, I don't know enough about either to know which one to choose.
Which one is better at creating a chat app?
Thanks!
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
Like you, I'm not familiar with APE, however socket.io on node.js comes with a chat app as it's main example app.
True, there aren't a lot of sites using Node.js right now. Socket.io, however, is probably considered Node's 'Killer App', and thus has relatively a lot of talk/work done with it.
I'm presuming APE has stable APIs, though, which socket.io might not necessarily have - The 0.7 version was a pretty broad, API-changing update, for example. This might happen less often with the publication of the socket.io spec.
I've build several websites using PHP and mySQL as backend, and believe that I'm fairly familiar with both. However during research for my new website I've come across node.js and mongodb (and socket.io, since the site is gonna contain a chat).
I've decided to use node.js and mongodb to run the chat - but don't know if I should just do the entire site with those two things?
Since I'm gonna run a node server anyway should I just run another (seperate) one hosting the website? Or is that an bad idea? - is it stable?
I could do the programming in PHP and still be using mongodb - but wouldn't node be way faster?
And another question:
I've planned to use ajax to handle all the posts to the page - but since I'm allready using socket.io to the chat - should I do all my post request using that?
For the ajax I've planned to use jQuery (also for all frontend effects).
don't know if I should just do the
entire site with those two things?
If you want to learn node.js then there is nothing better than coding it.
Since I'm gonna run a node server
anyway should I just run another
(seperate) one hosting the website?
You can use existing server and run your node.js app on other free port(o). I think for learning node you don't need to have dedicated machine.
is it stable?
Even versions of node.js are stable releases, however until there is 1.0 with feature freeze there could be breaking changes to its API.
I could do the programming in PHP and
still be using mongodb - but wouldn't
node be way faster?
It most probably (and definitely) would.
I've planned to use ajax to handle all
the posts to the page - but since I'm
allready using socket.io to the chat -
should I do all my post request using
that?
I would recommend stick to MVC model and use express since you can get into lot of time consuming troubles if you would use socket.io for classic stuff. Socket.io is namely for real-time functionality and things related to that.
There are already some solid web frameworks for node.js, in particular check out Express. Here's a really good article outlining some lessons and experiences from building a node.js website:
What it’s like building a real website in Node.js
Regarding your second question, it's probably still best to use AJAX handlers and HTTP with jQuery. I'm not sure that jQuery supports callbacks over raw TCP sockets.
node.js + express + jade + stylus + jQuery is my preferred environment.
Using forever to auto restart the server I've never had any real up-time issues even when I have bugs crashing the server on a regular basis.
As for socket.io + jQuery, they do get along fine, but it's just not as natural as the express + jQuery combo. I'd stick to making ajax calls for most things.
Node.JS can still be a little wild west like, but its improving. It is a very different model from coding in php, but it is very well suited for a lot of websites. You'll probably want to do the thin server (expose a REST API and your websocket endpoints) with a fatter client using something like BackBone.js to keep interactions clean.
The big win from doing the whole thing in node is that you will not have duplication of code between php and js for dealing with the DB or any other services required by both. Node.JS is also fantastic at handling tons and tons of concurrent requests.
Good Luck
I want to work with WebSockets in Node.js web app, and I am looking for the easiest way to do this. I've seen so many github repositories seemingly providing some ease of use.
But, I'm just looking to see if there's one that stands out as having the most support, or most widely implemented.
I was kind of leaning towards Socket.IO but I'm not entirely sure.
Any advice?
Thanks!
use now now or socket.io.
now is an abstraction build on socket.io which allows you to define methods on a shared object across client and server. This means you dont have to interact with the stream manually and can just seemingly call methods. Do read their best practices before use though.
now also has a grouping system in build which means you can talk to clients in groups rather then one or all.
socket.io itself is recommended because of it's excellent browser support with its range of fallbacks. It's also owned/maintained by a node.js startup so it's more likely to be maintained in the future. And it also has a range of server-side socket.io implementations for platforms other then node.js so you can use the same API on multiple platforms.
If you find socket.IO too large or bloated you can go for the lightweight websocket-server. This is just a simple websocket implementation and is reasonably stable. I have personally used this if I want something which is a very minimal abstraction and if I want more low level access to the websocket server itself.
Take a look at this blog post, it's very informative...