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

[enrico franchi]

On Wed, Sep 30, 2015 at 9:01 AM, Marco Beri <marcoberi a gmail.com> wrote:

> Uno dei rovesci dell'architettura a microservices che trovo davvero duro
> da digerire è questo:
>
> *"Business transactions that update multiple business entities are fairly
> common. These kinds of transactions are trivial to implement in a
> monolithic application because there is a single database. In a
> microservices-based application, however, you need to update multiple
> databases owned by different services. Using distributed transactions is
> usually not an option, and not only because of the CAP theorem. They simply
> are not supported by many of today’s highly scalable NoSQL databases and
> messaging brokers."*
>
> La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario
> (ma ammetto di essere ignorante in questo approccio, per questo chiedo un
> parere qui):
>
> *"You end up having to use an eventual consistency based approach, which
> is more challenging for developers."*
>


A me questa faccenda non convince in modo eccessivo. Allora, e' normale
avere business transactions che coinvolgono piu' entita'? Ovviamente.
Capita di continuo.

La quale cosa puo' essere un problema anche semplicemente con una API rest
progettata in modo idiota (ma questo non vuole dire che bisogna evitare
Rest).

Prendiamo il caso piu' semplice: devo prendere soldi da un conto e mettere
soldi su un altro conto. Se la mia API e' qualcosa del tipo

PUT /account/<id>/amount/<new-amount>

per esempio, diventa gia' li molto livello fare la normalissima transazione
di cui parlavo. Bisogna scrivere parecchia sessione a mano per gestire la
cosa in modo opportuno (nb, PUT e' intesa idempotente, quindi devo dirgli
quale e' l'amount, non posso dirgli aggiungi o sottrai... oppure potrebbe
essere, se voglio aggiungere o sottrarre)

PUT /account/<id>/transaction/<tid>/add/<amount-to-add-or-subtract>

Per inciso, questo ha pure il vantaggio che si possono correlare le due
operazioni, il che rende tutto parecchio piu' semplice. Non ho voglia di
riconcepire gli esempi anche con POST, perche' temo che poi diventi troppo
confuso.

Ora, un'API vagamente piu' sensata potrebbe avere una faccia tipo

PUT /transaction/<tid>/<src-account>/<dst-account>/<amount>

A questo punto la transazione non va piu' gestita a livello HTTP e rimane
nel server ed e' molto piu' semplice.

Ora tutta questa conversazione ha piuttosto senso se stiamo assumendo di
avere i conti correnti in qualcosa che si comporta come un db univoco. Solo
che tipicamente i due conti correnti sono due mondi distinti. E infatti le
banche non fanno le cose a quel modo punto.

Comunque, il fatto chiaro e' che avere una API invece che l'altra rende le
cose (apparentemente) molto piu' facili. E ci indica anche che spezzare in
due microservice la gestione di sta roba ci mette punto a capo
(incidentalmente, alla fine dei conti dovremo parlare con due banche
diverse -- o dire ad una banca cosa deve fare con l'altra, che e' il motivo
per cui la prima API e' veramente broken... ma tant'e').


Comunque, mi aspettavo che sarebbe stato piu' interessante da leggere.
TL;DR, se spezzare una certa cosa in due microservizi porta un mondo di
dolore, e' possibile che quei due micro-servizi non siano la scelta giusta.
Esattamente come se spezzare la responsibilita' di un oggetto in due
oggetti apre a dolore e bachi probabilmente l'API corretta dovrebbe avere
un solo oggetto. Questo al di la del livello di dettaglio con cui guardiamo
le cose (livello intra-servizio, livello inter-servizio, livello
design/OOP).

Questo per me non e' uno svantaggio dei micro-servizi, e' semplicemente una
scelta architetturale sbagliata.



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