Provide TypeORM Component instead of Mixin

[jonathan-casarrubias]

As a platform developer I would like to easily install TypeORM in LoopBack 4.

IMO having the following as first experience would be best:

import { TypeORMComponent, TypeORMOptions } from '@loopback/typeorm';

// Regardless the method you use: extend an app or create an app instance 
new App({
  components: [TypeORMComponent],
  typeorm: <TypeORMOptions> { ... }
})

By doing that I would expect my models to be automatically discovered and registered.

That as a first experience then by passing configurations or providers or even sequences we might do more fancy things like: registering models in different connections, create model Hooks through model sequences, etc.

I'm eager to contribute on this extension as well, since I already have a very good progress on the gRPC component and I do require both (gRPC and TypeORM) to start building FireLoop on top.

Thoughts?

[raymondfeng]

@jonathan-casarrubias What's your take on https://github.com/strongloop/loopback-next/tree/repository-typeorm/packages/repository-typeorm, which provides an adapter to use TypeORM with LoopBack Repository based queries and mutations?

[jonathan-casarrubias]

@raymondfeng thanks for providing me that info, let me review it and I'll come up with some comments

[jonathan-casarrubias]

I just went through that repo and I think it looks consistent to the repositories documentation from LB docs, I like the repository = new TypeORMRepository(ds, Note); part is great to map a repository from TypeORM a lot of work saved in there.

I guess I'm just not clear on a couple of development experiences.

From a developer perspective:

1.- How the connections will be configured? As a developer, I would like to have a simple configuration that internally setups the connection for me.

2.- How the repositories / models will be registered? Either in this repo and the one you shared I see manually registration of models, as a developer, I would like my models to be discovered.

Am I guessing these features might be planned to be provided from @loopback/core? is that the case?

I'm just not aware of all of the plans so I just want to know what is the future of repositories in terms of development/settingup experience the docs still don't state that.

But I think the repository-typeorm is a very good progress I just would like to know what is the end experience

[bajtos]

@jonathan-casarrubias We are abandoning the work on TypeORM integration, we are going to focus on improving Juggler, our ORM used by LoopBack 3.x. See the discussion in loopbackio/loopback-next#537 for the reasoning.

Feel free to take over this experiment of integrating TypeORM with LoopBack-next if you like.

[jonathan-casarrubias]

@bajtos if you drop efforts on building this in favor of fixing what feels entirely messed up (the juggler) I think it would be best for everyone, we are struggling with LB3 projects due to really basic problems in the Juggler that made a lot of us feel disappointed.

In other words, I do think the best for you -the senior guys- is to focus on the Juggler and fix it / improve it. It used to work very well before. Now we struggle a lot with basic queries that are leading us to difficult situation with our customers. (I'm literally unable to deliver a project)

(Example: strongloop/loopback#3593)

Anyway, I still think giving a shot to a different ORM is healthy for the community so I can take lead on that.

Just a quick question.- When do you think the LB4 Core will be ready?, I would not like to wait until next year as the calendar states for a stable release that includes features that I might or not need, but I also need to make sure that the core won't change so I can build a platform on top.

Cheers
Jon

[bajtos]

In other words, I do think the best for you -the senior guys- is to focus on the Juggler and fix it / improve it.

That's what most of us wish for! Unfortunately, the small size of our team means we are stretched pretty thin, and with the loopback-next refactor/rewrite under way, we have hard times finding enough bandwidth for significant juggler improvements.

Having said that, we would love to see more contributions from our community, fixing particular issues/regressions seem like a good place where to start.

Anyway, I still think giving a shot to a different ORM is healthy for the community so I can take lead on that.

Yes please! Please consider opening a new GH tracking issue in loopback-next and posting a comment in loopbackio/loopback-next#647, to make it easier for people interested in your work to find it (and possibly contribute). Let us know if you run into any questions or issues that we may help you with.

Just a quick question.- When do you think the LB4 Core will be ready?, I would not like to wait until next year as the calendar states for a stable release that includes features that I might or not need, but I also need to make sure that the core won't change so I can build a platform on top.

We have abandoned the concept of grouping features and releases horizontally (core, juggler, tooling, docs, etc.). It creates the classical waterfall problem where fundamental design issues are discovered towards the end of the project, when components built in isolation are finally put together, and when it's too late and expensive to change the design significantly.

Instead, we identified a small set of features to need for a thin vertical slice of our desired functionality, i.e. a minimal end-to-end scenario to cover in all aspects, from CLI tooling to conventional bootstrapper to docs. See loopbackio/loopback-next#696.

Once this MVP slice is done, I would like us to start producing meaningful incrementa releases in a regular cadence, ideally once a month.

I think many of the Core APIs are pretty stable these days, I remember only one breaking change in the last months or two, and it was related to an edge case only. I hope things will get even more stable after we finish the MVP/Walking Skeleton milestone, as it will mean most of the design and ground work has been already done.

I cannot promise you any specific date for this MVP milestone. Based on our current velocity and the estimates we have, my rough estimate is June 2018. The date may change, so don't take my word for it!