Cos'è più veloce? Utilizzando l'API REST o interrogando direttamente un database?

Quando aggiungi complessità, il codice verrà eseguito più lentamente. L'introduzione di un servizio REST, se non è necessario, rallenterà l'esecuzione mentre il sistema sta facendo di più.

L'astrazione del database è una buona pratica. Se sei preoccupato per la velocità, puoi cercare nella cache i dati in memoria in modo che il database non debba essere toccato per gestire la richiesta.

Prima di ottimizzare le prestazioni, anche se esaminerei il problema che stai cercando di risolvere e l'architettura che stai utilizzando, non riesco a pensare a una situazione in cui le opzioni del database sarebbero l'accesso diretto a REST.

Se la tua preoccupazione è la velocità, allora sì un servizio di Riposo sarà più lento per i motivi sopra indicati. Tuttavia, la velocità del tipo che descrivi è raramente la preoccupazione principale e, se lo è, può essere affrontata in altri modi. L'ottimizzazione prematura è la radice di tutti i mali .

Considerare se la tua preoccupazione principale è l'interoperabilità (mobile, web, B2B), ora REST è molto interessante perché è indipendente dalla tecnologia.

Supponiamo che tu codice per un database. Cosa faresti se decidessi di cambiare il tuo archivio dati sottostante. Quanto sarebbe difficile da fare se sei strettamente collegato al negozio sottostante?

La vera risposta è dipende , ma spero di averti dato alcune cose a cui pensare!

Se trovi difficile rispondere a questa domanda.

La risposta generale corretta dovrebbe essere: dipende.

The way I see it with REST:

1. You make an object in your code to call the REST method
2. Call http method
3. Code inside your REST API queries the database
4. Database returns some data
5. REST API code packs up the data into Json and sends it to your client
6. Client receives Json/XML response
7. Map response to an object in your code

C'è un errore nel tuo pensiero.

E questo errore deriva dal fatto che non comprendi pienamente REST e i suoi principi. REST non è stato inventato, perché alcuni nerd hanno trovato interessante (ovviamente lo è) inviare oggetti JavaScript via HTTP sul filo. Il vantaggio principale dell'utilizzo di HTTP è la possibilità di utilizzare Caching . Se rendi i tuoi risultati memorizzabili nella cache , allora ci sono meno richieste da fare al DB. E nessun marshalling è coinvolto. La risposta potrebbe essere consegnata direttamente.

La risposta di @Klees è non del tutto corretta :

When you add complexity the code will run slower. Introducing a REST service if it's not required will slow the execution down as the system is doing more.

Quando si hanno a che fare con risultati di cache, non c'è alcun impatto sulla tua applicazione: fornire risposte note a domande note può essere fatto tramite proxy inversi.

L'introduzione di un livello di servizio aggiuntivo comporta sempre un costo aggiuntivo in termini di complessità e prestazioni. Esistono alcuni tipi specifici di architettura in cui l'introduzione di un livello di servizio condiviso (come un'API REST) può migliorare a causa del caching condiviso, ma sembra che non sia il tipo di architettura che hai.

Considera un'architettura in cui hai più app Web o più app desktop che si collegano direttamente allo stesso database. Se eseguono spesso le stesse query, può migliorare le prestazioni per memorizzare nella cache i risultati delle query in un servizio condiviso. Soprattutto se dici che centinaia di app desktop accedono allo stesso database direttamente (non tramite un'app Web!) E eseguono le stesse query, potrebbe esserci un notevole miglioramento. Tuttavia, anche in questa architettura, la ragione principale per introdurre un servizio condiviso sarebbe probabilmente la sicurezza e l'astrazione dei dati piuttosto che le prestazioni.

Ma sembra che tu abbia una singola app web che si collega direttamente al database. In tal caso non vi è alcun vantaggio nell'introduzione di un livello di servizio aggiuntivo. La memorizzazione nella cache, l'astrazione del database, ecc. Possono essere gestiti nel livello di accesso ai dati nella stessa applicazione.

Dipende.

Ovviamente, più livelli nel tuo codice sono più lenti. Ma ... arriva un punto in cui le prestazioni end-to-end dirette non contano tanto quanto la scalabilità. Se hai 1 utente che accede al tuo database su un PC locale, può andare veloce. Se hai un migliaio di utenti che accedono allo stesso DB sullo stesso PC, è probabile che vedrai che tutti si sentiranno frustrati. La soluzione è spostare il DB in un'altra casella, aggiungere un livello nel mezzo e sebbene per 1 utente, si eseguirà più lentamente, quando i mille accedono, andrà più veloce. (questa è una risposta semplicistica ma vera in linea di principio).

Ci sono altri motivi per nascondere il tuo DB dietro un livello intermedio, come la sicurezza.

Non so dove ti perda, ma è abbastanza chiaro, quando stai usando l'API REST stai facendo un passo in più, e il passo extra "sempre" significa più lento quando la programmazione è coinvolta.

Ci sono pro e contro, ma se puoi accedere al database direttamente dalla tua applicazione è sempre meglio chiamarlo direttamente invece di usare l'API Web, ovviamente se usi l'API Web puoi facilmente trasferire la tua applicazione su una piattaforma diversa.

REST:

• aperto a multi frontend e 1 back-end
• devi creare la tua API (o usarne una come Loopback)
• non funziona offline

DB locale:

• non aperto ai "tier", devono avere accesso al tuo back-end per sincronizzare
• non è necessario creare un'API, utilizzare l'interfaccia DB
• funziona offline

QUESTO È QUELLO DI DIFFERENZA ENORME, PERSONE SPESSO DIMENTICATI QUESTI PUNTI