<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Simone Magnaschi wrote:<br>
</div>
<blockquote
cite="mid:CAOZ-zm8yu9tA9DXdz_NMH8JcyNAsrt8awtF=+ixjjh-t8BNpuQ@mail.gmail.com"
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>
<br>
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>
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>
<br>
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>
<br>
Di contro, non so quanto pesi nel tuo caso specifico il trattamento
http+json: se hai un migliaio di chiamate al secondo probabilmente
molto, se hai una chiamata al minuto e il tempo di processing del
backend e' di 5 secondi invece non varrebbe la pena...<br>
<br>
<blockquote
cite="mid:CAOZ-zm8yu9tA9DXdz_NMH8JcyNAsrt8awtF=+ixjjh-t8BNpuQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>S.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Il giorno 16 luglio 2015 16:58, Marco
Vito Moscaritolo <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mavimo@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mavimo@gmail.com">mavimo@gmail.com</a></a>></span> ha
scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Premetto che sto affrontando un problema
"simile" (banca dati legacy intoccabile con struttura
abbastanza complicata) io ho affrontato il problema nel
seguente modo (premetto che non sono scuro della strada,
ma -per ora- mi sta dando soddisfazioni):
<div><br>
</div>
<div> 1) Definizione di una libreria contenente le entity </div>
<div> 2) Creazione di un WS che tramite json-api
implementa dei WS che espone le entity, questo è quello
che in realtà si relazione con i DBs</div>
<div> 3) Creazione di un client che in base alle
informazioni richieste chiede i dati al WS.</div>
<div><br>
</div>
<div>Ad occhio sembra un pò tutto overkill, però:</div>
<div><br>
</div>
<div> 1) Nel mio caso definire dei model era abbastanza
un delirio (non si sa bene quale entity esistevano, con
che struttura, che relazioni, .. ) considerate che si
tratta di una base dati di dati con strutture definite
nella seconda metà del 1800, evolutesi poi nel tempo in
cui sono state mergiate altre basi dati, avere un
elemento esterno ha reso facile capire quale erano le
strutture realmente esistenti e come queste erano
legate.</div>
<div><br>
</div>
<div> 2) Usando dei WS posso alterare la struttura della
base dati / modo in cui interagire senza intaccare il
lato applicativo (che poi nel mio caso sono più di uno).
I WS sono scritti in silex (scelta discutibile, lo so,
ma per ora mi basta :D ) usando <a
moz-do-not-send="true"
href="https://github.com/neomerx/json-api"
target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/neomerx/json-api">https://github.com/neomerx/json-api</a></a>
e <a moz-do-not-send="true"
href="https://github.com/neomerx/limoncello"
target="_blank">https://github.com/neomerx/limoncello</a>
con delle integrazioni per silex. La cosa MOLTO BELLA di
json-api è che puoi definire in maniera sistematica nel
WS come devono essere idratate le entity richieste in
base ai parametri passati; nelle ultime versioni delle
librerie che ho indicato (a memoria >0.5.1) puoi fare
lazy loading delle entity relazionate abbastanza
banalmente. Il layer di interazione è definito da
EntityRepostory (uno per ogni entity) che si appoggiano
a doctrine DBAL (ma potrebbe essere tranquillamente
direttamente PDO). Questo mi ha permesso di scorporare
il problema di relazione delle entity dalla loro
persistenza in maniera abbastanza semplice. Un WS in
mezzo inoltre obbliga a definire come interagire con le
entity. Usando un WS posso applicare caching a livello
HTTP abbastanza facilmente; la base dati ha > 10^6
oggetti e un tasso di richiesta abbastanza alto, quindi
DEVO prevedere caching, soprattutto perché il tasso di
letture è estremamente maggiore alle scritture (di
diversi ordini di grandezza)</div>
<div><br>
</div>
<div> 3) Questa è la parte che mi convince meno, ma in
sintesi quando chiedo un entity spiego che relazioni
voglio fargli caricare in base a quello che uso, in
questo modo so che entity ho e cosa posso usare, ma al
tempo stesso ho chiamate del genere:</div>
<div><br>
</div>
<div> $myEntity = $myEntityRepository->getById(123,
[</div>
<div> 'my_entity.author',</div>
<div> 'mia_entity.comments',</div>
<div> ]);</div>
<div><br>
</div>
<div> foreach ($myEntity->comments as $comment) {</div>
<div> var_dump($comment->getTitle());</div>
<div> }</div>
<div><br>
</div>
<div>che come potete ben notare fanno si che possa avere
entity inconsistenti (che è male) ma per ora è un
problema che sto sopportando abbastanza facilmente (alla
fine i controller dei client fanno poche chiamate e
ottengo un numero limitato di oggetti che devo
mostrare/gestire).</div>
<div>Per la parte di persistenza quando persisto la entity
NON vado a persistere le informazioni figlie con un
unica chiamata ma eventualmente con chiamate a cascata.</div>
<div><br>
</div>
<div>NB: questo è legato al mio use case dove le entity
sono solo in GET, pochissime (100k al mese) PUT e POST
oltre a nessuna DELETE (tutti i dati sono storicizzati e
non cancellabili).</div>
<div><br>
</div>
<div>Non credo matchi esattamente con il tuo problema,
quindi magari è una strutturazione che non è adeguata al
tuo problema, però magari si :)</div>
<div><br>
</div>
<div>Ciao</div>
<div> Marco</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">2015-07-16 15:03 GMT+02:00 Gaetano
Giunta <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:giunta.gaetano@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:giunta.gaetano@gmail.com">giunta.gaetano@gmail.com</a></a>></span>:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">Per quel che riguarda eZ ti posso
solo indirizzare a:<br>
<br>
<a moz-do-not-send="true"
href="http://ezsystems.github.io/slides/"
rel="noreferrer" target="_blank">http://ezsystems.github.io/slides/</a><br>
<a moz-do-not-send="true" href="http://doc.ez.no"
rel="noreferrer" target="_blank">http://doc.ez.no</a><span><br>
<br>
Simone Magnaschi wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
Grazie Gaetano,<br>
l'approccio sembra molto interessante e
sembrerebbe fare al caso mio dato che parte
dei dati li abbiamo su servizi esterni (quindi
api e no db).<br>
Ho provato a dare un'occhiata veloce a <a
moz-do-not-send="true"
href="https://github.com/ezsystems/ezpublish-kernel/"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/ezsystems/ezpublish-kernel/">https://github.com/ezsystems/ezpublish-kernel/</a></a>
ma come immaginavo a una code base abb.
complessa.<br>
</blockquote>
<br>
</span>
solo un filino... :-D<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><span>
Per caso hai articoli o risorse per poter
approfondire quel tipo di approccio?<br>
<br>
Grazie ancora<br>
S.<br>
<br>
</span>
[...]<br>
</blockquote>
<br>
ciao</div>
</div>
<div>
<div><br>
<span class="">
_______________________________________________<br>
Milano mailing list<br>
<a moz-do-not-send="true"
href="mailto:Milano@ml.grusp.org"
target="_blank">Milano@ml.grusp.org</a><br>
<a moz-do-not-send="true"
href="http://ml.grusp.org/listinfo.cgi/milano-grusp.org"
rel="noreferrer" target="_blank">http://ml.grusp.org/listinfo.cgi/milano-grusp.org</a><br>
</span></div>
</div>
</blockquote>
</div>
<span class="HOEnZb"><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Ciao<br>
Marco<br>
--<br>
web: <a moz-do-not-send="true"
href="http://mavimo.org" target="_blank">http://mavimo.org</a><br>
mob: <a moz-do-not-send="true"
href="tel:%2B39%20393%209249923"
value="+393939249923" target="_blank">+39 393
9249923</a><br>
skype: marco.moscaritolo<br>
twitter: @mavimo</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Milano mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Milano@ml.grusp.org">Milano@ml.grusp.org</a>
<a class="moz-txt-link-freetext" href="http://ml.grusp.org/listinfo.cgi/milano-grusp.org">http://ml.grusp.org/listinfo.cgi/milano-grusp.org</a>
</pre>
</blockquote>
<br>
</body>
</html>