From TypeORM to LoopBack: A Retrospective

The community support has been huge for Which JavaScript ORM should you be using in 2018? That analysis was conducted prior to implementing a project which is now nearing a production release. With the benefit of experience, the project shifted to prefer LoopBack 3.0. This article explains the motivation for that change.

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:

1. TypeORM is incompatible with Angular CLI.
2. Angular Universal was not straightforward to extend into a unified API-and-rendering server. So, we segregated the API server. However, TypeORM is meant for client-side consumption, so we could not achieve core-supported isomorphic types using TypeORM.

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:

1. LoopBack automatically builds your API. This is a core functionality, not an extension.
2. LoopBack automatically creates a Swagger file, which can in turn automatically generate an ERD.
3. LoopBack 3.0 is a well-documented, production-tested tool built around a familiar and extendable Express pattern.

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:

1. Truly isomorphic types, without the need to duplicate code.
2. Better support for database associations.
3. Better support for database configuration-as-code, including CREATE DATABASE
4. Modern JavaScript support including async/await and more.
5. TypeScript support

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.