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

[Marco Paolini]

2015-09-30 10:01 GMT+02:00 Marco Beri <marcoberi a gmail.com>:

> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
> riccardo.magliocchetti a gmail.com>:
>
>> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>>
>>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>>> che
>>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>>> sono i
>>> microservice python. Abbiamo copiato un po' da qua
>>> https://www.nginx.com/blog/introduction-to-microservices/
>>>
>>
>> link interessante grazie
>
>
> 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."*
>

Marco, hai centrato perfettamente il nodo della questione.

In una app monolitica puoi fare:

def purchase_product(product_id, payment_id):
  with transaction.atomic():
    product = Product.objects.select_for_update().get(pk=prod_id)
    if product.status != 'available':
      raise ProductNotAvaliable()
    product.status = 'purchased'
    product.save()
    Payment.objects.create(product=product, payment_id=payment_id)

sfruttando alla grande le funzionalità del db relazionale per sincronizzare
l'accesso ai dati e per garantire l'integrità e la consistenza.

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.

L'approccio che propongo, e sul quale sto sperimentando da un po', si basa
su un core monolitico django e *alcuni* microservice periferici che stanno
dietro ad un "frontend application tier" (scusate il nome) in nodejs che
permette l'isomorfismo di parte della app e con API graphql. Tutti questi
componenti girano in container docker. Ultimamente stiamo usando trhift per
la comunicazione interna tra questi "microservice". Stiamo scopiazzando un
po' da facebook ;)

In generale nella maggior parte dei progetti in cui lavoro alla fine non ci
saranno mai sopra più di una decina di sviluppatori, quindi l'architettura
monolitica se ben incapsulata va benissimo. I microservice a noi servono
per gestire un po' meglio la scalabilità e il ciclo di vita dei singoli
componenti e poer poterli scrivere in linguaggi diversi in alcuni casi.

Marco
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150930/87567104/attachment-0001.html>