Sequelize orm vs Loopback orm

Question

Sto creando una pausa supportata da PostgreSQL. Mi piace il framework Strongloop Loopback, ottimizza lo sviluppo delle API. Ma come il suo built-in orm rispetto al sequelize? Quali funzionalità avanzate sono sequelizzate come sql orm dedicati, che mancano nel loopback? Forse è meglio restare con il sequelize e usare altri helper per il resto della API rispetto al framework di loopback monolitico?

Answer 1

Tipo di domanda di opinione, non so se appartiene davvero qui. Non vedo molta differenza nell'implementazione ORM, per quanto riguarda il pezzo RDMBS (nosql è un'altra storia). Non riesco davvero a parlare per l'implementazione di Postgres in particolare, dato che purtroppo ho bisogno di usarlo con MSSQL. Ti schizza comunque di lavorare con Hstore o JSON? Pensa a quelle cose che troverai mancanti in loopback in quanto ha generalizzato l'API su tutti i connettori. È un trade-off. Esamini il tuo RDMBS nello stesso modo in cui faresti Mongo, diciamo. Detto questo, strongloop sembra aver realizzato un prodotto qui orientato per l'azienda, quindi scommetto che il supporto dovrebbe essere abbastanza buono.

In una nota a margine, non so davvero se chiamare loopback un framework monolitico sia accurato. Per me, almeno, un fotogramma monolitico sarebbe qualcosa di simile a Rails che ti dipinge in un angolo rispetto all'architettura e che è davvero più orientato al contenuto reso server (vs Fat-client SPAs). Il loopback genera automaticamente un'API di restata conforme allo spavalderia, anche se è compito dell'utente configurare quali rotte/verbi sono accessibili e il controllo ACL. Mentre una certa implementazione dei pezzi è "cotta in forno", è difficilmente monolitica. Finirai per creare tutte queste rotte in qualsiasi altro framework se stai andando con un'architettura Restful. Puoi ancora creare punti finali personalizzati in loopback come meglio credi. Una cosa davvero bella con Loopback è che è possibile decodificare le definizioni dei modelli da set esistenti/legacy in RDBMS. C'è anche un'opzione di sincronizzazione delle definizioni (non ho ancora esplorato in realtà). Controlla this talk, mostra bene la logica del perché è il loopback.

Answer 2

Una cosa degna di nota è che Loopback NON garantisce l'integrità referenziale poiché non impone chiavi esterne a livello di DB. vedere https://github.com/strongloop/loopback-connector-mysql/issues/135

Answer 3

È un po 'in ritardo, ma la risposta per futuri riferimenti: loopback è più di ORM, si tratta di un ORM + Express, in effetti. È possibile utilizzare anche la lib di ORB di loopback (loopback-datasource-juggler) separatamente, ma api di essa non è così intuitiva come Sequelize. D'altra parte, per me, uno dei principali differenziatori era, Loopback è in grado di aggiornare le tabelle del database esistenti, senza distruggere i dati in esso, se si modifica il modello in seguito. Con Sequelize, devi gestirlo manualmente, crea solo il tavolo la prima volta quando lo esegui. Per aggiornare la tabella esistente, è necessario rilasciarla e quindi ricrearla. E si spera che tu ricordi di avere il backup dei dati nella tabella. O modificare manualmente la struttura della tabella.

Il motivo per cui Loopback lo gestisce facilmente, a differenza di Sequelize, non impone l'integrità dei dati a livello di database, come @ gurg-hackpof menzionato sopra.