Tip: Read this first to understand how LoopBack works.
A key powerful feature of LoopBack is that when you define a model it automatically comes with a predefined REST API with a full set of create, read, update, and delete operations.
The Basic model object has methods for adding hooks and for validating data. Other model objects all “inherit from” it. Models have an inheritance hierarchy, as shown at right: When you attach a model to a persistent data source it becomes a connected model with create, retrieve, update, and delete operations. LoopBack’s built-in models inherit from it.
Every LoopBack application has a set of predefined built-in models such as User, Role, and Application, so you don’t have to create these common models from scratch.
You can define your own custom models specific to your application. You can make your custom models extend built-in models to build on the predefined functionality of User, Application, and other built-in models.
You can create LoopBack models in various ways, depending on what kind of data source the model is based on. You can create models:
- With the LoopBack model generator.
- From an existing relational database using model discovery. Then you can keep your model synchronized with the database using LoopBack’s schema / model synchronization API.
- By instance introspection for free-form data in NoSQL databases or REST APIs.
All three of these methods create a Model definition JSON file that defines your model in LoopBack,
by convention in a LoopBack project’s
common/models directory; for example,
You can also create and customize models programmatically using the LoopBack API, or by manually editing the model definition JSON file. In most cases, you shouldn’t need to use those techniques to create models, but you generally will use them to modify and customize models.
The Model definition JSON file includes an
idInjection property that indicates
whether LoopBack automatically adds a unique
id property to a model. For a model connected to a database, the id property corresponds to the primary key.
See ID properties for more information.
Model create, retrieve, update, and delete operations
|Operation||REST||LoopBack model method
|Read (Retrieve)||GET /modelName?filter=...||
|Delete (Destroy)||DELETE /modelName/modelID||
(*) Methods listed are just prominent examples; other methods may provide similar functionality; for example:
See PersistedModel API documentation for more information.
You can add custom application logic in several ways; you can:
- Add application logic to models through remote methods (custom REST endpoints), remote hooks that are triggered by remote methods, and operation hooks that are triggered by model create, retrieve, update, and delete methods.
- Add boot scripts that run when the application starts.
- Define custom middleware, similar to Express middleware.
You can add code to validate data before saving it to the model and back-end data store.
Middleware refers to functions executed when HTTP requests are made to REST endpoints. Since LoopBack is based on Express, LoopBack middleware is the same as Express middleware. However, LoopBack adds the concept of phases, to clearly define the order in which middleware is called. Using phases helps to avoid ordering issues that can occur with standard Express middleware.
See Defining middleware for more information.
Data sources and connectors
LoopBack generalizes backend services such as databases, REST APIs, SOAP web services, and storage services as data sources.
Data sources are backed by connectors that then communicate directly with the database or other back-end service. Applications don’t use connectors directly, rather they go through data sources using the DataSource and PersistedModel APIs.
LoopBack components provide additional “plug-in” functionality:
- Push notifications - enables sending information to mobile apps for immediate display in a ”badge,” alert, or pop-up message on the mobile device.
- Storage component - enables uploading and downloading files to and from cloud storage providers (Amazon, Rackspace, Openstack, and Azure) as well as the server file system.
- Third-party login - integrates Passport and enables user login (and account linking) using third-party credentials from Facebook, Google, Twitter, Github, or any system that supports OAuth, OAuth 2, or OpenID.
- Synchronization - enables mobile applications to operate offline and then synchronize data with the server application when reconnected.
- OAuth 2.0 - enables LoopBack applications to function as oAuth 2.0 providers to authenticate and authorize client applications and users to access protected API endpoints.