[Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Paolini]

Il giorno 1 ottobre 2015 13:32, Giovanni Porcari <
giovanni.porcari a softwell.it> ha scritto:

>
> > Il giorno 30 set 2015, alle ore 22:24, Marco Paolini <
> markopaolini a gmail.com> ha scritto:
> >
> > Se product e Payment fossero in due microservice differenti, dovremmo
> creare una transazione distrubita (XA) e gestire il fallimento a livello
> applicativo. Molto + codice, molto + difficile da testare.
> >
> >
>
> Curiosità da parte di qualcuno con tanta 'pratica e poca teoria alle
> spalle:
>
> In una situazione come quella che proponi il mio primo approccio sarebbe
> quello
> di avere un unico servizio che mette in una coda un identificativo
> temporale univoco
> con le operazioni da compiere e successivamente uno o più servizi prendono
> l'evento
> e ciascuno per la sua parte compie le operazioni necessarie.
>
> Capisco che è un approccio 'naif' ma non consentirebbe appunto di
> segmentare un
> applicativo monolitico salvando le logica delle transazioni ?
>
> Se una transazione fallisce dovrebbe essere possibile effettuare una sorta
> di rollback
> dell'intera transazione proprio perchè esiste un luogo dove è presente in
> nuce
> l'intera transazione anche se non ancora attualizzata nelle scritture
> necessarie
> nei singoli servizi.
>
> Insomma un po' i WAL di postgres ma nell'ottica di servizi distribuiti.
>

Si, è così che si fa (credo) cioè con un repository centrale (etcd,
zookeper, postgres stesso) che si occupa di tener traccia delle transazioni
distribuite.

Io credo che questo approccio sia più complesso da implemetare rispetto a:
BEGIN; SELECT FOR UPDATE; COMMIT . Credo anche che quando il progetto
diventa molto grande, magari conviene implementarlo anche se è più
complesso. Non ho molta esperienza in proposito.

Ciao
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20151001/95e0551a/attachment.html>