loopback design decisions - why not using existing packages?

[Bnaya]

Hey

First i want to say that this project looks very promising.
We choose not to use LB3, but think we will use LB4.
Following my question:
#110 (comment),
I've opened this issue

I wonder why you aren't using projects like
https://github.com/typeorm/typeorm
As the model layer and
https://github.com/inversify/InversifyJS
as the DI

Thanks

Bnaya

[kjdelisle]

@Bnaya Thanks for the questions, sorry for the slow reply!

Keep in mind, these are my opinions, I don't speak for all of the Loopback team when I'm giving these answers!

InversifyJS is really cool, no doubt, but we want the core to be lightweight, and we want to ensure that we have control over the innermost parts of the developer experience. If InversifyJS were to make sweeping changes to its syntax or structure, it would force us to follow along to stay current, or fork it and maintain a much larger codebase than we'd like. Since the idea of dependency injection is married so tightly to the core concept of Context within loopback4, that's not a position I'd want to put our users in.

As for TypeORM, the answer is much more complicated.

One of the things we've been thinking about is whether or not we still want to provide our own Juggler (see #537 for discussion and feel free to add your voice!). I won't dump all of the details here, but until we decide what it is we want to provide, we're bridging the gap between loopback-datasource-juggler for 3.x so that people can continue on with something we've already built.

The good news here is that loopback4 has no enforced opinion on what sort of ORM (or models) you must use, so you're more than welcome to use TypeORM in a loopback app if it suits you!

cc @bajtos @raymondfeng if either of you wanted to weigh in and add your thoughts.

[sbacem]

+1 to use TypeORM by default in loopback4

[kjdelisle]

@sbacem The great thing about this version of loopback4 is that you already can use TypeORM! Most of what's currently in the alpha won't do anything to hinder you if you decide to build a series of annotated TypeScript objects using it and construct your repositories with it.

The big question in #537 is do we want to make our own juggler, support other ORMs (like TypeORM) by providing templates that generate models/repositories for them, or something else?

[kjdelisle]

The other part is that we can't bake TypeORM support in exclusively, since it only concerns itself with SQL and that would create a disparate level of support between users who want SQL and users that want various NoSQL flavours like CouchDB/Cloudant, MongoDB, Cassandra, etc.

[Bnaya]

@kjdelisle thanks for all of the information!
Would be nice to have a label for issues like #537 and other design/high level topics

[kjdelisle]

@Bnaya Done. The discussion/design label is here!

It's not a sure thing, but I've begun tinkering a bit with TypeORM and loopback-next and have made a prototype mixin to add TypeORM sugar methods to a loopback Application. I'm going to have @bajtos take a look at it first, make some tweaks and fixes and see where it ends up.

[Bnaya]

@kjdelisle thank you!

[bajtos]

I think @kjdelisle answered the questions pretty well 👍

https://github.com/inversify/InversifyJS as the DI

There is one more reason why we are not using InversifyJS. A typical IoC container like InversifyJS serves to inject behaviour only (e.g. I want something behaving like a weapon, and InversifyJS will give me a specific weapon instance). For better or worse, we want to inject data in LoopBack4 too - from the current request/response, through the controller & method name being invoked, to data like access token used to authorize the request and transaction/correlation ID that should be forwarded in outgoing requests made to backend services.