The ORM analysis identified LoopBack as the generally preferred candidate, but TypeORM was a close second. The team chose to engage TypeORM because our project is written in Angular and we wanted to leverage isomorphic TypeScript.
While using TypeORM, development encountered a number of issues. Some are documented on GitHub. Some were even closed. While the TypeORM team was extremely responsive and helpful, the struggle to set up was an early red flag, and forecasting on early metrics put our project timeline in jeopardy.
By stubbing our toe on some of these issues, it became evident that TypeORM documentation was not as strong as it had originally appeared. The TypeORM team made up for this in part by being responsive on GitHub, but LoopBack 3.0’s comprehensive documentation was starting to look comparatively better.
Those minor issues were inconvenient but tolerable. Two major issues were central to the shift to LoopBack:
Both of these issues are decisive. Angular CLI is a best-practice tool for Angular development. It is particularly critical for rapid and tested development of Angular Universal applications.
Granted, LoopBack 3.0 does not support isomorphic typing, but issue 2 above removes the key incentive for using TypeORM in the first place.
LoopBack maintains a number of benefits which have made it a great resource ever since:
While LoopBack 3.0 does not have isomorphic types, it does leverage standardized JSON model definitions which can be easily mirrored in the UI. We are able to leverage consistent entities from the database, through the server, into the UI, although we have to duplicate definitions a bit.
LoopBack isn’t perfect. Desired features include:
LoopBack 4 is in active development and looking for contributors. It already supports some of the above-noted features. It’s not yet production ready, but I hope you’ll join me in supporting that project as an innovation in the space.