Thoughts on Loopback & the Ecosystem

[kowsheek]

It was great to meet and chat @dhmlau @raymondfeng, the team really appreciated your taking the time. Having stepped up development last week, I wanted to share our thoughts on Loopback in how (from our perspective) it can continue to be an attractive platform and ecosystem.

cc: @saunderst @SrChip15 @ckrac

1. As developers and users of the ecosystem, we need documentation. Currently, we sift through LB3 and LB4 documentation and code to find what we need. If you look at competing frameworks such as Nest, their documentation looks and feels comprehensive and coherent. As developers we sometimes fail to appreciate the need for aesthetically appealing content - as consumers of the content, it's paramount.

Business impact: it had costs my team significant amounts of time to find what we need to answer everyday questions.

2. Fragmentation of projects such as the connectors looks worrying to me since they seem like forlorn projects. While we trust that LB4 will have a long EOL, it seems a small team is juggling several projects that are not comprehensive in their functional coverage. For example array support in the PostgreSQL connector should be a core feature, but isn't available yet. If we want the community to contribute, we have to make the ecosystem more attractive - starting with brand and documentation.

Business impact: the ecosystem of the core platform is what determines the longevity of the solution, if we have to rework our solution. For example, I'm currently exploring integrating TypeORM (based on @raymondfeng's implementation because we feel it's a more active solution than the connectors.

3. Speed of development cycle is what I believe keeps developers engaged to a framework. The faster we can see results of the code we write, the faster we can build. The API-first approach has been amazing for us but the build and test cycles are extremely long (1 to 2 minutes) for a solution our size. We looked into optimizations but it seems to be something that should be core to the framework. Alternatively, say, if documentation was available to how we could plug-in latest TypeScript RC to use latest build features, or how to integrate VS Code debugger, it would save us a tonne of time and effort. Additionally, exploring solutions to enable HMR like Nest would be amazing.

Business impact: every build costs us time that we could be dedicating to developing business logic and application.

Hope we can have a discussion about the trajectory you see regarding the above. Happy to meet and chat further again.

[raymondfeng]

@kowsheek Great feedback. We'll come up a course of actions to address your concerns.

[raymondfeng]

Speed of development cycle is what I believe keeps developers engaged to a framework. The faster we can see results of the code we write, the faster we can build. The API-first approach has been amazing for us but the build and test cycles are extremely long (1 to 2 minutes) for a solution our size. We looked into optimizations but it seems to be something that should be core to the framework. Alternatively, say, if documentation was available to how we could plug-in latest TypeScript RC to use latest build features, or how to integrate VS Code debugger, it would save us a tonne of time and effort. Additionally, exploring solutions to enable HMR like Nest would be amazing.

We have been working on #1636 for some time now. But it's blocked by microsoft/TypeScript#30823.

The loopback-next repo is set up to allow your development against latest master.

1. To use latest version of TypeScript, you can simply change the typescript version in loopback-next/packages/build/package.json.
2. The loopback-next/sandbox is a magic directory to either drop in your application or create a symbolic link to your application. Afterward, run npm i from loopback-next so that your application starts to use @loopback/* directly from the file system.

[raymondfeng]

As developers and users of the ecosystem, we need documentation. Currently, we sift through LB3 and LB4 documentation and code to find what we need. If you look at competing frameworks such as Nest, their documentation looks and feels comprehensive and coherent. As developers we sometimes fail to appreciate the need for aesthetically appealing content - as consumers of the content, it's paramount.

We see some of the pains. The team is in discussion to improve the layout and flow so that developers can follow naturally by their development tasks. We also plan to add more diagrams to visualize the key building blocks to help you understand the big picture upfront.

[sbacem]

what about TypeOrm, will be a package for this ?

[raymondfeng]

what about TypeOrm, will be a package for this ?

Do you expect a package to wrap TypeORM as LoopBack 4 repositories? Otherwise, you can use TypeORM as-is, for example, in a controller class.

[raymondfeng]

Please join the discussion at #2925.

[sbacem]

I wish to have package/doc like in nestjs

why our team wanted to change Juggler by TypeOrm ?

• Juggler need more doc
• Not have query Builder for complex query
• The relation clearer in TypeOrm ( for developper have used Doctrine or Hibernate)

This is the feedback of our team after 5 months working with loopback.
Big thanks for this good framework, we won plenty of time with amazing CLI.
I hope juggler will be improved in juggler-next.

[bajtos]

Speed of development cycle is what I believe keeps developers engaged to a framework. The faster we can see results of the code we write, the faster we can build.

Personally, I am unhappy about the lack of maturity of TypeScript support for medium- to large-sized projects. Build + test cycle in loopback-next monorepo takes 3+ minutes, it make TDD pretty much impossible :( I totally understand your frustration!

We have been looking into ways how to improve the situation for months. As @raymondfeng already commented, we are currently blocked by a limitation in TypeScript - microsoft/TypeScript#30823.

However, we can at least enable incremental builds, both for loopback-next monorepo and LB4 applications using @loopback/build, see #2928

if documentation was available to how we could plug-in latest TypeScript RC to use latest build features, or how to integrate VS Code debugger, it would save us a tonne of time and effort.

+1 to document how can LB app developer tweak their TypeScript configuration (or the compiler version used) and also how to integrate with VS Code debugger. It would be great to have new issues opened, one for TypeScript and another for VS Code debugger.

At the moment, projects scaffolded using lb4 CLI tool are relying on @loopback/build to provide build tools like typescript, tslint, etc. While it makes project infrastructure files smaller, it also makes it more difficult to customize them. I think it would be great to have a new command, e.g. npm run eject, that would convert a project based on @loopback/build to a standalone project consuming all build dependencies directly. Quoting from create-react-app:

If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.

Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc.) into your project as dependencies in package.json
All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.

---

Additionally, exploring solutions to enable HMR like Nest would be amazing.

+1, HMR would be awesome. Can you please open a new issue to keep track of this feature request?

[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.

[stale]

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.