<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-29 15:25 GMT+00:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><br><div class="gmail_quote">2015-01-29 16:21 GMT+01:00 enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra">Non concordi sul fatto che sia un delirio, sul fatto che sia creato da sviluppatori per sviluppatori o su entrambe?<span><font color="#888888"></font></span></div></blockquote></div><br></div></span><div class="gmail_extra">Sulla seconda direi che non sia un male.<br></div><div class="gmail_extra">In fondo e' uno strumento che serve agli sviluppatori. Quando fai una cosa che possono usare i bimbominkia (chi ha detto PHP?) poi non ti lamentare se lo usano sopratutto loro.</div></div></blockquote><div><br></div><div>Il problema e' che poi i servizi vanno mantenuti e ci vanno fatte sopra le operations. </div><div>C'e' parecchia esperienza in tutto questo. E al di la della buzzword "devops", tipicamente ci sono persone che sono molto brave a scrivere codice, progettare interfacce e compagnia... e persone che sono molto brave a mettere in piedi servizi. Quando hai gli sviluppatori che pensano un tool senza molto input da parte della seconda categoria di persone, hai disastri in attesa di accadere.</div><div><br></div><div>I tizi di node.js ti suggeriscono come buona pratica di prendere il webserver che hai nella standard library (e fin qui poco male, ma adesso ci arriviamo) e usare quello. In pratica l'applicazione e il webserver vivono nello stesso mondo. Che sembra bello, si. Solo che e' anche una forma piuttosto estrema di violazione di separations of concerns e di unnecessary tight coupling.</div><div><br></div><div>Tipicamente nella maggior parte dei contesti hai un webserver (che parla HTTP), hai un qualche tipo di application server (che smazza da HTTP alla tua applicazione) e hai appunto la tua applicazione. Entro certi limiti, i tre pezzi sono intercambiabili (e si parlano in modo standard). Per esempio in Python puoi partire con Apache e quando hai un problema di scalabilita' sulle richieste sostituirlo con NGINX. Ora l'effort di sviluppo che hai fatto e' stato nell'applicazione, che tipicamente non sa un accidenti di chi chi sta davanti. E sempre tipicamente non e' particolarmente influenzato dal fatto che giri Apache o NGINX o LightHTTPd o chi per loro. Se domani qualcuno scrive un web server che fa i giri intorno ad NGINX, puoi metterlo su senza grossi problemi.</div><div><br></div><div>Se tieni tutto quanto integrato diventa tutto molto piu' complicato. In questo ci sono una serie di problemi accessori, come per esempio... chi fa la terminazione SSL? Avere tutto in un unico blocco monolitico vuole dire cercare guai quando fai le operations. </div><div><br></div><div>Poi certo... davanti a node.js ci si mette spesso nginx a fare da *load balancer* o da proxy... ma stavano cosi' bene separati per i fatti loro, voglio dire. E allora... perche' forzarmi questa architettura quando semplicemente potevo scegliermi i componenti come mi pareva, lasciando chiaro quello che e' il mestiere del webserver e quello dell'applicazione.</div><div><br></div><div>Poi per inciso, non prendo troppo sul serio nel 2015 chi mi suggerisce che semplicemente node.js "non blocca", quando e' evidente che non blocca *sull'IO* e ignorare il fatto che si... a volte si blocca sulla CPU (tipo perche' ci sono da fare dei conti). E questo te lo dovrebbero scrivere a caratteri cubitali sulla home-page: "E' tutto magico finche' improvvisamente qualche front-end developer che si e' riciclato backend engineer non deve fare qualcosa piu' che smazzare un po' di rest API e fare qualcosa con la CPU. A questo punto buttate tutto e usate qualcosa di diverso oppure divertitevi a scrivervi uno scheduler cooperativo e spezzatevi a mano i task CPU bound per funzionare. O passate per un sistema di worker; e divertitevi a fare tutto questo in javafuckinscript."<br></div><div><br></div><div> </div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>