ContextQMD
Back to Loopback Next

LoopBack 3 features not planned in LoopBack 4

docs/site/migration/not-planned.md

4.0.0-alpha.15.8 KB
Original Source

{% include tip.html content=" Missing instructions for your LoopBack 3 use case? Please report a Migration docs issue on GitHub to let us know. " %}

In the early days of LoopBack, we were exploring different functional areas to find features that would make the framework compelling to a wide audience. Some of those feature become popular, other not so much. In the meantime, the world has moved on and many paradigms popular back in 2013-2015 have been superseded by better ideas.

Additionally, the community of LoopBack maintainers was not growing fast enough to support the wide spectrum of features offered by LoopBack. As a result, most extensions were not integrated well together and many of them are becoming outdated by now.

In order to keep the project sustainable and offer great developer experience to framework users, we decided to sunset several LoopBack 3 extensions and features. We are encouraging our community step up and take over development of these extensions.

Storage component

loopback-component-storage provides a unified REST API for storing and retrieving arbitrary files, using 3rd-party storage like Amazon S3.

Essentially, this component has the following parts:

  1. A custom layer to handle file uploads
  2. A custom layer to handle file downloads
  3. Connectors to different storage services (this part is handled by pkgcloud package)
  4. Integration layer providing File and Container abstractions with REST API.

In LoopBack 4, you can implement a similar functionality as follows:

  1. Use x-parser: stream extension to receive request body as a stream, and multer package to deal with multi-part file uploads. Check out our File Upload/Download Example for a fully working application.

  2. LoopBack 4 does not provide first-class support for file downloads yet, see loopback-next#2230. As a workaround, you can inject the full Express response object and use Express API to stream the response body. Find more details in the discussion in the linked GitHub issue, check out our File Upload/Download Example for a fully working application.

  3. To connect to your cloud storage provider, you can use pkgcloud or directly the Node.js client library provided by your provider. You may want to check multer-storage-pkgcloud

  4. Finally, create a Service providing File and Container APIs in TypeScript and one or more Controllers to implement the REST API.

If you are happy with the outcome, then please consider packaging your code as a LoopBack Component and sharing your great work with the entire LoopBack community. We are happy to promote it in our documentation, just submit a pull request to add your component to Using components.

Push notifications

loopback-component-push enable server applications to send information to mobile apps even when the app isn’t in use.

The component consists of the following parts (see Architecture):

  1. Device model and APIs to manage devices with applications and users.
  2. Application model to provide push settings for device types such as iOS and Android.
  3. Notification model to capture notification messages and persist scheduled notifications.
  4. Optional job to take scheduled notification requests.
  5. Push connector that interacts with device registration records and push providers APNS for iOS apps and GCM for Android apps.
  6. Push model to provide high-level APIs for device-independent push notifications.

In LoopBack 4, you can re-create a similar functionality as follows:

  • Implement models, repositories and controllers to provide Device and Application model.
  • Implement a Service to provide TypeScript API for sending notifications and persisting scheduled notifications to be sent later. You can use packages like apn and node-gcm to interact with Apple's and Google's push notification services.

Offline data access and synchronization

Synchronization component allows browser clients to access and modify data while in offline mode, and then synchronize (replicate) changes made both on the client and on the server when the client comes online again.

The implementation in LoopBack 3 is complex and tightly integrated with the built-in persistence layer, which makes it very difficult is to migrate such functionality to LoopBack 4's programming model.

If you are interested in offline data access, then we recommend you to research specialized solutions tailored for the database server you are using for persisting your data. Few pointers to bootstrap your search:

  • MongoDB Realm provides two-way and offline-first sync for MongoDB Atlas.
  • pouchdb enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers when the application is back online.
  • GUN a is a small, easy, and fast data sync and storage system providing offline-first capabilities.