Originally published on strongloop.com
When building a LoopBack 4 application, we often need to tweak or improve the default data access behavior provided by the framework. It's usually desirable to apply the same set of customizations for multiple models, possibly across several microservices. In this post, I'd like to share a few tips and tricks for reusing such repository code.
Originally published on strongloop.com
As LoopBack 3 is expected to reach its EOL by the end of this year, we have been working hard to achieve feature parity between LoopBack 3 and LoopBack 4. One feature of LoopBack 3 that we did not have in LoopBack 4 yet was the ability to go directly from only a model definition and model configuration to fully-featured CRUD REST API. Unlike LoopBack 3, LoopBack 4 relied on intermediate repository and controller classes in order to go from a model defintion class to use REST API. One thing that LoopBack 4 strives to do is make common tasks as easy as possible, while allowing advanced composition with loosely-coupled artifacts. So, after completing tasks from the related epic, we are now proud to announce that LoopBack 4 now offers support for going from a model definition to REST API with no custom repository or controller classes.
Originally published on strongloop.com
LoopBack 4 now offers a new feature: inclusion of related models! This addition not only simplifies querying data in LoopBack 4, but since we have similar features in LoopBack 3 it also closes one feature gap between LoopBack 3 as well. The idea is to use the inclusion resolver, which is a function that helps to query data over different relations, to achieve such simplifications for us.
Here is a simple use case of inclusion: a customer has many orders.
If we'd like to get a customer's instance with all their orders instances, we can query on Customer with filter {include: [{relation: 'orders']}. The inclusion resolvers are similar to GraphQL resolvers -- it will find the target instances of Customer first and pass its result to the inclusion resolver of orders. The query result will contain the return value of orders nested under corresponding Customer instead of connecting to database twice. Read on for detailed examples and explanations!
Originally published on strongloop.com
We've refactored the authentication component to be more extensible and easier to use.
Now you can secure your endpoints with both passport-based and LoopBack native authentication strategies that implement the interface AuthenticationStrategy.
The new design greatly simplifies the effort of application developers and extension developers since they now only need to focus on binding strategies to the application without having to understand/modify the strategy resolver or the action provider.