I have a question - does anyone has any benchmark data re. using Express JS framework vs pure Node.js?
Is this something that even should be considered -- or using Express or similar framework is definitely a MUST if you're building a more or less large web app?
EDIT:
The article I linked to below disappeared, and I couldn't find it after searching around a bit. However, in lieu of that, here are a couple of relevant references with sufficiently scientific benchmarks:
https://github.com/koajs/koa/blob/master/docs/koa-vs-express.md#is-koa-faster-than-express
http://serdardogruyol.com/?p=111
http://qzaidi.github.io/2013/07/20/surprises/
Although this doesn't answer the delta part of your question, there's some absolute statistics about ExpressJS performance here:
Updated Link
http://blog.perfectapi.com/2012/benchmarking-apis-using-perfectapi-vs-express.js-vs-restify.js/
Looks like, on a small Amazon instance, Express averages:
a very respectable 1,600-1,700 requests per second
Express is a convenience wrapper around node.js, and should not add much latency to your server; your code would probably go through many of the same steps anyway. That being said, if your load tests (or hapless customers) find the server is too slow and/or not scalable, then you should profile at that time, and the bottleneck probably won't be Express.
BTW, even though Express calls itself "high performance", they're naughty for not posting measurements.
Related
i want to create a website based on node js and mysql , but i've read that there is a framework called express for node js , and i'm wondering if i must to use such kind of a framework to create a decent website or it is possible without it and just work with pure node js.
No framework is required. You can write a full-blown web server using only the http module or if you really want to write everything yourself, you can even do it with only the net module.
It's really about what is the most effective use of your time and skill as a developer. Except for academic or pure learning experience reasons, if you're just trying to accomplish a task as efficiently as possible and free, pre-existing, pre-tested code exists that makes your job easier, then that's a better way to go.
For example, if I need to do a file upload from a browser to my back-end and the data is coming in as the multipart/formdata content-type from the browser, I have zero interest in reading and learning the multipart/formdata RFC then writing my own code to parse the multipart/formdata content-type. Pre-existing, already tested code exists to do that for me and I'm adding no value to the goals of my project by re-implementing and then testing it all myself. Therefore, I'd like to use a pre-built module that does all that for me. I can just configure the right library on the right route and out plops my uploaded file in only the amount of time it takes to understand the interface to the 3rd party module and how to use it properly.
This is where Express comes in. Not only does it offer a useful set of features and architecture for configuring routes, installing middleware, sending responses, using template engines, handling errors, etc... but there are also thousands of third party modules that are built to hook into Express and it is easiest to use them if you're using Express as your core framework. Some of these modules could be used outside of Express, some cannot - it really depends upon how they're designed and what Express interfaces they do or don't use.
Also, Express is fairly "un-opinionated" and fairly "lightweight" which means it doesn't force you into a particular methodology. It just offers you easier ways to do things you were already going to have to write code for yourself.
Look at it this way. When you get node.js, there are thousands of APIs that offer lots of already tested things such as a TCP library, a file I/O library, etc... Those are frameworks (in a sense) too. You don't have to use them either. You could rewrite whatever functionality you need from scratch. But, you wouldn't even think about doing that because tested code already exists that solves your problem. So, you happily build on top of things that are already done.
One of the BIG advantages of coding with node.js is getting access to the tens of thousands of pre-built modules on NPM that already solve problems that many people have. Coding in node.js with a mindset that you will never use any outside modules from NPM is throwing away one of the biggest advantages of coding with node.js.
could you tell me what are the Routes used for in frameworks?
A route is a URL that you wish for your web server to respond to. So, if you want http://myserver.com/categories to be URL that your server responds to, then you create a route for /categories so that you can write code for what should happen when that URL is requested. A framework like Express allows you to create that route very simply with just a single statement such as:
app.get('/categories', function(req, res) {
// put code here to handle that request
});
This is just the tip of the iceberg for what Express supports. It allows you to use wildcards in route definitions, identify parameters in urls, create middleware that does prep work on lots of routes (such as check if the user is logged in), etc...
You don't have to use a framework but it is recommended to use one of them since frameworks like Express make your life easier in many ways. Check this: What is Express.js?
Yes you CAN write a Node.js-based backend without any back end implementation framework such as Express. And if you are using Node.js for the first time without any previous experience of asynchronous coding, I'd advise against using Express, KOA or other Node implementation frameworks for your simple learner apps (e.g. those needing things like register/login form processing, logout button, user preference updates to database, etc) because:
(1) Node.js is a core skill for JavaScript back ends.
Stupid analogies between server tasking and restaurant waiters are no use to a real web engineer. You must first know what exactly Node can/cannot do in the server CPU that makes it different to most other back end technologies. Then you have to see how the Node process actually does this. Using Express/KOA/Hapi/etc you are sometimes effectively removing the mental challenges that come with a Node back end. Any time-saving is achieved at the expense of gaining a proper working understanding of what Node is and how it really operates.
(2) Learning Node.js and its asynchronous coding is hard enough without the added complication of coding with an unknown framework like Express/KOA that assumes users' familiarity with JavaScript constructs like callback functions and Promises. It's always better to learn something in isolation so you get the essence of its individual effects, rather than the overall effects if used with other packages/frameworks. So many of these Node.js Express tutorials are the software equivalent of learning to make a cake by watching Momma do it. We can copy it but we don't know how or why it's working. Professional coders can't just be good copycats.
(3) Available learning tutorials using Express often drag in other technologies like MongoDB, Mongoose, Mustache, Handlebars, etc that make learning Node.js even more awkward still.
(4) A share of basic web apps can be written more efficiently with Node.js, custom JS and existing JS modules imported off the npm repository rather than with Express.
(5) Once asynchronous coding and the JavaScript constructs available to assist with it are understood clearly, pure Node.js apps for basic tasks aren't that hard.
(5) After you do get your head around Node.js and can get basic web app functionalities working using server-side JavaScript constructs, you can then judiciously start to explore Express/Hapi/KOA/etc and see what an implementation framework can do for your workflow when doing larger projects needing numerous functionalities. At this point you know what Express code should be doing and why it is done the way it is.
Node.js has become the back-end technology of choice for most small to medium scale web applications over the last 10 years. It is also the major reason why the JavaScript language has evolved from a mere front-end scripting tool with a limited set of Java-aping constructs to the innovative and comprehensive language that it is today. It is also the most popular language in use today. Investing time in understanding the Node server framework, and the latest JavaScript constructs used in Node, is time well spent. Implementation frameworks such as Express, KOA, Hapi, Sails, etc have great benefit when writing more elaborate back ends on the Node.js platform. But all these implementation frameworks are predicated on the behaviour patterns of Node.js. So unless Node itself is understood first, the full utility of Express/KOA/Sails/etc will never be enjoyed.
Try here for the pure Node.js.
I'm wondering if some of you veterans could provide some guidance to some of us noobs.
Is there any advantage to writing vanilla Node over using Express? More specifically, any particular scenario where using Express will not be an option? And lastly for the tasks that you can use Express for, how deep should you go within the layers of abstraction to find out what's going on?
I mean there are plenty of people who can create robust and powerful web applications and they have no clue what the hell Express is actually doing for them.
Much appreciated
If I were you, I'd use express.
To be honest, Express isn't much of a web framework. It's really barebones, and barely adds any functionality on top of Node core.
With this said, however, there are some benefits:
For better or worse, express has become the 'defacto' default web framework for Node developers. There's a lot of information about it.
Express provides some core things that are useful: a routing layer (to map functions to URLs), an 'application' object that you can bind variables to for settings, etc. -- and a simple middleware model that lets you add functionality to your app easily.
Because express is so close to 'barebones' node, you can still write raw node code to work with it. It isn't at all complicated like other 'larger' frameworks: django, rails, etc.
There are a TON of third-party express middlewares you can use which add all sorts of functionality to your site. This makes building your site easier.
Finally -- the biggest reason to use express is that it does almost nothing. It isn't significantly different from using raw node except that it provides some simple abstractions over lower level stuff.
Because express is so simple, it means you don't need to learn much to use it, and can write your app in whatever way you want (it doesn't enforce any sort of patterns).
I'd like to add a few things here that might help you out. One thing that I have come to realize with software engineering is that there is never a "catch all" answer to a lot of these types of questions. Since each application is different, it is a good idea to look at the challenges and figure out what is the best tool for the job.
If you look at some of the performance tests done on the frameworks you notice that vanilla node is ultra performant. But most of the time your application isn't going to need to handle 8000 requests per second, and even if it does you can always scale your server horizontally nowadays. So you trade off a little bit of speed to gain a few benefits, such as:
Much easier to write.
The code base, in my opinion, is much easier to maintain.
A lot of the little gotchas are taken care of by the framework so you don't have to be a Node.js god.
Middleware.
Now, that doesn't mean that every single application should use express. A lot do because it is about as barebones as it gets. For instance, Walmart created Hapi because they claim that it is easier to maintain their code base with a 'configuration first' approach. So maybe if you are going to have this monster backend and a monster team, Hapi might be a good choice. If implementing something with real-time you might want to use something like socketcluster.io to help you scale websockets. It is all about picking the right tool for the right job.
That being said, there are advantages to building a server with vanilla Node, especially when learning to develop node apps. Since frameworks abstract a lot of the lower level stuff it takes away the opportunity to pick up some cool node tricks here or there. Or a lot of times if a framework is insufficient or an npm package is doing something weird it is good to have that knowledge of vanilla node under your belt to really understand what is going on. Having the skill of knowing how Node.js works is such a benefit when working with any framework.
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.
Evaluating Nodejs and trying to see if it will fit our needs. Coming from a rails world, I have a few unanswered questions despite searching for a long time.
Whats the best way to manage assets with Nodejs (Expressjs)? In rails, the static assets are a) fingerprinted for caching forever b) js and css are minified 3) scss is compiled down to css
Whats the best way to handled uploaded images from users such as avatars?
Does grunt help with minifying and gzipping html/css/javascript?
How can I avoid mutliple http requests to the server with Node. I don't want to make multiple http requests for every javascript asset I need. Rails helps here by combining all js and css files.
Also, is Mongodb the preferred solution for most projects? I hear a lot of bad things about Mongodb and good things about it. Having a difficult time deciding if Mongo can help with more reads than writes with probably 400-500 GB data in the long run.
Any help or pointers? Thanks so much for taking the time to point me to the right places.
For each of the point you mentioned I give you a few module examples that might fit your need. Remember that at every point there are much more modules serving the same purpose:
node-static (as a static file server), node-uglify (for minifying JS code), css-clean (same for CSS), merge-js, sqwish, and jake can help you with the building of the website (in this step you could plug-in the previous modules)
node-formidable is pretty famous
check out this question
checkout this question
I am not sure if it is the "preferred". It is the noSQL and the Javascript nature in it that makes it attractive. There are modules already for every type of database. ongo should handle that data. Depends also how large is one document. There are some limitations.
There is this Github Wiki page in the NodeJS project listing and categorizing many of the important modules out there.
The exact choice of modules also depends what framework will you use use to build the app. A pretty established (but certainly not the only one) is express. But you can find more on this topic here.
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.