Per suggerimenti nei commenti, proverò a riformulare la mia domanda per riflettere meglio il mio problema:
Devo presentare gli utenti (pochi in un primo momento, il maggior numero possibile in seguito) con un sito web. Lì saranno in grado di sfogliare i vari dati. I dati saranno forniti da un db "cache" locale. Gli utenti dovrebbero essere sempre presentati con dati il più freschi possibile.
La fonte per la maggior parte dei dati sarà costituita da servizi esterni con possibili limiti, tempi di risposta lunghi, ecc. Anche il processo di elaborazione dei dati da tali origini allo schema del db locale non è immediato (conversione, calcoli, disaccoppiamento, ricreare relazioni ecc.)
Sta mettendo tutto il codice di data mining e processamento ok (e facendo tutto ciò che funziona nel tempo che intercorre tra gli utenti clicca su un link e ricevi dati), o è la mia seconda idea - un'altra, un'applicazione di data miner sempre in esecuzione - meglio? O c'è un'altra opzione?
Vecchio testo:
Attualmente sto sviluppando un sito Web che presenterà sia i propri dati (profili utente, il loro contenuto inviato) sia i dati ottenuti da varie fonti esterne (ad esempio tramite chiamate al servizio web).
Le fonti varie avranno vari limiti delle chiamate consentite, risponderanno con velocità variata ecc.
No, l'utente dei dati viene presentato dovrebbe essere, per impostazione predefinita, il più fresco possibile con un'opzione per richiedere l'aggiornamento (se non aggiornato di recente).
Ho iniziato lo sviluppo in ASP.NET (nel bene o nel male), con alcuni modelli e alcune personalizzazioni, e un bel po 'di codice ho trovato una dimostrazione pratica del concetto. Ma poi ho iniziato a pensare a operazioni su larga scala.
La visualizzazione dei dati memorizzati nella cache è semplice e veloce, non ho sbagliato. Il rinfresco però è un problema.
a) Richiedere dati per un utente è veloce, ma mangerà rapidamente attraverso le chiamate API consentite. b) La richiesta di dati per più utenti (per le API che lo consentono) consente di risparmiare una grande quantità di chiamate api, ma richiede linearmente più tempo (non 1: 1, ma richiede tempo per richiedere, ricevere e analizzare decine di volte più dati di singola richiesta).
Arriva anche il problema di superare i limiti. Di solito ciò costringerebbe l'app a annullare l'aggiornamento o attendere qualche secondo per una nuova tolleranza. Ma non vedo davvero l'utente che attende con piacere diversi secondi per il caricamento della pagina.
Attualmente sto considerando di sventrare la parte di raccolta dei dati del sito Web e di spostarla in un'unica applicazione gestionale, condividendo un database con il sito web. Il sito web fornirebbe informazioni che gli utenti hanno bisogno di aggiornare i loro dati, l'app dovrebbe bilanciare il carico dei servizi esterni per utilizzarli in modo efficiente (non limitato a "quando un utente apre un sito Web") e mantenere i dati il più freschi possibile - anche possibilmente mantenendo una parte della franchigia per gli aggiornamenti forzati.
Ora, il problema principale che vedo con questo è il costo dell'hosting non solo del sito Web, ma anche di uno sfondo che esegue un'applicazione .NET. Ma supponiamo che il costo non sia rilevante. Quello che temo davvero è che io compro la soluzione. Potrei semplicemente aggiungere altro sito Web in Ajax e attendere che la richiesta venga completata in background (quando le chiamate diventano disponibili).
Quindi, qualcuno ha un'esperienza simillar? Sono particolarmente interessato allo scenario in cui è stato ridimensionato, cioè possiamo presumere che ci sarà sempre un deficit di chiamate disponibili.
PS Mi preoccupo anche di mantenere il sito web (che può essere attivato in modo indipendente da molti utenti) dal tentativo di aggiornare gli stessi record due volte ecc. - Immagino che dovrei mettere alcune protezioni aggiuntive, bloccare o almeno segnare i record che subiscono l'aggiornamento ecc. . Un sacco di codice solo per risolvere il problema che non esisterebbe con un singolo back-end ....