Example of using remote connector with LB4

[nikivanov]

Hi!

I'm trying to talk to an LB2 application from my LB4 application via the remote connector. I have no problem using the REST connector, but it doesn't do method translation properly when using DefaultCrudRepository. If I create the REST datasource like this:

const dataSource = new juggler.DataSource({
	"name": "remoteDS",
	"connector": "rest",
	"baseURL": "http://localhost:3020/v1/",
});

and then await dataSource.connect(), it connects with no problems.

However, if I set it up like this:

const dataSource = new juggler.DataSource({
	"name": "remoteDS",
	"connector": "remote",
	"url": "http://localhost:3020/v1/",
});

and then await dataSource.connect(), the connect promise never gets resolved.

In general, I have trouble finding anything about Loopback 4 and the remote connector. Are there any tutorials or documentation that would be valid for LB4? Thanks!

[marioestradarosa]

The todo tutorial has an excellent section on REST Service Integration
https://loopback.io/doc/en/lb4/todo-tutorial-geocoding-service.html

[nikivanov]

If I use the remote connector, it would auto-discover models, no? I'm trying to connect to my own lb2 application - the remote connector seems a lot more native than the plain REST one. For instance, my lb2 app has a findOne method. If I use the REST connector, findOne gets converted into a filtered request with a limit of 1 - not an issue in itself, but I want the repo methods and the remote methods to be 1-1. As far as I understand it, the remote connector would do a lot of that work for me.

[bajtos]

Hi @nikivanov, I am afraid the remote connector is unlikely to work with LoopBack 4+ because the it's based on high-level design features that are intentionally not available in LB 4, at least not yet. Let me explain.

The remote connector assumes that both the client and the server are sharing the same set of model definitions (model JSON files in LB 3.x) format, and that the server is exposing all built-in REST API endpoints provided by PersistedModel in v3.

In LoopBack 4, we have intentionally decoupled the REST API from the data-access layer by adding a concept of Controllers. As a result, the REST API of a LoopBack 4 application cannot be automatically inferred from a model definition.

As a result, the remote connector cannot act as a client connecting to LoopBack 4 servers. Our current preference is to leverage OpenAPI to build clients, e.g. use swagger-codegen to build strongly-typed clients, or swagger-js to provide a dynamic client in JavaScript.

Having said that, your use case is different because you would like to connect from v4 server to v2 client. Unfortunately, I don't see any clean way how to do that either, because again, the remote connector relies on the fact that in v2/v3, a Model class combines three different aspects - model definition (data schema), data access and REST API, while v4 keeps these three concepts decoupled.

I see only one option and personally find it a bit hacky: in your LBv4 server, create a dummy LBv2 application to provide the client. An example snippet to illustrate what I mean:

const loopback2 = require('loopback');

class MyApplication extends BootMixin(...(RestApplication)) {
  // ...
  async boot() {
    await super.boot();
    setupLoopBackClient();
  }

  setupLoopBackClient() {
    const app = loopback2();
    app.dataSource('remote', /* your remote connector config */);
    // TODO: define LB2 models and attach them to "remote" datasource
    // alternatively, use loopback-boot to handle this for you.

    app.bind('client').to(app);
    // bind each of the remote models as a new service
    app.bind('services.Product').to(app.models.Product);
    // etc.
  }
}

// usage in controllers
class ProductController {
  constructor(
    @inject('services.Product') public productService: juggler.PersistedModel
  ) {}
  
  @get(/products)
  async getProducts() {
    return this.productService.find();
  }
}

(The code example above may not work out of the box as I don't have time to verify it myself, sorry for that!)

[dhmlau]

@nikivanov @mgabeler-lee-6rs, cross posting my comments in #2788 (comment):

Please see this docs page: https://loopback.io/doc/en/lb4/Calling-other-APIs-and-web-services.html for more detailed instructions.
I have this repo https://github.com/dhmlau/loopback4-external-apis as an example too.

Please note that @nabdelgadir is working on a PR that allows mounting a LB3 app to LB4: #2682, that might be something you're looking for.

[mgabeler-lee-6rs]

That PR looks interesting, but also looks to be doing the opposite of this -- serving an LB3 app from within an LB4 app, as opposed to trying to send requests to a remote LB3 app from an LB4 app.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[deepakrkris]

closing this issue based on the discussion above, and since it is stale for a long time, please reopen if necessary.