<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-17 11:22 GMT+01:00 Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" target="_blank">roberto@unbit.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">> [...]<br>
>> Forse mi sono perso qualcosa, ma quale è la differenza tra questa<br>
> soluzione ed avere Apache prefork con N + M processi?<br>
><br>
> La soluzione che hai indicato è quella tipica frontend + backend, nel caso<br>
> in cui il frontend sa gestire 10K ma il backend no (e spesso non deve<br>
> farlo).<br>
><br>
> Ma davvero ci sono vantaggi in un ulteriore livello, in cui l'applicazione<br>
> Django minimale fa da frontend e tutto il resto (inclusa connessione al<br>
> database) la fa un ulteriore backend?<br>
><br>
<br>
</div></div>Ti faccio l'esempio di un progetto sui cui ho lavorato di recente che deve<br>
fornire notifiche (tramite SSE) in tempo reale, scrivendo dei testi in un<br>
div.<br>
<br>
La parte SSE all'inizio deve essere comunque autenticata, deve prendere<br>
dei dati dal db per scegliere che tipo di informazioni mi servono, dopo di<br>
che django non serve piu', i dati che mi arrivano sono presi da redis.<br>
<br>
Quindi una volta che django ha autenticato l'utente, e scelto cosa fargli<br>
vedere, passa la connessione (la tecnica usata e' irrilevante)</blockquote><div><br></div><div>Irrilevante, ma altamente dipendente dal sistema operativo e non tutti la supportano :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 al livello<br>
"back-backend" (chiamiamolo cosi') che si occupa di leggere in maniera non<br>
bloccante da una coda redis e inviare le informazioni (e la cosa potrebbe<br>
durare ore). A questo punto django ha finito il suo ciclo di richiesta ed<br>
e' pronto a gestirne un' altra.<br>
<br></blockquote><div><br></div><div>In effetti questo è un caso particolare che non avevo considerato.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Il giro e'<br>
<br>
proxy non bloccante -> application server bloccante -> application server<br>
non bloccante.<br>
<br>
Non parlerei di vantaggi, ma di necessita', far digerire a django il<br>
modello gevent (o quello che sia) e' talmente tedioso come processo che<br>
tanto vale aggiungere un ulteriore strato. E' un po' piu' macchinoso senza<br>
dubbio, ma non ha (teoricamente) sorprese sul medio e lungo termine.<br>
<br></blockquote><div><br></div><div>Questo non è un caso d'uso dei web sockets?</div><div>Il problema è l'autenticazione; con la soluzione attuale il back-back-end riceve dati da una fonte sicura.</div><div>Però con i websockets potresti disaccoppiare completamente i due backend (?).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Io non metto in dubbio che avere tutto non bloccante da cima a fondo sia<br>
l'approccio migliore, ma una azienda che ha investito in Django non passa<br>
a tornado da un giorno all'altro (o a nodejs o a Go o a Rust ecc. ecc.),<br>
quindi bisogna ricorrere a workaround che comunque mantengano un certo di<br>
grado di solidita'. (e poi devo ancora trovarne di framework<br>
non-blocking-friendly che siano al livello di django)<br>
<br></blockquote><div><br></div><div>Vero, ma bisogna stare attenti a non cadere nella sindrome dell'utilizzo a tutti costi perchè è l'unica cosa che conosco/conoscono gli altri.</div><div><br></div><div><br></div>
<div>Ciao  Manlio</div></div><br></div></div>