loopbackio / loopback-next

LoopBack makes it easy to build modern API applications that require complex integrations.
https://loopback.io
Other
4.95k stars 1.07k forks source link

Create model relations between local and remote models #5196

Closed rivoheinsalu closed 3 years ago

rivoheinsalu commented 4 years ago

Suggestion

In LB3 strong-remoting let's users easily define model relations over multiple microservices. This gives users convenient way to query data with single query over multiple services without having to manually map relations.

Given the more open nature of LoopBack 4 it is not anymore possible to define remote relations on Entity but I think it is worth porting strong-remoting to support LB4 with more strict structure making user responsible for defining correct interfaces.

https://loopback.io/doc/en/lb3/Strong-Remoting.html

Examples

Extending HasMany relation example https://loopback.io/doc/en/lb4/HasMany-relation.html User has two microservices:

  1. Customer
  2. Order

It is possible to define HasMany relation on Customer Entity with remote connector @hasMany(() => Order, {connector: 'remote', model: 'Order'})

Giving user ability to query customers with orders via single endpoint using customerRepo.find({include: [{relation: 'orders'}]});

bajtos commented 4 years ago

Thank you for starting this discussion. I am not sure if adding strong-remoting to LoopBack 4 is the right solution. I would like to reframe the discussion a bit and start with describing the problem to solve.

IIUC, you would like to let your LB4 application to have a regular Repository access to models that are persisted by another LoopBack application, which was historically done via the remote connector.

The first question that comes to my mind - what LoopBack version is used by the remote application? Is LB4-to-LB4 remote good enough, or do you also need LB4-to-LB3 remote access?

rivoheinsalu commented 4 years ago

Is LB4-to-LB4 remote good enough, or do you also need LB4-to-LB3 remote access?

Initially would be good to have LB4-to-LB3-to-LB4 as migrating more than 10 LB3 apps to LB4 one-by-one would give good migration path. But at the end LB4-to-LB4 would be the way.

bajtos commented 4 years ago

@rivoheinsalu I have an idea how to implement a solution allowing LB4 application to talk to both LB3 and LB4 applications when resolving relations. I'd like to write a quick PoC today 🤞

I see how it could be useful to access LB4 models from a LB3 application (LB3 app having a LB4 app acting as a remote). I think it may be possible to extend the ideas from my PoC to implement a LB3 connector acting as a remote connector for LB4, will see.

raymondfeng commented 4 years ago

The newly released lb4 openapi —client can generate strongly-typed service proxies for REST APIs that expose swagger/openapi spec.

bajtos commented 4 years ago

Here is my take on how to allow LB4 apps to access models persisted by other LB apps, leveraging our openapi connector under the hood:

https://github.com/strongloop/loopback-next/pull/5222

@rivoheinsalu can you PTAL?

rivoheinsalu commented 4 years ago

@bajtos thank you for all the effort. This looks very straightforward and easily extendable with different repository interfaces as well as even different datasources, not only LB4 apps.

Seems very good fit for my use case. Exposing find is already covering like 90% of my use cases. Thanks to your PR I have now much better understanding of entity relation mappings inside LB4 application as well.

Good job!

stale[bot] commented 3 years ago

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.

stale[bot] commented 3 years ago

This issue has been closed due to continued inactivity. Thank you for your understanding. 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.