Utilizzo di file flat vs database / API come trasporto tra frontend e backend

Ho un'applicazione che ha generato una discussione piuttosto accesa tra un paio di sviluppatori.

Fondamentalmente, è diviso in un livello Web e un livello back-end. Il livello Web raccoglie informazioni tramite un semplice modulo Web, inserisce questi dati come un documento JSON (letteralmente un file .json) in una cartella di controllo utilizzata dal back-end. Il back-end esegue il polling di questa cartella ogni pochi secondi, preleva il file ed esegue le sue funzioni.

I file stessi sono molto semplici (ovvero tutti i dati delle stringhe, nessun annidamento) e circa 1-2k al massimo, con il sistema che trascorre la maggior parte del suo tempo inattivo (ma fa scoppiare fino a 100 messaggi in un dato momento). La fase di elaborazione del back-end richiede circa 10 minuti per messaggio.

L'argomento emerge quando uno sviluppatore suggerisce che l'uso del filesystem come livello di messaggistica è una cattiva soluzione, quando invece dovrebbe essere usato qualcosa come un database relazionale (MySQL), un database noSQL (Redis) o persino una semplice chiamata API REST.

Va notato che Redis viene utilizzato altrove nell'organizzazione per la gestione dei messaggi in coda.

Gli argomenti che ho ascoltato si dividono come segue

A favore di file flat:

• I file flat sono più affidabili di qualsiasi altra soluzione, poiché il file viene spostato da una cartella "watch" a una cartella "processing" dopo che è stata prelevata, e infine a una cartella "done" al termine. Non vi è alcun rischio che i messaggi scompaiano, escludendo bug di livello molto basso che potrebbero comunque interrompere altre cose.

• I file flat richiedono meno sofisticazione tecnica per capire - solo cat. Nessuna domanda da scrivere, nessun rischio di far cadere accidentalmente un messaggio dalla coda e farlo sparire per sempre.

• Il codice di gestione dei file è più semplice delle API del 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 introdotta.

• Il principio YAGNI afferma che i file flat funzionano bene ora, non è necessario dimostrare di passare a una soluzione più complicata, quindi lascialo.

A favore di un database:

• È più facile ridimensionare un database rispetto a una directory piena di file

• I file flat hanno il rischio che qualcuno copi un file "finito" nella directory "watch". A causa della natura di questa applicazione (gestione della macchina virtuale), ciò potrebbe causare una catastrofica perdita di dati.

• Richiedere maggiore sofisticazione tecnica a T / S l'app significa che il personale non istruito ha meno probabilità di rovinare qualcosa semplicemente frugando sulle cose.

• Il codice di connessione DB, in particolare per qualcosa come Redis, è almeno robusto quanto le funzioni standard di gestione dei file della libreria.

• Il codice di connessione DB è visibilmente (se non funzionalmente) più semplice dal punto di vista dello sviluppatore, dal momento che è più alto della manipolazione dei file.

Da quello che posso vedere, entrambi gli sviluppatori hanno molti punti validi.

Quindi, di queste due persone, gli sviluppatori pro-file o gli sviluppatori pro-database, quale è più in linea con le migliori pratiche di ingegneria del software, e perché?

Passerebbe a una soluzione che coinvolge database o i sistemi di accodamento menzionati da Ewan

• creare dipendenza da un nuovo sistema complesso sia nel backend che nel frontend
• introdurre complessità inutili e un carico di nuovi punti di errore
• aumentare i costi (incluso il costo di proprietà)

Lo spostamento / ridenominazione dei file all'interno di un singolo volume è garantito per essere atomico su tutti i sistemi operativi attuali, qualunque siano le loro difficoltà in relazione a cose come il blocco di file / record. La gestione dei diritti a livello di sistema operativo dovrebbe essere sufficiente per bloccare i non lavati e per prevenire manipolazioni errate / accidentali da parte di operatori autorizzati (amministratori / sviluppatori). Quindi i database non hanno nulla da offrire, a condizione che le prestazioni della soluzione attuale siano all'altezza.

