I would like to know the following.
We are using node version 6 and an upgrade to node 12 or 14 is easier said than done as it may demand a re-write of our code in our case.
That said I would like to know the disadvantage of continuing with node6 for significant amount of time in the future? I know node 6 is not supported but what would that mean for a production application which is running for several years? Thanks.
Let's assume your production application is running perfectly fine till, so there is no need to change anything (Here we are focusing on business logic). But apart from that, there are certain things we may focus on while talking about maintaining the production projects like adding new features, improving the performance, and many more.
Let's focus on the above two points
if we want to add new functionality, we have to stick with the older version of nodejs. So libraries which we are using should be also running on nodejs version 6 or lower which will be problematic for developers.
improving the performance
Let's look out the key improvements done in nodejs after version 6
Heap size & dump improvements
Native modules N-API improvements
Improved startup performance, TLS, and security
Performance improvements with V8 Engine v6.6
and many more
These are just the system improvements, apart from these there are function improvements like promises, async/await, ES6, diagnosis, and monitoring
So if we are updating slowly to new stable versions it will help both developers to maintain and getting high performance
Note that, node version 8 is coming to an end and after 2020, there'll be no support for it including any security patches.
Considering your case, I wouldn't recommend jumping 8 major versions and upgrading to version 14.
Instead go one version up, see how things go; then continue doing the same until you get to a LTS version.
Related
I'm surprise to not find a official guidelines around upgrades for the community edition of cassandre in their website.
https://cassandra.apache.org/doc/4.0/index.html
I see that datastax provides some guidelines for their enterprise product but not really for the community versions. maybe I'm not looking at the right sites?
by googling around I see different howTos and different advices regarding upgrading minor versions in a cluster but nothing specific for making the jump between 4.0.1 to 4.0.5(which is the latest rpm available in their official repos)
[context]
about a year ago, I had put together a very simple cassandra cluster with 3 seed nodes and 2 normal nodes. this cluster is running on 4.0.1 since then without any issues and now I'm looking to upgrade a few minor versions to 4.0.5.
Besides replacing from time to time a node the maintenance is pretty simple and tbh I cannot complain about cassandra software itself.
[/context]
My understanding from other stackoverflow questions is that for minor versions(saw lot of questions about 3.11 minor upgrades) the risk is low and sometimes depending on the versions you can get away without not even having to upgrade the sstables but I cannot find if this applies to 4.0.1 to 4.0.5.
I would like to understand how the community is handling this lack of official community guidelines for upgrades in C*, so I'm looking to see what sites or docs the great stackoverflow heroes recommended to take them as reference.
I'm still in the researching phase before the upgrade, I was thinking to run some sort of "online" upgrade by updating node by node, to avoid downtime, i know this will mean having mixed versions in the cluster for a while but I understand the other option is to bring the whole cluster down, perform the upgrade on all nodes and the start it back.
There are more and more references in the Node.js community to "CrankShaftScript" (and "CrankShaftJS") on Twitter, GitHub, and Facebook group discussions. I thought Node.js was written in C++ and JavaScript, so what is CrankShaftScript referring to in performance regression bugs like this one:
https://github.com/nodejs/CTC/issues/146#issue-237435588
CrankShaftScript is the name given by the community to JS idioms (such as certain types of loops) that run faster(est?) on V8's CrankShaft engine.
CrankShaft is being replaced by an engine named TurboFan. Lots of JS code written by devs over the years has been written specifically to run fast on CrankShaft (e.g. written in "CrankShaftScript") using the known idioms that run fast on CrankShaft - this is no longer necessarily the case because the V8 engine is now different and the code that ran fastest on CrankShaft is not necessarily guaranteed to run fastest on TurboFan.
In case my answer is too verbose, here's a great comment on the NodeJS Benchmarks thread that may detail it better:
...I noticed that some parts of Node core are sort-of written in
CrankshaftScript, i.e. carefully tuned towards stuff that works
extremely well in Crankshaft.
CrankShaftScript is a community-adopted term used for non-idiomatic and/or non-standard compliant JavaScript that will only execute and/or perform well in the specific versions of the v8 JavaScript runtime that employ the CrankShaft JIT compiler. Specific examples include: loops written in a difficult-to-maintain fashion to work around JIT optimization deficiencies in v8, and use of v8-specific built-in functions/globals.
This term was originally coined to describe some root performance issues in node-chakracore and spidernode, which are Node.js distributions that employ the ChakraCore and SpiderMonkey runtimes instead of v8.
It is now being used as shorthand to explain why the Node.js 8.1 release series, which updated to a newer version of v8, has several performance regressions in micro- and macro-benchmarks due to v8's CrankShaft JIT being superseded by TurboFan (sometimes referred to as "TF"). As in these issues:
https://github.com/nodejs/node/issues/11851#issuecomment-287253082
https://github.com/nodejs/CTC/issues/146#issuecomment-310229393
https://twitter.com/matteocollina/status/870580613266501632
For these reasons, the Node.js community is actively working on excising instances of CrankShaftScript in Node.js core code, as well as in common npm packages. This should help alternative Node.js distributions like node-chakracore perform better and ease the risk of future upgrades to the JavaScript runtime in Node.js.
CrankShaft is the compilation infrastructure for V8, Node.js' Javascript runtime (details).
It's now being replaced by TurboFan.
There was a bug in V8 that was making my application take up a lot more memory than it had to, but its been fixed recently. Therefore, I would like to compile nodejs with a newer version of v8. How can I do this And is it smart?
I noticed that the version of v8 that the stable nodejs uses is quite old (from the end of 2012!) I think v8 has improved a lot since then so there must be some reason nodejs comes with an older version of v8.
Before trying this, I would just use the latest node v0.11 releases, which have a much newer v8, and are very close to being declared stable and blessed as v0.12. While technically possible to at least attempt a different v8 change, I believe your chances of success at getting all of node core plus whatever npm modules you need working are pretty slim and it will take some time if you aren't already an expert in this domain. Plus you are circumventing a good community process. If you have a legit bug with memory usage, and it's not already fixed in the latest v0.11 release, file it. node core pays attention and responds to these things.
Is the latest mongodb native driver mature enough to use with for instance GridFS in a production environment or as specification in a large project?
Referring to http://mongodb.github.com/node-mongodb-native
I would like to consider the rapid changing conventions, as opposed to the maturity of the technology. In short, is it safe to select a version as specification for a high profile production environment?
My limited experience with the technology does not allow me to determine if it would be safe to use in a locked down specification scenario, or even version lock down as per long term support aka Ubuntu, where fix/security patches are OK as opposed to version changes.
Yes. This driver is mature enough to use in production. It is being used in many high profile Node.js deployments already and supports a feature set on par with existing MongoDB drivers. It is also put through the same testing as other MongoDB drivers and performs sufficiently well.
On the MongoDB side there should not be any concern about rapidly changing conventions. The API has shown stability over the past few releases and hasn't introduced any breaking changes through many releases.
Are you really sure that you want to use young technology in the kind of setting you are describing? It requires a lot of maturity for a project to start doing long term support of older versions.
Also in the open source world you rarely see the project itself providing any kind of long term support. Instead you have companies like Canonical and RedHat backporting patches to their specific versions of i.e. MySQL. 10Gen is the company behind MongoDB and mongodb-native and they would be the right ones to ask about long term support.
My experience with mongodb-native is that is a very rapidly improving project and you really need to keep up with what is going on. I would not like to support anything where the mongodb-native version is set in stone for the next n years.
Having said that MongoDB, Node.JS, and mongodb-native are certainly production ready if you are prepared to stay abreast with their rapid development.
As stated in the title, I would like to know if it's safe to develop a website using one of the actuals "omg" platforms that are Node.js and Ringo.js at their actual version.
Also, I would like to know if they support cookies/sessions and how do they deals with multi-fields post (fieldname[] in PHP).
Thank you
--Edit--
Thanks for all the links guys.
What can you tell me about Ringojs ?
Since I haven't figured which platform to start playing with. I must admit that the fact it can use Java seamlessly really impress me. The only available XSLT 2.0 library is in Java. I could use it as a templating system.
Is there anyone who had the chance to play with Ringojs?
From my experience using both, Ringo is more stable and "safer" for production use but you can comfortably deploy both. In addition to the ability to wrap existing Java libraries that you mention, you also get the benefit of being able to run it in an existing webapp container which manages the lifecycle of the application for you and ensures its availability.
That being said, it doesn't have to be an either or decision. By using my common-node package and assuming you don't use any Java libraries, it's perfectly feasible to maintain a project that runs on both without any changes to the code.
I've also included benchmarks that test the performance of Node.js vs. RingoJS the results of which you can find in the common-node/README.md. To summarize: RingoJS has slightly lower throughput than Node.js, but much lower variance in response times while using six times the RAM with default Java settings. The latter can be tweaked and brought down to as little as twice the memory usage of Node with e.g. my ringo-sunserver but at the expense of decreased performance.
Node.js is stable, so yes it's safe to use. Node.js is capable of handling cookies, sessions, and multiple fields but are not as easy to manage. Web frameworks solve this problem.
I recommend Express.js, it's an open-source web framework for Node.js which handles all of this and more.
You can download it here:
https://github.com/visionmedia/express
I hope this helped!
Examples of some of the bigger sites running Node.js
https://www.learnboost.com/
http://ge.tt/
https://gomockingbird.com/
https://secured.milewise.com/
http://voxer.com/
https://www.yammer.com/
http://cloud9ide.com/
http://beta.etherpad.org/
http://loggly.com/
http://wordsquared.com/
Yes. It is. https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node and https://github.com/joyent/node/wiki/modules
cookies/sessions/forms etc http://expressjs.com/ makes it easier
Ringojs is a framework developed by Hannes Wallnöver and uses rhino as it's scripting framework. There are webframeworks, templating-engines, orm-packages and many many more things already available. Have a look at the tutorial featuring a good subset of packages you may use for a simple web-application. It's not too long and straightforward.
Even thought some of those packages used within the tutorial (e.g. ringo-sqlstore]) are marked as 0.8 and come with the hint "consider this being beta" they are already very stable and bugs - if you find one - get fixed or commented on very fast.
And the power of uncountable java-libraries out there is at your fingertips - so if you already have java-knowledge this knowledge isn't wasted. Rhino - the scripting-engine - even enables you to implement interfaces and extend classes. It is possible a little more advanced but i've done it and i know of packages taking advantage of such features (like ringo-ftpserver which is a wrapper around Apache FtpServer written in java)
Another pro for me is - because ringojs is based on java - it works fairly well with multithreading with ringo/worker for example.