[pugMI] Dubbi su architettura / data mapper / repository ecc... HELP! :)
Gaetano Giunta
giunta.gaetano a gmail.com
Ven 17 Lug 2015 01:38:15 PDT
Simone Magnaschi wrote:
> Marco grazie, non so se calza con la mia situazione attuale ma mi sembra un ottimo spunto di riflessione.
> 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?
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.
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.
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).
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.
Rimarrebbero i vantaggi:
- api WS disponibile con zero sforzo
- separazione netta tra la tua 'facade' sui database legacy compositi e il codice front che consuma i ws
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...
> S.
>
> Il giorno 16 luglio 2015 16:58, Marco Vito Moscaritolo <mavimo a gmail.com <mailto:mavimo a gmail.com>> ha scritto:
>
> 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):
>
> 1) Definizione di una libreria contenente le entity
> 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
> 3) Creazione di un client che in base alle informazioni richieste chiede i dati al WS.
>
> Ad occhio sembra un pò tutto overkill, però:
>
> 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.
>
> 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 https://github.com/neomerx/json-api e
> https://github.com/neomerx/limoncello 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)
>
> 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:
>
> $myEntity = $myEntityRepository->getById(123, [
> 'my_entity.author',
> 'mia_entity.comments',
> ]);
>
> foreach ($myEntity->comments as $comment) {
> var_dump($comment->getTitle());
> }
>
> 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).
> 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.
>
> 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).
>
> Non credo matchi esattamente con il tuo problema, quindi magari è una strutturazione che non è adeguata al tuo problema, però magari si :)
>
> Ciao
> Marco
>
>
> 2015-07-16 15:03 GMT+02:00 Gaetano Giunta <giunta.gaetano a gmail.com <mailto:giunta.gaetano a gmail.com>>:
>
> Per quel che riguarda eZ ti posso solo indirizzare a:
>
> http://ezsystems.github.io/slides/
> http://doc.ez.no
>
> Simone Magnaschi wrote:
>
> Grazie Gaetano,
> 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).
> Ho provato a dare un'occhiata veloce a https://github.com/ezsystems/ezpublish-kernel/ ma come immaginavo a una code base abb. complessa.
>
>
> solo un filino... :-D
>
> Per caso hai articoli o risorse per poter approfondire quel tipo di approccio?
>
> Grazie ancora
> S.
>
> [...]
>
>
> ciao
>
> _______________________________________________
> Milano mailing list
> Milano a ml.grusp.org <mailto:Milano a ml.grusp.org>
> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
>
>
>
>
> --
> Ciao
> Marco
> --
> web: http://mavimo.org
> mob: +39 393 9249923 <tel:%2B39%20393%209249923>
> skype: marco.moscaritolo
> twitter: @mavimo
>
>
>
>
> _______________________________________________
> Milano mailing list
> Milano a ml.grusp.org
> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20150717/fbe7e3a9/attachment-0001.htm>
Maggiori informazioni sulla lista
Milano