Nella nostra azienda abbiamo utilizzato interfacce basate su file simili per decenni con grande successo. Molte altre cose sono andate e sono andate, ma queste interfacce sono rimaste grazie alla loro assoluta semplicità, affidabilità e accoppiamento / dipendenza minimi.

Non credo che nessuna delle due soluzioni sia intrinsecamente una cattiva pratica, quindi rispondere quale sia la migliore pratica potrebbe essere difficile.

Non credo che il principio YAGNI si applichi qui se hai a che fare con la scala. "Lavorare" è relativo, se si ha un forte potenziale di perdita catastrofica dei dati e poca capacità di ridimensionamento, non lo prenderei davvero in considerazione. Non sono esattamente sicuro della scala con cui hai a che fare, ma se hai una grande quantità di queste voci, diventa sempre più difficile passare a un nuovo sistema. Quindi, se questo è il caso, direi che un database è la migliore pratica.

MongoDB o redis (non ho esperienza con redis, leggo solo cose buone) dovrebbero andare bene poiché i tuoi dati dovrebbero già adattarsi perfettamente (i documenti json sono spesso banalmente cambiati in documenti BSON per MongoDB). Ha anche un vantaggio in più nel mantenere molti dati in memoria invece che potenziali letture / scritture frequenti sul disco per tutto il tempo. Inoltre, garantisce che letture / scritture simultanee non causino corruzione o blocco.

Se il principal YAGNI si applica qui e i file non sono un collo di bottiglia, si adattano all'ambito e non hanno problemi catastrofici, direi che attenersi ai file è "best practice". Non c'è motivo di cambiare nulla se non ci sono problemi, magari scrivere alcuni test, sottolinearlo e vedere dove sono i limiti e i colli di bottiglia.

Non sono sicuro se un database sia comunque la soluzione in questo contesto. Se stai comunicando con cose sullo stesso server, potresti fare una sorta di IPC, no?

Mentre il bravo 'ol' salva un file e lo copia in una directory fatta è un punto fermo di molti livelli di comunicazione esp. con vecchi sistemi di frame principali e simili. I ragazzi "anti" hanno ragione; in quanto ha molti problemi e casi limite. Che sono difficili da gestire se hai bisogno di affidabilità al 100% e si verificano più spesso man mano che aumenti la frequenza e il volume dei file.

Se controlli entrambi i lati della transazione, ti suggerisco di esaminare alcuni dei molti semplici sistemi di accodamento disponibili. ZeroMQ, RabbitMQ, MSMQ ecc. Anziché un database. Ma come intendi, se non si è rotto ...

La soluzione di database è quella giusta. Risolve molta dipendenza da un particolare host o condizioni al contorno.

Entrambe sono soluzioni simili, tranne per il fatto che il database non è ospitato in un determinato host. Questo elimina i problemi di firewall / accesso con il sistema unix. Abbiamo avuto casi di eliminazione "accidentale" su filesystem e nessuno da incolpare.

Con il database, puoi anche avere lo stesso problema ma puoi attivare il controllo o inserire solo la logica per eliminare le eliminazioni.

Anche nel file system se è necessario inserire l'applicazione nel nome del file, ad esempio OASIS, è necessario creare i file OASIS.john_doe.system1.20160202. Questo diventa noioso e può essere rappresentato più facilmente nel database. Puoi anche avere campi nulli nel database e in base alla logica

È anche facile aggiornare i database piuttosto che un'intera directory di file in caso di eventuali patch o correzioni che potresti voler fare sulle tabelle. Ovviamente puoi farlo sul file system ma l'aggiornamento del database è più intuitivo.

ad esempio, vuoi eseguire nuovamente il test, ma con un sistema diverso da OASIS dire DESERT e john_doe a doe_smith e datare dal 20160101 al 20151231

Facile da generare righe per DESERT / doe_smith / 20151231 dal set originale piuttosto che creare quei file con script di shell.

Quindi, dalla leggibilità, la soluzione di database di estensione punto di vista è migliore.