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.
Express is the most popular Node.js package for web server development. Its lightweight, extensible, and flexible nature makes it a perfect fit for projects, small and large, from simple websites to complex web frameworks.
LoopBack is a framework built on top of Express. It comes packed with tools, features, and capabilities that enables rapid API and microservices development and easy maintenance.
In this post we will explore the points that make LoopBack a compelling choice for Express developers when it comes to API development.
In April, we focused mostly on completing migration activities, like the migration guide and other related tasks like running existing tests in a LoopBack 3 application after composing it within a LoopBack 4 application. But, that didn’t stop us from exploring and adding some cool features.
We now have a new Express package, which enables modeling Express middleware functions as an interceptor chain. Also it is possible now to break a complex application into much smaller components and wire them in a main application. You can find more details on thsese below in
Exploring new territories.
Also our community has published many LoopBack 4 extensions in NPM. Many of these extensions are addressing a variety of usecases like pub-sub messaging, mqtt, graphql, rate-limiting, authentication, logging, AWS cloud integration, etc. The extensibility of LoopBack in real time use cases are even surprising us and the possibilities seems to be endless.
- Migration Guide
- Exploring new territories
- APIConnect Extension
- Community Contributions
In the past, we’ve explored a few options on providing a forum for our users to help each other: Google group, Gitter and GitHub. We are pleased to announce that the LoopBack Slack workspace, https://loopbackio.slack.com/, is available for our users to join. Since Slack is quite commonly used, we thought it would be a good time for us to modernize our tooling for the LoopBack community helping out each other out. Also, the LoopBack core team uses Slack on a daily basis; it is helpful because it allows us to get notifications and communicate efficiently.
There have been lots of great questions and answers. We thought it would be helpful to curate some of the discussions here. Thanks again for submitting the questions and answers!
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.