Sincronizza / invia dati tra sistemi front-end e back-end per un sito e-commerce

1

Un cliente recentemente ha sviluppato un nuovo sistema di gestione delle scorte .net sviluppato che si aggancia al proprio EPOS e consente ai propri negozi di tenere traccia di ordini, prodotti, clienti, ecc. da un unico database centrale che utilizza MS SQL Server 2003. Il client spera di usarlo come un'opportunità per rinnovare / ri-sviluppare il loro sito per utilizzare anche questo database back-end centralizzato.

Ho esperienza con l'e-commerce, ma questa è la prima volta che sviluppo un sito che ha bisogno di lavorare con i sistemi di back-end delle aziende.

Speravo di utilizzare una piattaforma off-the-shelf come Magento per semplificare il processo di sviluppo e consentire futuri aggiornamenti e l'uso di plug-in / moduli. Tuttavia, dopo aver esaminato lo schema per i loro nuovi sistemi di back-end, è evidente che potrebbero esserci diversi problemi. Il loro database ha molti problemi di progettazione, le tabelle sono mal normalizzate e il loro approccio al design del database mi sembra datato.

Se dovessi utilizzare una piattaforma off-shelf come Magento, l'unico modo in cui posso vederlo funzionare è ricreare tutti i prodotti / categorie / clienti nel front-end DB, questo potrebbe dover essere fatto manualmente perché delle differenze di schema tra il backend (centralizzato db) e frontend (magento db). Sarebbe un compito immenso e creerebbe un nuovo problema su come gestire la replica dei dati (prodotti, livelli di scorte, prezzi, ordini, stati degli ordini). Il cliente attualmente gestisce tutti i prodotti e ordina i dati sul proprio sistema .net e vuole continuare a farlo, quindi ci dovrebbe essere un modo per aggiornare i siti db quando apportano modifiche ai loro sistemi back-end (per esempio nel caso l'ordine è stato spedito / annullato / ecc.). Allo stesso modo, il database centralizzato dovrebbe essere aggiornato dal front-end quando un cliente fa un ordine, aggiorna i livelli delle scorte, ecc. Questi sono solo due esempi di dati che dovranno essere sincronizzati, ma sono innumerevoli altri scenari.

Qualcuno ha esperienza di lavoro con Magento o altre piattaforme in situazioni simili a quelle sopra? Come hai gestito la replica dei dati e l'invio di dati tra il db centralizzato back-end e il front-end db?

Sto attraversando un periodo difficile per trovare il miglior setup / architettura per un sito come questo, qualsiasi suggerimento nella giusta direzione sarebbe molto apprezzato.

In retrospettiva non posso fare a meno di ritenere che la soluzione migliore sarebbe quella di creare una piattaforma interna da zero che possa connettersi direttamente al loro database centralizzato invece di utilizzare una piattaforma off-shelf e preoccuparsi della sincronizzazione dei dati tra back-end / fine frontale. Qualche idea?

    
posta Jeemusu 10.10.2013 - 12:04
fonte

1 risposta

2

Non consentirei al front-end di connettersi direttamente al database mission-critical. Questo è un problema di sicurezza. Il tuo front-end è normalmente in "wild" (pubblico) e quindi è sempre indirizzato agli hacker per tutto il giorno. Se uno arriva attraverso il tuo database produttivo viene violato e la società è ferma.

In tali situazioni introduco sempre una API backend stretta da utilizzare dal front-end. Il front-end può accedere alle informazioni di back-end solo a questa API; nessun altro modo! L'API deve essere sicura per il tipo e il più piccola possibile - inserire solo ciò che è veramente necessario. Crea funzioni API per i tuoi casi d'uso è un buon inizio (ad esempio AcceptOrder (Guid orderno) .Non ci sono API generiche in cui uno può riuscire a iniettare query e logiche generali.In backend considera ogni parametro API in ingresso come potenzialmente compromesso. esempio sfuggirli prima di inviarlo a qualsiasi db-engine ecc.

La domanda se hai bisogno di un frontend esplicito db a parte l'API backend dipende principalmente dalle prestazioni dell'API / rete tra front e backend e se il frontend mostra i dati da una sola fonte di backend. In una soluzione di e-commerce è probabile che ne hai bisogno a causa delle prestazioni. In questo caso guarderei il database di frontend come una sorta di cache dei dati lato server. Alcuni dati possono essere memorizzati in modo semplice (ad es. Valori di ricerca come categorie, ecc.) Altri sono più difficili (come il numero di articoli disponibili). Forse alcuni di loro non possono essere memorizzati nella cache in un db front-end.

Come inizio della valutazione della migliore strategia di sincronizzazione, analizzerei ogni tabella in combinazione con i casi d'uso. Quanto spesso vengono utilizzati? Quanto breve-vivere / quanto spesso cambia sono i dati al loro interno? ecc. Non farei una sincronizzazione bidirezionale generale tra i database. Scaricamento di parti del backend-db nel frontend-db è ok ma non fare mai un dump dump dal frontend- al backend-db (sicurezza).

Spero che questo aiuti un po 'o almeno ti dia input per i tuoi pensieri. Alcune decisioni difficili sono davanti a te; -)

Aggiornamento su SOAP: SOAP non sarebbe la tecnica peggiore per questo, ma anche non quella con le massime prestazioni; almeno non fuori dalla scatola. La progettazione di un'API SOAP richiede alcune considerazioni aggiuntive, come l'autenticazione e il raggruppamento di molti dati in alcune chiamate SOAP (le chiamate SOAP sono "costose", quindi non provare a fare migliaia di esse in un secondo ;-))

SOAP è un protocollo standardizzato e quindi può essere utilizzato in molti linguaggi di programmazione su molte piattaforme. Se conosci la tua piattaforma e hai sia fine (frontend e backend) che il tuo controllo, potresti trovare un protocollo più nativo allo stack tecnologico e quindi più veloce. Puoi quindi anche codificare il tuo TCP, se lo desideri, ma fai attenzione con questo, poiché avrà anche bisogno di una buona autenticazione e sicurezza.

Vorrei iniziare con SOAP o uno più nativo del mio stack di programmazione (ad esempio .Net: WCF Binary). Puoi anche pensare a una REST-API (WebAPI in .Net).

Aggiornamento sulla spinta dei dati dal back-end al front-end: Lo considererei solo per i dati che cambiano molto e il valore corrente è importante. Ad esempio il back-end può segnalare i conteggi delle scorte al front-end. Ma in qualche modo mi sembra sbagliato visto che il back end deve funzionare per front-end anche se non c'è un solo utente sul front-end. Quindi hai un carico di lavoro permanente sul back-end. Queste cose dipendono in realtà da molti dettagli del tuo progetto e dai suoi casi d'uso, direi. È difficile rispondere in generale.

    
risposta data 10.10.2013 - 14:10
fonte

Leggi altre domande sui tag