Ho un'applicazione che ha generato una discussione piuttosto accesa tra un paio di sviluppatori.
Fondamentalmente, è diviso in un livello web e un livello backend. Il livello Web raccoglie le informazioni tramite un semplice modulo Web, archivia questi dati come un documento JSON (letteralmente un file .json) in una cartella di controllo utilizzata dal back-end. Il back-end interroga questa cartella ogni pochi secondi, preleva il file e svolge le sue funzioni.
I file stessi sono molto semplici (vale a dire tutti i dati di stringa, nessun nidificazione) e circa 1-2k al loro massimo, con il sistema che impiega la maggior parte del tempo inattivo (ma scoppiando fino a 100 messaggi in qualsiasi momento). Il processo di elaborazione del back-end richiede circa 10 minuti per messaggio.
L'argomento arriva quando uno sviluppatore suggerisce che l'uso del filesystem come livello di messaggistica è una cattiva soluzione, quando qualcosa come un database relazionale (MySQL), un database noSQL (Redis) o anche una semplice chiamata API REST dovrebbe essere usato invece.
Va notato che Redis è utilizzato altrove nell'organizzazione per la gestione dei messaggi in coda.
Gli argomenti che ho sentito analizzano come segue
A favore di file flat:
-
I file flat sono più affidabili di qualsiasi altra soluzione, poiché il file viene spostato solo da una cartella "watch", in una cartella "processing" dopo che è stato raccolto e, infine, in una cartella "done" una volta terminato . Non vi è alcun rischio che i messaggi scompaiano escludendo bug di livello molto basso che comunque potrebbero infrangere altre cose.
-
I file flat richiedono una sofficità tecnica meno comprensibile - solo
cat. Nessuna query da scrivere, nessun rischio di far scappare accidentalmente un messaggio dalla coda e averlo perso per sempre. -
Il codice di gestione dei file è più semplice delle API di database dal punto di vista della programmazione, poiché fa parte della libreria standard di ogni lingua. Ciò riduce la complessità complessiva della base di codice e la quantità di codice di terze parti che deve essere introdotto.
-
Il principio di YAGNI afferma che i file piatti funzionano bene in questo momento, non è necessario dimostrare di passare a una soluzione più complicata, quindi lasciala.
In favore di un database:
-
È più semplice scalare un database rispetto a una directory piena di file
-
I file piatti rischiano che qualcuno copi un file "completato" nella directory "guarda". A causa della natura di questa applicazione (gestione della macchina virtuale), ciò potrebbe causare una perdita di dati catastrofica.
-
Richiedere una maggiore sofisticazione tecnica per l'app T / S significa che lo staff non istruito ha meno probabilità di rovinare qualcosa semplicemente spaccando le cose.
-
Il codice di connessione DB, specialmente per qualcosa come Redis, è almeno altrettanto robusto delle funzioni di gestione file della libreria standard.
-
Il codice di connessione DB è visibilmente (se non funzionalmente) più semplice dal punto di vista dello sviluppatore, poiché è più alto della manipolazione dei file.
Da quello che vedo, entrambi gli sviluppatori hanno molti punti validi.
Quindi, tra queste due persone, lo sviluppatore pro-file o lo sviluppatore pro-database, quale è più in linea con le migliori pratiche di ingegneria del software e perché?