Caching lato server in openrasta

Question

Ho un sito che viene sottoposto a polling piuttosto difficile per la rappresentazione JSON delle stesse risorse da più client (browser, altre applicazioni, script shell unix, script python, ecc.).

Vorrei aggiungere un po 'di cache in modo tale che alcune delle risorse siano memorizzate nella cache del server per un periodo di tempo configurabile, per evitare il colpo della CPU di gestire la richiesta e serializzare la risorsa su JSON. Ovviamente potrei memorizzarli da solo all'interno dei gestori, ma poi prenderei il risultato della serializzazione su ogni richiesta e dovrei modificare anche molti gestori.

Ho esaminato il modulo di caching di openrasta ma penso che questo sia solo per il controllo della cache del browser?
Quindi qualsiasi suggerimento su come posso ottenere openrasta per memorizzare nella cache la rappresentazione renderizzata della risorsa, dopo che il codec l'ha generata?

Grazie

Answer 1

openrasta-caching ha supporto preliminare per il caching lato server, con un'API è possibile associare alla cache di asp.net lato server, utilizzando l'attributo ServerCaching. Detto questo non è completo, né è openrasta-caching per quella materia. È uno 0,2 che avrebbe bisogno di un paio di giorni di lavoro per arrivare a una buona v1 che supporta completamente tutti gli scenari che volevo supportare che l'infrastruttura di caching asp.net attualmente non supporta (soprattutto, rendere la cache in OpenRasta lavoro esattamente come un intermediario http piuttosto che un oggetto e uno centrico come esiste in asp.net land, incluso il controllo client della cache del server per quelle volte che si desidera consentire al client di forzare il server a ripetere la query). Poiché attualmente non ho alcun progetto client che lavori sulla memorizzazione nella cache, è difficile giustificare qualsiasi ulteriore lavoro su quel plugin, quindi non sto codificando nulla per ora. Però ho 4 giorni gratuiti, quindi DM me se vuoi che il caching di openrasta sia portato a 0.3 con qualsiasi requisito tu abbia in grado di soddisfare 4 giorni di lavoro.

È possibile implementare qualcosa di più semplice utilizzando un IOperationInterceptor e collegando la pipeline asp.net usando questo, o essere più web-friendly e implementare il caching fuori processo utilizzando calamaro e fare affidamento su openrasta-caching per generare la cache HTTP corretta Istruzioni.

Detto questo, per il tuo problema, potresti non aver nemmeno bisogno del caching del server se il costo è in json. Se si esegue il mapping di un'ultima modifica o di un Etag a quello restituito dal gestore, verrà generato correttamente un 304, ove appropriato, ed eviterà il rendering di json alltogether, a condizione che il client esegua richieste condizionali (e dovrebbe).

Esiste anche una API proposta per consentire di ottimizzare ulteriormente l'API eseguendo una prima query sull'ultima modifica/etag per restituire il 304 senza recuperare alcun dato.