This article will help existing users understand LoopBack 4:

• How to connect LoopBack 3.x concepts to LoopBack 4 terms
• What’s new and exciting in LoopBack 4

Overview

At high-level, LoopBack 3.x applications consist of three big “parts”

• Persistence layer (this includes talking to backend services like SOAP/REST)
• Outwards facing REST API

• App-wide setup - Express middleware, boot scripts, etc.In the persistence layer, users can contribute the following artifacts:

• Definitions of Model data types (properties, validations)

• Definition of data sources
• Configuration of models (which datasource are they attached to)

• Operation hooksAt the public API side, users can define:

• Which built-in methods should be exposed (think ofdisableRemoteMethodByName)

• Custom remote methods
• before/after/afterError hooks at application-level
• before/after/afterError hooks at model-level
• before/after/afterError hooks at model method levelLoopBack 4 was intentionally designed to allow users to choose their ownORM/persistence solution. The juggler from LoopBack 3 has been packaged into@loopback/repository so that it’s possible for users to reuse their existingmodel definitions, migrating their application incrementally.

Concept/feature mapping

In Loopback 3.x (and earlier), models were responsible for both accessing datain other systems (databases, SOAP services, etc.) and providing theapplication’s external REST API. This made it easy to quickly build a RESTinterface for an existing database, but difficult to customize the REST API andfine-tune it to the needs of application clients.

LoopBack 4 is moving to the well-known Model-(View-)Controller pattern, wherethe code responsible for data access and manipulation is separated from the coderesponsible for implementing the REST API.

loopback4-example-microservicesdemonstrates this loose coupling. Facade is the top-level service that servesthe account summary API, and is dependent on the three services Account,Customer, and Transaction. But the facade only aggregates the calls to the threeservices, and is not tightly coupled with the service implementation; that’s whyit is independent of the three services. We can define the APIs in facade theway we want. Thus, code responsible for data access and manipulation isseparated from the code responsible for implementing client side APIs.

What’s new and exciting in LoopBack 4

Some of the highlights of LoopBack 4 include:

• Leverage TypeScript for better code quality and productivity
• Unify and simplify the asynchronous programming model/style around Promise andAsync/Await
• Implement an IoC Container with Dependency Injection for better visibility,extensibility and composability
• Introduce Component as packaging model for extensions that can be plugged intoLoopBack 4 applications
• Make everything else as components (REST, Authentication, and Authorization)
• Divide the responsibilities of LoopBack models into
  • Controllers: handle incoming API requests
  • Repositories: provide access to datasources
  • Models: define schemas for business objects
  • Services: interact with existing REST APIs, SOAP Web Services, and otherforms of services/microservices
• Refactor the ORM into separate modules for different concernsAs LoopBack 4 continues to grow, more features are continuously added. You cancheck out our blog tokeep up with these new features.