We have a rather large Loopback 3 server which has now reached "End-of-Life" end of 2020.
I am aware of the recommendations to migrate to Loopback 4 as soon as possible, but am hesitant to undertake the migration - much of LB3 functionality does not (yet) exist on LB4, LB4 model relations a subset of LB3, and just pure volume of work involved. I also am aware of (and have tested) the embedding of the LB3 app inside an LB4 app.
So practically speaking - what are the practical downsides to remaining on LB3 for the forseeable future? I understand I will lose out on future patches & fixes e.g. security updates, and I imagine LB3 will have the nodejs version capped (v10?). But for instance will the npm modules ever become unavailable, or will the server just "cease to start" one day? anything else to consider?
(if this smells of management pressure - you're correct)
There's 2 main downsides:
Since LoopBack 3 is being End-of-Life-d (EoL) by the core maintainers, the community's interests would also shift. Parts of the community may choose to use other alternatives, while others may migrate LoopBack 4.
The documentation nor the repo isn't going anywhere, but you may not get community assistance if you're stumped on a particular issue.
LoopBack 4 will continue to improve over time, and the migration guide will be iterated alongside. Hence, you'll have the same opportunity to migrate to LoopBack 4 when ready.
Any security patches, including those of upstream dependencies, won't be applied. This makes it difficult to ensure software security as LoopBack 3 will no longer benefit from semi-automated dependency updates.
If upstream dependency security patches are important (and they should be), it is recommended to maintain a fork of the packages.
The flow would look something like this:
Node.js security fixes may also be important. Hence, the packages should be tested against the latest LTS version of Node.js where possible.
Maintenance includes updating the dependencies and fixing any incompatibilities arising from these updates.
Most probably not. There's no reason why the packages will just "break", barring any unresolved bugs.
As assurance, NPM does not allow unpublishing of packages unless under extreme circumstances, and package-lock.json with npm ci will ensure a mostly-replicable installation.
However, package locks only apply to direct dependencies. Hence, if any upstream dependency applies a backwards-incompatible change without a semver major, the packages may inadvertently break.
This can be mitigated by using NPM Shrinkwraps, which would take a snapshot of the entire dependency tree.
Yes. It's not a hard requirement, however it's not recommended to take the risk of hidden breaking changes.
LoopBack 3 is a well-covered application (in terms of tests). Hence, the test suite can be used to gauge and detect any potential incompatibilities across Node.js updates.
If you're able to maintain a fork of the LoopBack 3 packages, run the test suite, and update the dependencies and Node.js LTS versions through a CI/CD pipeline, then it should be reasonably safe.
LoopBack 3 is quite a mature project. Hence, it can be assumed that most critical flaws have been found. The Maintenance LTS period was designed to allow detection of such bugs without adding any new features that may cause regression or new critical flaws. Nonetheless, detection of a new critical flaw after EOL is still possible.
You must weigh the pros and cons yourself. With all this in mind, how safe it is is incredibly dependent on the type of service that's run on LoopBack 3, the needs of the business, and how much risk you're willing to take.
Secure Software Development Lifecycle is incredibly important, and products and services should be built with this in mind to prevent or mitigate these issues.
I'd start planning the migration now. Since LoopBack 4 is a complete rewrite as a meta-framwork to cater to the popularity of TypeScript and OOP in Node.js, the migration will take some effort.
If there's certain features that you need in LoopBack 4, then 👍 the relevant GitHub issue. LoopBack 4 is an open source project that is community-driven. The maintainers will try to cater to the requirements of the community, and constructive feedback allows the core and community maintainers to prioritize accordingly.