<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-07-17 10:38 GMT+02:00 Gaetano Giunta <span dir="ltr"><<a href="mailto:giunta.gaetano@gmail.com" target="_blank">giunta.gaetano@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>Simone Magnaschi wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Marco grazie, non so se calza con la mia situazione
        attuale ma mi sembra un ottimo spunto di riflessione.
        <div>Una domanda hai server differenti per i WS e i "client" di
          questo WS o è la stessa macchina? Quanto pesa il networking
          per tutte le chiamate al WS in termini di performance?</div></div></blockquote></span>
    In effetti una 'feature' che mi sembra relativamente semplice da
    implementare ma raramente vedo in pratica e' quella di avere un
    transport-layer flessibile nelle librerie di tipo WS.<br>
    <br>
    A parte il trasporto http si potrebbe prevedere il trasporto
    in-memory, evitando quantomeno il parsing relativo al protocollo
    http, ma mantenendo la possibilita' di mettere in cache le risposte.<br></div></blockquote><div><br></div><div>IMHO il gioco non vale la candela, sopratutto se poi pensi di usare sistemi di caching HTTP (eg reverse proxy) che migliorano le performance riducendo di molto la complessità applicativa.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Volendo puntare al massimo delle performances si potrebbe anche
    bypassare la serializzazione+deserializzazione in json, e ritornare
    direttamente gli oggetti generati (tipicamente con l'introduzione
    della cache ci sarebbe comunque una serializzazione, probabilmente
    usare igbinary e' l'opzione migliore per quella).<br>
    Per evitare problemi di references e memleaks, gli oggetti generati
    dalla tua api dovrebbero essere gia' in partenza di tipo 'struttura'
    prima del loro encoding.<br></div></blockquote><div><br></div><div>Tutto vero, ma credo che sia utile solo in situazioni VERAMENTE ESTREME (poi magari mi sbaglio :D )</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Rimarrebbero i vantaggi:<br>
    - api WS disponibile con zero sforzo<br>
    - separazione netta tra la tua 'facade' sui database legacy
    compositi e il codice front che consuma i ws<br></div></blockquote><div><br></div><div>Che IMHO è il vero vantaggio, anche a costo di un pò più di complessità e "meno pulizia" nel codice.</div><div><br></div></div><div class="gmail_signature">Ciao<br>       Marco<br>--<br>mob:     +39 393 9249923<br>skype:   marco.moscaritolo<br>twitter: @mavimo</div>
</div></div>