We often face a dilemma around example projects. They are useful learning resources that demonstrate individual features in a runnable application while making it easy to tweak and play with the code. But on the other hand, they can quickly become a maintenance burden. As the framework evolves, significant ongoing efforts are needed to keep these examples up to date with the latest APIs, conventions, and best practices.
Because our CLI tooling makes it so easy to quickly create a new project, we could not resist the temptation and ended up with about 18 example projects. To update them, one has to open 18 pull requests - that’s a lot of tedious work!
LoopBack 4 implements an IoC container to support dependency injection with decorators. You can find more information at http://loopback.io/doc/en/lb4/Dependency-injection.html.
Dependency injection is very powerful, but when something goes wrong, it can get ugly. Circular dependencies and resolution errors can leave you with layers of bindings and injections to sift through to track down even small problems.
But there’s no reason to panic! We’ve recently introduced the ability to track down the dependency injection path to help you out. Let’s start with an example before we dive into the details of the feature.
I’ve recently been working on an exciting new feature for LoopBack4 which would allow for the readily available generation of JSON Schema for your LoopBack4 models. I’ll dive right into it.
Models and metadata in LoopBack 4
Currently with LoopBack 4, a model is a way to represent data, such as
Order, handled by the framework and is implemented as TypeScript classes. One useful feature of TypeScript is its experimental decorators which are able to infer property types of a class at compile-time and store them as metadata.
A security advisory was issued today for users of LoopBack 2.x and 3.x.
Security risk: Medium (CVSS: 4.3) Vulnerability: Prevent unauthorized alteration of records on same table.
You can find the full details in the corresponding links below.
If you haven’t already checked out the Developer Preview release, it is just the first milestone of our LoopBack 4 journey. A tentative plan is outlined at https://github.com/strongloop/loopback-next/wiki/Upcoming-Releases. Please note that it is not an official commitment and subject to adjustment as we make progress with the community contributions and feedbacks.
Work has been going non-stop on the upcoming LoopBack 4.0, and we’d like to share some of what we’ve just added in the current release!
We’ve added the new controller generation command to the
lb4 CLI toolkit, which you can install with
npm i -g @loopback/cli.
How controllers work in LoopBack 4
Controllers are what sit in the middle of the request-response lifecycle of LoopBack 4. Incoming requests are routed by the RestServer to an instance of a controller that has been configured to handle the appropriate route.