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

Qual è la prestazione più veloce saggia? Creando un'API REST e facendo in modo che la tua app Web utilizzi l'API REST per eseguire tutte le interazioni con il tuo database O eseguire una query direttamente sul tuo database (ovvero utilizzando qualsiasi oggetto tipico utilizzato dalla tua lingua per eseguire query su un database come JDBC per Java)?

Il modo in cui lo vedo con REST:

1. Si crea un oggetto nel codice per chiamare il metodo REST
2. Chiama il metodo http
3. Il codice all'interno dell'API REST interroga il database
4. Il database restituisce alcuni dati
5. Il codice API REST raggruppa i dati in Json e li invia al tuo client
6. Il client riceve la risposta Json / XML
7. Mappa la risposta a un oggetto nel tuo codice

D'altra parte, interrogando direttamente un database:

1. Si crea un oggetto con stringa di query per eseguire una query sul database
2. Il database restituisce alcuni dati
3. Mappa la risposta a un oggetto nel tuo codice

Quindi questo non significa che l'uso di un'API REST sarebbe più lento? Forse dipende dal tipo di database (SQL vs NoSQL)?

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

Estrarre il database è una buona pratica. Se sei preoccupato per la velocità, puoi esaminare la memorizzazione nella cache dei dati in modo da non dover toccare il database per gestire la richiesta.

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

Se la tua preoccupazione è la velocità, 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 .

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

Supponi di codificare un database. Cosa faresti se scegli di modificare il tuo archivio dati sottostante. Quanto sarebbe difficile da fare se sei strettamente associato al negozio sottostante?

La vera risposta è che 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.

Il modo in cui lo vedo con REST:

1. Si crea un oggetto nel codice per chiamare il metodo REST
2. Chiama il metodo http
3. Il codice all'interno dell'API REST interroga il database
4. Il database restituisce alcuni dati
5. Il codice API REST raggruppa i dati in Json e li invia al tuo client
6. Il client riceve la risposta Json / XML
7. Mappa la risposta a un oggetto nel tuo codice

C'è un errore nel tuo pensiero.

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

Pertanto la risposta di @Klees non è del tutto corretta :

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

Quando si ha a che fare con i risultati memorizzati nella cache, non vi è alcun impatto sulla propria applicazione: la consegna di risposte note a domande note potrebbe essere effettuata tramite proxy inversi.

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

Prendi in considerazione 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, è possibile che le prestazioni della cache vengano migliorate in un servizio condiviso. Soprattutto se si dice che centinaia di app desktop accedono direttamente allo stesso database (non tramite un'app Web!) E che eseguono le stesse query, ci potrebbe essere un notevole miglioramento. Tuttavia, anche in questa architettura, il motivo principale per l'introduzione di 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'introdurre un livello di servizio aggiuntivo. La memorizzazione nella cache, l'astrazione del database ecc. Potrebbero essere gestite a livello di accesso ai dati nella stessa applicazione.

Dipende.

Ovviamente, più strati nel 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 li vedrai frustrati. La soluzione è spostare il DB in un'altra casella, aggiungere un livello nel mezzo e sebbene per 1 utente, funzionerà più lentamente, quando i mille accederanno, andrà più veloce. (questa è una risposta semplicistica ma in linea di principio vera).

Esistono altri motivi per nascondere il DB dietro un livello di livello intermedio, come la sicurezza.

Non so dove ti perdi, ma è abbastanza chiaro, quando stai usando l'API REST stai facendo un passo in più, e un passo in più "sempre" significa più lentamente quando si tratta di programmazione.

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 portare la tua applicazione su piattaforme diverse.

RIPOSO :

• aperto a più frontend e 1 backend
• devi creare la tua API (o usarne una come Loopback)
• non funziona offline

DB locale:

• non aperti a "livelli", devono sincronizzare l'accesso al back-end
• non è necessario creare un'API, utilizzare l'interfaccia DB
• lavorare offline

QUESTA È DIFFERENZA MOLTO ENORME, LE PERSONE SONO DIMENTICATE DIMENTICATE QUESTI PUNTI