search

loopbackio / loopback-next

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

Driver Interface #776

Closed jpventura closed 6 years ago

jpventura commented 6 years ago

Description/Steps to reproduce

I've started using LoopBack because the connectors and datasources seemed like a canned solution for fast integration with RESTful APIs with API Blueprints or Swagger specifications.

However, while I was trying to create a simple tutorial app, I discovered that it is not possible to automagically consume the API because the server might not provide all CRUD functionalities required by PersistentModel.

Even if Pet Store or TMDB were written in Swagger, the auto import would not be possible.

Driver Interface

Waterline adapters are similar to connectors, except for the fact they define a standard driver interface should provide:

As mentioned at #537, queries would be written in Knex.js language to provide queries.

Expected result

Providing standard methods similar to the driver interface would help juggler to inspect datasources, allowing we faster abstract any kind of local/remote data access.

Also it would be possible to provide an elegant query language:

Pet.find({
    or : [
      { name: 'walter' },
      { occupation: 'teacher' }
    ]
});
Untel commented 6 years ago

I used Sails before Loopback, and had to change Waterline for Sequilize (not without pain). Waterline don't support Deep populate, polymorphism, and some other things. The Loopback 2/3.x connectors where such better. In case where the LB4 team don't develop their own orm, i think it should be better to use TypeORM or Sequalize with typescript definition, than Waterline

kjdelisle commented 6 years ago

We do intend to have a Juggler in v4 as per the discussion in #537, though we will be simplifying it somewhat to reduce friction between datasources and make it easier to support more widely.

@Untel The good news is that the way we've designed the framework for LB4, you can make use of whatever ORM you'd like and keep the protocol-facing portions. Here's a prototype mixin that adds TypeORM as a part of the Application class: https://github.com/strongloop/loopback4-extension-typeorm

It's not necessarily a production-ready mixin per se, but it does demonstrate how you can still leverage LoopBack 4's Application, Context and Controller patterns with a totally different ORM.

bajtos commented 6 years ago

@jpventura thank you for opening this issue.

However, while I was trying to create a simple tutorial app, I discovered that it is not possible to automagically consume the API because the server might not provide all CRUD functionalities required by PersistentModel.

I took a look at your tutorial application. As far as I understand, it's a typical LoopBack 3.x application. It makes we wonder, how did you reach the conclusion that "it is not possible to automagically consume the API because the server might not provide all CRUD functionalities required by PersistentModel."?

First of all, @loopback/repository is using loopback-datasource-juggler 3.x and it's PersistedModel under the hood, therefore all data-access APIs are available (even if not exposed via DefaultCrudEntityRepository).

Are you perhaps referring to the REST API layer? This is something we have to figure out yet. I am personally proposing the approach where controller methods are generated by our CLI tooling, as I have explained in great length in my comment https://github.com/strongloop/loopback-next/issues/485#issuecomment-323345250 about migration from LB 3.x to 4.x. There is also a pull request in review that creates a controller base class providing a common CRUD REST endpoints - see https://github.com/strongloop/loopback-next/pull/740.

Setting aside the fact that I don't understand what is the problem you are facing and how Waterline is going to solve that, I'd like to second what @kjdelisle said in the comment above - we have specifically designed LoopBack 4 to allow developers to use a different ORM instead of our juggler. Of course, you would have to write your CRUD controller methods yourself.

except for the fact they define a standard driver interface

Our controllers do have a standard driver interface, even if it's not as well documented as Waterline's. See the following two pages for more information:

Providing standard methods similar to the driver interface would help juggler to inspect datasources, allowing we faster abstract any kind of local/remote data access.

We have APIs for inspecting database schemas in juggler (is that what you meant?), there is even a basic templated implementation for SQL connectors - see the code in SqlConnector.

I feel I may be missing the point you are trying to make, could you please elaborate more on what issues do you see and what real-world scenarios you are not able to accomplish right now?

bajtos commented 6 years ago

Looks like this proposal does not have enough traction, I am closing this issue for now.