While I find node.js quite entertaining to use, I am still a beginner and need a lot of help from the documentation. However, lately, the problems I tried to solve are getting more complex, and so are the answers. Often, I find the explanations I need on this site, but the problem is that I cannot verify then on the documentation side.
A clear example: I wanted to set the process.stdin to read the keytrokes of the process. The question
nodejs how to read keystrokes from stdin
was very helpful and did what I needed, but something buggs me: in the node.js documentation, there is no mention that a stdin stream emits 'keypress' events. Am I missing a huge body of knowledge about node.js? If this site did not exist, how would one learn the stream emits 'keypress' events? Is the documentation just that bad?
No documentation is perfect. The node community has done a reasonably solid job with making the standard Node documentation cover the primary use-cases though.
Your specific example about keypress isn't great though. keypress is/was not documented because that event was not meant for public usage, and it was removed in more recent versions of node, which is why it is not in the documentation today. The answer you linked to is nearly three years old.
For the current stable version of Node, the keypress module provides that functionality, and it documents how to use it.
Related
What I want to do
I'd like to use Server-Sent-Events for notifications and another feature – I don't need to go into detail for the other feature, but it requires real-time updates taken from a database just like notifications do.
Possible alternatives
Websockets would be an option, but I think it might be a bit too much, as I only require a one-way channel for this. However I'm totally aware that I might be wrong here and Websockets could be the best option – feel free to school me on this. The current backend-setup is Node.js (Express.js webserver) with MongoDB.
Approaches I've seen so far
I've already seen some approaches on this matter, but the main issue here is that I'd like it to be as scalable as possible. Having a for-Loop constantly query my database is the worst approach I've seen so far. The best approach I've seen is observing the MongoDB oplog, but that one seemed a bit like a hack to me rather than a good, solid solution.
I posted a link to this question on reddit in the subreddit r/node where the user /u/PremJyotish221 told me to use Redis with PUB/SUB, and let me tell you... it works perfectly! :)
So to anyone stumbling over this with the same problem, I can absolutely recommend it. It's fast, easy, reliable, and scalable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been trying to create a mongodb server which will receive post requests and insert or read from a mongodb server and reply back. I have started with node.js. However while I was reading stuff, I have been realizing, people actually hate node.js. Many people are crossing to GO. So I am all confused now.
I have chosen node.js because of the natural json compatibility of javascript. However after all the things I have read, node.js sounds like a waste of time.
Could someone help me clarify my confusion ?
Thank you.
Edit : People refer to the problem of callback hell, and lowering performance of node.js once the business logic starts to be more complex than simple loops.
People refer to the problem of callback hell
This has never been an issue for me. You can use whatever structure you want in your code. Any promise library may be helpful if you find that you really need 1,000 nested callbacks, but this is rare in most circumstances.
lowering performance of node.js once the business logic starts to be more complex than simple loops
Rarely is this a problem. Most applications are IO-bound. If yours isn't, you have a couple options. One is not to use Node.js. Another is to compile a native extension for the specific part that's dragging you down (since you'll be writing native code to solve this problem anyway) and call it from the rest of your Node.js application. That way you get most of the performance of your native code but still get the flexibility of working in JavaScript.
Since you linked to that Reddit post, I'll address some of the comments there.
Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it :D
It's all relative. No doubt that weakly typed and interpreted anything is slower. It's a trade-off that you have to decide makes sense for what you're doing. Personally, it's far cheaper for me to fire up another box to handle the load than it is to rewrite all of the helpful modules and frameworks I use in Go. Maybe that's not the case for you, so you get to decide.
In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client.
This is generally true. I don't understand why shared client/server code is some sort of selling point for Node.js, as it isn't for most applications. I had one case where several classes I wrote for an RPC layer ran on both the server and the client. One thing I will say though is that there are a ton of NPM packages that run in both so if you get used to using a nice package on one, it will often times work on the other.
Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!
You don't have to learn Coffeescript to use an NPM package written in Coffeescript. Coffeescript compiles to JavaScript, and are used in your code the same way any other package is. Also, those same Coffeescript packages do run just fine in the browser since it all builds to JavaScript.
With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me).
It's up to you to decide if this matters for your use case.
The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.
Don't use abandoned junk, just like you wouldn't with any packages on any platform. It's very easy to see what's abandoned junk. NPM calls out what's been updated and when, whether or not its dependencies are up to date, and how many people are using that package. There are definitely a massive number of useful packages available for Node.js, just like they are for most popular platforms.
Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on.
That's not really accurate, and I'm really curious what's going on in this person's application where this is necessary.
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have been really playing with node.js alot here lately. I really like it and would like to get serious about building a site that I have in mind with it. There are just a few things that I had questions on. I am currently using express, cluster, mongoose(mongodb), and dust because it seems like the community is doing pretty well with this setup.
The first question that I have run into is making changes in the app. If I change one of the files in my app (with the exception of templates), I have to restart the app in order for the changes to show up. Is there something out there that will do this automatically or is there something I am missing?
The second question I have is, are there any really good resources out there that anyone can recommend. Seems like alot of the stuff that I have found through google just explains one topic and there are not alot of books on it yet(see some good ones releasing this year though). I was wondering if there was a really good resource for node applications (really interested in how people are structuring there applications and what they are using).
The third question or really feedback I would like to get is what good node modules should I be looking into using for my application. I really like cluster and running apache benchmarks with it versus without it I saw a double in the number of requests it could handle when using all 4 cores versus just the single core. I want to try and keep my code so that I dont have to write the logic twice for the backend / frontend which is why i have decided to use dust as my templating choice.
The last thing that I would like to know is based on an article that I read by linkedin (http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates). After reading this article I was just impressed by the ingenuity that they came up with to do this. I see many benefits from this by saving bandwidth on the server from not having to server process the files each time and letting the users browser do the load. It also will allow for less bandwidth throughput by not sending the whole template to the browser every time and caching it. But I am just stumped as to how they accomplished this. Can someone please shine some light on this subject or if you know of a good article that explains how to do this it would be great. I dont know for sure I would use this implementation but I would love to know how to do in case it is applicable.
Thanks for any feedback.
First question:
Actualy there are multiple tools that do the job starting from nodemon to supervisor
Second question:
Learning materials
videos: nodetuts
books: from node beginner and more books
podcast: nodeup
alot of great bloggers: laurenzo | Peteris Krumins about usefull nodejs modules | dailyjs and many more
grouped modules: toolbox.no.de (for unknown reason not working now)
Not to forget nodejs docs. Also browsing github and reading source for great nodejs modules or apps can be quite good for learning.
Third question:
i think my Second question answer includes this one also.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I finished watching Douglas Crockford's excellent series on Javascript, and in the final episode (so far), loopage he lays out why Node.js is a near perfect solution for server side code.
He talks about keeping state, not in the database, but in closures running in Node.js, he also states that templating systems (like JSP, PHP, and ASP) are a poor abstraction for more complicated Web Applications and that node.js provides a solution to this.
And I am ready to buy in, but I can't find any examples of Web Applications using this pattern, or any books or tutorials about how to go about doing this. I am not talking about a simple application, but something that would use the patterns that Crockford spoke of in his talk. Anyone know where I can find some tutorials/examples of Web Applications written in Node.js (and yes I know about Geddy and ExpressJs, but they don't seem to follow the radically different patterns that Crockford was speaking of, and were more like getting a Railsy experience on Node.js).
[Note from 3 years in the future: It seems like Express, Geddy, Sails, Kraken et all are re-implementations of the Rails/Symfony/Spring frameworks from Ruby/PHP/Java. Whereas things like Hoodie and Meteor are attempts at a whole new paradigm. KOA looks interesting, but is a ways away from being usable, but looks like it is building on the strengths of javascript with the history of MVC applications of the past. 3 years on and it is still exciting times for Nodejs, even if it is no longer the new hotness. At least there are a lot of real world examples of Node in use now...
I would suggest you check out the various tutorials that are coming out lately. My current fav is:
http://nodetuts.com/
Hope this helps.
The Node Knockout competition wrapped up recently, and many of the submissions are available on github. The competition site doesn't appear to be working right now, but I'm sure you could Google up a few entries to check out.
DailyJS has a good tutorial (long series of 24 posts) that walks you through all the aspects of building a notepad app (including all the possible extras).
Heres an overview of the tutorial: http://dailyjs.com/2010/11/01/node-tutorial/
And heres a link to all the posts: http://dailyjs.com/tags.html#nodepad
Update
Dav Glass from Yahoo has given a talk at YuiConf2010 in November which is now available in Video from.
He shows to great extend how one can use YUI3 to render out widgets on the server side an make them work with GET requests when JS is disabled, or just make them work normally when it's active.
He also shows examples of how to use server side DOM to apply style sheets before rendering and other cool stuff.
The demos can be found on his GitHub Account.
The part that's missing IMO to make this really awesome, is some kind of underlying storage of the widget state. So that one can visit the page without JavaScript and everything works as expected, then they turn JS on and now the widget have the same state as before but work without page reloading, then throw in some saving to the server + WebSockets to sync between multiple open browser.... and the next generation of unobtrusive and gracefully degrading ARIA's is born.
Original Answer
Well go ahead and built it yourself then.
Seriously, 90% of all WebApps out there work fine with a REST approach, of course you could do magical things like superior user tracking, tracking of downloads in real time, checking which parts of videos are being watched etc.
One problem is scalability, as soon as you have more then 1 Node process, many (but not all) of the benefits of having the data stored between requests go away, so you have to make sure that clients always hit the same process. And even then, bigger things will yet again need a database layer.
Node.js isn't the solution to everything, I'm sure people will build really great stuff in the future, but that needs some time, right now many are just porting stuff over to Node to get things going.
What (IMHO) makes Node.js so great, is the fact that it streamlines the Development process, you have to write less code, it works perfectly with JSON, you loose all that context switching.
I mainly did gaming experiments so far, but I can for sure say that there will be many cool multi player (or even MMO) things in the future, that use both HTML5 and Node.js.
Node.js is still gaining traction, it's not even near to the RoR Hype some years ago (just take a look at the Node.js tag here on SO, hardly 4-5 questions a day).
Rome (or RoR) wasn't built over night, and neither will Node.js be.
Node.js has all the potential it needs, but people are still trying things out, so I'd suggest you to join them :)
The closest thing is likely Dav Glass's experimental work using node.js, express and YUI3. Basically, he explains how YUI3 is used to render markup on the server side, then sent to the client where binding to event and data occurs. The beauty is YUI3 is used as-is on both the client and the server. Makes a lot of sense. The one big issue is there is not yet a production ready server-side DOM library.
screencast