Svantaggi di base
Eccesso di complessità, ridondanza. Più possibilità di bug (più percorsi attraverso più codice), più tempo per sviluppare, testare e più costi da mantenere, per sempre.
Dati obsoleti
Nel momento in cui i dati nel database cambiano da un'altra fonte rispetto a questo servizio, il server inizia a restituire dati non corretti (o almeno obsoleti). È possibile sperimentare la cache che non è coerente con i dati persistenti. È abbastanza educativo.
Coefficiente di scalabilità e cache
Non appena l'app di test si ridimensiona a migliaia di utenti (la maggior parte delle app di test lo fa, giusto?) e si aggiungono più server, si avrà un problema di coerenza della cache, in cui ciascuno di questi server ha la propria copia di quel JSON cache, e le copie possono dare risultati diversi alle richieste.
Modifica simultanea
Che cosa succede quando arrivano molte richieste simultanee da più utenti? Come si assicura che ogni utente visualizzi informazioni aggiornate e che le modifiche dell'utente non vengano perse? È abbastanza risolvibile. Il database può fornire questo servizio. Come lo fornirai a JSON? È una grande opportunità di apprendimento, ma è questa la tua priorità ora?
Ma il caching è talvolta una buona idea
C'è un posto per il caching. A volte è necessario per le prestazioni. Se il tempo per recuperare i dati dal database è "abbastanza veloce", allora non c'è bisogno di cache.
Forse l'apprendimento è la tua priorità
Stai costruendo un'applicazione di test. È la tua sandbox. Se hai voglia di avere una cache JSON intermedia, non c'è bisogno di giustificarla.
Fallo e impara dall'esperienza.