Sequelize orm vs Loopback orm

Question

I'm creating rest api backed by PostgreSQL. I like Strongloop Loopback framework, it streamlines api development. But how its built-in orm compared to sequelize? What advanced features has sequelize as dedicated sql orm, which are missing in loopback? Maybe it's better to stay with sequelize, and use some other rest api helpers than monolitic loopback framework?

Addington

Answer 1

It's kinda late answer but for future references: Loopback is more than ORM, it's an ORM + Express, in fact. You can use Loopback's ORM lib (loopback-datasource-juggler) separately also but api of it is not as intuitive as Sequelize. On the other hand, for me, one of the main differentiator was, Loopback is able to update the existing database tables, without destroying the data in it, if you change your model later on. With Sequelize, you need to handle it manually, it only creates the table first time when you run it. To update the existing table, you need to drop it and then re-create it. And hopefully you remember to get backup of the data in table. Or change structure of the table manually.

The reason that Loopback handles it easily is, unlike Sequelize, it's not enforcing the data integrity on the database level, as @gurg-hackpof mentioned above.

Intersidereal

Answer 2

Kind of an opinion question, don't know if it really belongs here. I don't see much of a difference in the ORM implementation myself, as far as the RDMBS piece goes anyway (nosql is another story). I also really can't speak for the Postgres implementation specifically as I unfortunately need to use it with MSSQL. Does squelize let you work with Hstore or json though? Think those things you will find missing in loopback as it generalized the API across all connectors. Its a trade-off. You query your RDMBS the same way as you would Mongo, lets say. That said, strongloop appears to have made a product here geared for the enterprise so I would wager that the support should be pretty good.

On a side note, I don't really know if calling loopback a monolithic framework is accurate. To me, at least, a monolithic frame work would be something like Rails that paints you in a corner as to the architecture and is really geared more for server rendered content (vs Fat-client SPAs). Loopback automatically generates a swagger compliant Rest API for you, though its up to you to configure which routes/verbs are accessible and the ACL controls. While certain implementation of the pieces are "baked in" its hardly monolithic. You are going to end up creating all these routes in any other framework if you are going with a Restful architecture. You can still create custom end points in loopback as you see fit. One really nice thing with Loopback is that you can reverse-engineer model definitions from existing/legacy sets in RDBMS. There is also a definition sync option (i haven't actually explored yet). Check out this talk, it does well show the logic to why loopback is.

Decretive

Sadly the link to the talk on YouTube is broken - uploader has closed their account. What was the title of the talk, if you remember, please? – Brace

Answer 3

One thing worth noting is that Loopback does NOT guarantee referential integrity since it does not enforce foreign keys at the DB level. see https://github.com/strongloop/loopback-connector-mysql/issues/135

Gusset

Answer 4

In addition to all above, loopback database connectors do not handle failover database connections in a HA cluster setup. Sad :(. And their github issues are not looked at these days.

Windfall

Loopback has now LoopBack 4, so issues in LoopBack 3 are not looked over now, migrate yourself to LoopBack 4 github.com/strongloop/loopback-next – Iscariot