When using semantic versioning, what if the REST API endpoints of a backend (used by a frontend application) do NOT change, but the code inside of the codebase DOES change in a backwards-incompatible way (breaking change)? Does this mean the major number has to increase or the minor?
Also, in the situation that there is a bug, and in order to fix the bug we have to add a new parameter to a function that is used in multiple places in the codebase (which means it is a breaking change if I'm correct), does this mean the major version has to increase even though it is a bug fix (which would mean the patch version has to increase)?
PS: we want to use semantic versioning in a small development team (5 developers). The projects are for paying clients, but we want to handle a good standard for doing new releases and knowing the amount of impact of a release based on the version. I don't think this will change how we have to use semantic versioning though (feel free to correct me if I'm wrong here).
Related
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.
The 'request' module has been a long-time standard for Node.js. They have recently deprecated the library.
I am starting a new project, and looking for the best solution to do my networking. I started off using the native 'https' module, but ran into problem after problem. Using the request module seemed to be easy and work just fine. There are also many other libraries to replace the request module.
Generally speaking, you should avoid using deprecated libraries when possible. But does that rule of thumb apply here?
Is it bad to start a new project with the 'request' module? If so, what is the new standard?
I would personally not start a new project with the request() library unless it has a feature that no other library has that I absolutely need or unless I need another module that depends upon the request() module itself.
When I have the freedom to choose, I'm using got() for new projects instead. Choosing from the list of alternatives is a personal decision so you just have to evaluate the type of interface they each have and what features they have. For what I typically do with this type of library, got() seemed simple and clean, built from the ground up with promises, meets my needs and I've had no problems using it.
Axios, node-fetch and superagent have advantages in that you can use a similar interface in both node.js and in the browser. All are popular and in wide use.
I tried bent, but didn't click with its programming interface.
I'd personally rather be using libraries that have a stated objective to continue to evolve with new developments in the language, new developments in nodejs libraries and add new features over time rather than a library that says it will not be adding new features.
I also like using a library that has promise support built-in from the core rather than added on only as a wrapper since I do all asynchronous programming with promises now.
Some other resources in examining the alternatives:
Feature comparison chart (written by the makers of got())
Migrating to got() from request
And, if you want to read about why the request() library has gone into maintenance mode, read here.
In a nutshell, it's an old architecture with tons of features glued onto the side, but because there are so many modules dependent upon it, they can't really break their API to fix or smooth things out. And, because it's so popular, it is holding back the success of competing solutions that have designed a cleaner interface. So, the decision was made to let the alternatives that have been designed in a more modern way take the mantle going forward and request() will go into maintenance mode to continue to support the other modules that are dependent upon it, but not try to evolve into a more modern interface.
Request isn’t really deprecated. It’s no longer considering new features or breaking changes, but it is still being maintained. It’s safe to use for the foreseeable future, but how good an idea it is to use it is up to the developer. Not really a right or wrong answer here.
They’ve stopped new work on it because they believe the patterns it uses are out of date and to switch over to modern patterns would effectively make request an entirely new module, so rather than invalidate thousands of blogs and SO answers by making a massive update, they’ve decided to stop in order to make space for a new standard to emerge that effectively uses new features. As of yet, a new standard does not exist.
If you like request, and the outdated patterns it uses are good for your purposes, then go for it. But new patterns and features exist for a reason, and they might be worth exploring.
The author of request mentions that request was written in the old ways when the best practices were so different. He tried to recreate a similar library with better practices and made bent.
I would say the only problem with request was not the underlying code, but also its interface: callbacks belong to the stone age and make your code ugly.
My personal suggestion would be using RxJS-based solutions:
RxJS's bundled ajax library for frontend code (comes with rxjs),
RxJSx's request library for backend (#rxjsx/request).
I have a number of microservices in a distributed system - one of which I have recently renamed to better reflect its bounded context and disambiguate with another similarly named service.
The service was on version 3.1.0 at the point of renaming. My question is, what do I do with the version now? Is it 4.0.0? Or is this conceptually now a new service, replacing the old one and starting again from 1.0.0?
I would lean towards the latter option, but I'm also versioning the db schema to match the service, and I don't want to end up in the position where the service is 1.0.0 but the db schema is 3.1.0...
You should bump to version 4.0. The idea is not the name of the service, but a hint to its history and lineage. In this example, though the method of calling the executable has changed, the linage of the database is intact and you want to keep the history that the previous version existed.
Bumping the major version already signals to all users that incompatible changes have occurred, so no one will pick this new invocation version up by accident.
Semantic versioning is deliberately underspecified so that the core tenets will continue to be followed even if others disagree with an argument. That is, semantic versioning will only specify what you must do, not what you should do.
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.