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

[Alessandro Re]

2015-10-03 12:56 GMT+01:00 enrico franchi :
>
> 2015-10-02 18:10 GMT+01:00 m :
>>
>> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
>> che ha un significato preciso in matematica, sia stata presa e usata a
>> sproposito ?
>
>
> No. Non sei l'unico. Ad essere sinceri anche nella community il termine non
> piace a molti e cercano alternative.


E questo, ragazzi, è il motivo per cui si dice che la matematica, un
giorno, potrebbe esservi utile :D

Grazie Enrico per questo bel ripasso di algebra e topologia.

Comunque, sebbene il tuo salumiere deve essere piuttosto skillato (e,
d'altronde, non mi sarei aspettato altrimenti), al mio salumiere gli
isomorfismi topologici li spiego dicendo che un toro e una tazza hanno
sostanzialmente la stessa forma... Lui mi guarda male, però. E ti
dirò, il salumiere mi guarda anche peggio quando gli dico che un toro
è una ciambella (a quanto pare non c'é mercato per bistecche di
ciambella).

Per rispondere alla domanda originale: onestamente non credo
di aver mai sentito la parola "isomorfismo" usata fuori dal contesto
matematico (prima di leggere questo thread)... Sarà perché non uso
javascript (e ne sono felicissimo)? :D

Ciauz
~Ale
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2015-10-04 14:22 GMT+02:00 Alessandro Re :

> Comunque, sebbene il tuo salumiere deve essere piuttosto skillato (e,
> d'altronde, non mi sarei aspettato altrimenti), al mio salumiere gli
> isomorfismi topologici li spiego dicendo che un toro e una tazza hanno
> sostanzialmente la stessa forma... Lui mi guarda male, però. E ti
> dirò, il salumiere mi guarda anche peggio quando gli dico che un toro
> è una ciambella (a quanto pare non c'é mercato per bistecche di
> ciambella).
>

Con una certa approssimazione però. Io direi ciambella con più buchi :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-10-03 16:33 GMT+02:00 Luca Bacchi :

> Questi concetti, che mi pare siano alla base del moderno web design sono
> spiegati molto meglio di quanto io sia in grado di fare in questo articolo
> che vi condivido:


Muchas gracias Luca, molto interessante

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[m]

* Marco Paolini (markopaol...@gmail.com) [151002 19:23]:


si dai tranquillo se scoppi per così poco, immagina se ti dico che in python
questa è si chiama funzione:

def ciao():
  db.save('hey')



si, grazie, lo sapevo, molto cortese comunque

--
 .*.finelli
 /V\
(/ \) --
(   )   Linux: Friends dont let friends use Piccolosoffice
^^-^^ --

What to do in case of an alien attack:

1)   Hide beneath the seat of your plane and look away.
2)   Avoid eye contact.
3) If there are no eyes, avoid all contact.

-- The Firesign Theatre, _Everything you know is Wrong_
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Luca Bacchi]

Ciao Carlos. È più o meno quello che intendevo.

Questi concetti, che mi pare siano alla base del moderno web design sono
spiegati molto meglio di quanto io sia in grado di fare in questo articolo
che vi condivido:

http://rauchg.com/2014/7-principles-of-rich-web-applications/

Ciao
Il 03/ott/2015 04:28 PM, "Carlos Catucci"  ha
scritto:

>
> 2015-10-03 16:22 GMT+02:00 Luca Bacchi :
>
>> Proprio nella prima chiamata può avere senso inviare la pagina completa,
>> e non solo un container vuoto da dover poi riempire con successive chiamate
>> Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
>> caricamento dell'applicazione.
>
>
> E allungando i tempi di caricamento. Io da come le vedo caricherei la
> parte visibile all'avvio completa, e a document ready inizierei a prendere
> via ajax i contenuti delle "scatole" sottostanti. Questo almeno se per SPA
> si intende quelle a scrolling verticael. In caso ocntrario ovvio che carico
> tutto, le ajax calls dovrebbero esserci in risposta a eventi particolari
> (es, pressione di un tasto oppure apertura di un menu).
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-02 17:29 GMT+01:00 Marco Paolini :

>
>
> Il giorno 2 ottobre 2015 12:42, enrico franchi 
> ha scritto:
>
>>
>> 2015-10-02 7:43 GMT+01:00 Marco Paolini :
>>
>>> Avere nodejs nel proprio stack tecnlologico è quasi una necessità oggi:
>>> hai gratis isomorfismo e rendering server-side di applicazioni single-page.
>>
>>
>> Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
>> importante per determinate scelte di carriera, ma di qui a chiamarla una
>> "necessita'" ne passa.
>>
>
> Per curiosità, come fai il rendering lato server di una app single page
> angular/ember/react?
>

1. potrei non avere una spa (ancora una volta, e' una moda, non e' un
obbligo; ci sono casi in cui funziona bene, casi in cui funziona male);
come detto prima, non e' una tecnologia che trovo particolarmente simpatica
e che trovo spesso abusata.
2. potrei non avere particolare interesse a fare rendering lato server
(dipende caso per caso quando vinci e quando perdi: ho parecchi use-case
completamente diversi da tenere d'occhio... non trovo una soluzione che va
bene per tutto)
3. per il mio use-case piu' massiccio sfortunatamente sono sotto una pila
di nda. ma diciamo che a naso non mi sembra una soluzione


>
> Secondo me se sviluppi app web è prorio una necessità, perchè nodejs ti
> offre una serie ti tool interessanti per sviluppare app web.
>

Secondo me se sviluppi applicazioni web *non* e' una necessita' (in fatti
non tutti fanno cosi'); magari se sviluppi spa. E anche li, le spa ci sono
da un po' di anni, ma sta cosa del ssr e' relativamente recente. Vedrai che
la tecnologia evolvera' ancora. Ogni 6 mesi esce ualcosa di radicalmente
nuovo/


>
> Lato client è indispensabile, visto che su nodejs si appoggia *tutta* la
> toolchain moderna di un programmatore frontend: grunt/gulp, bower, karma,
> npm...
>

Anche C e' indispensabile perche' ci si basa tutto... ma questo non vuole
dire che devi lavorare in C sebbene dei componenti che ti servono siano
scritti in C.

E poi... programmatore frontend a chi?


> Lato server è estremamente comodo usarlo a fianco (o davanti) l'
> application tier python per fare appunto rendering server-side e sfruttare
> isomorfismo per condividere codice tra client e server.
>

Come dicevo, non c'e' molta speranza che i tentativi di introdurre node.js
in mia presenza non incontrino strenua resistenza.

Poi quando mi mostreranno che non c'e' alternativa ed effettivamente la
cosa non e' un delirio da gestire ne parleremo.

--
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-10-03 14:49 GMT+02:00 Marco Beri :

> Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...


Cavolo ora tutti sanno che sono il tuo salumiere, e cha cazz. ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-10-03 14:53 GMT+02:00 Giovanni Porcari :

> Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)


+1

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

On Oct 3, 2015 1:56 PM, "enrico franchi"  wrote:
>
> Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un
isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici
*e* che sia invertibile.

Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...

Ciao.
Marco.
P.s. Avrei pure preso 26 all'esame di algebra... Non mi ricordo più una
mazza...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-10-03 16:22 GMT+02:00 Luca Bacchi :

> Proprio nella prima chiamata può avere senso inviare la pagina completa, e
> non solo un container vuoto da dover poi riempire con successive chiamate
> Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
> caricamento dell'applicazione.


E allungando i tempi di caricamento. Io da come le vedo caricherei la parte
visibile all'avvio completa, e a document ready inizierei a prendere via
ajax i contenuti delle "scatole" sottostanti. Questo almeno se per SPA si
intende quelle a scrolling verticael. In caso ocntrario ovvio che carico
tutto, le ajax calls dovrebbero esserci in risposta a eventi particolari
(es, pressione di un tasto oppure apertura di un menu).

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-02 18:10 GMT+01:00 m :

> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
> che ha un significato preciso in matematica, sia stata presa e usata a
> sproposito ?
>

No. Non sei l'unico. Ad essere sinceri anche nella community il termine non
piace a molti e cercano alternative.
Tra l'altro... si, il termine e' mal scelto; ma mi sta facendo divertire un
mondo... tipo ho acchiappato il post di Rauschmeyer sull'argomento, in cui
tenta di spiegare che si, isomorfismo e' un buon termine per affinita' con
"il concetto topologico di ismorfismo". A questo punto spara la definizione
di isomorfismo in topologia... ed e' sbagliata. Di brutto: tipo sembra
ignorare il punto chiave di essere un'isomorfismo in topologia (altrimenti
detto omeomorfismo), che e' un concetto in un certo senso molto piu' forte
-- dal concetto di isomorfismo in algebra.

Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un
isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici
*e* che sia invertibile. Ovviamente, parlare di Javascript *isomorfico* e'
strano: di solito dici che *due* (o piu' cose) sono isomorfe o che *un*
ente (che appunto e' una funzione) e' un'isomorfismo. "Isomorphic
Javascript" non ha particolarmente senso: se hai un solo elemento nel
discorso, grazie tante ... A e' isomorfo ad A. Ma comunque... l'altro pezzo
interessante e' che la mappa e' invertibile. Questo lascia pensare ad un
rapporto biunivoco fra le due cose. Ora io non sono un esperto di sto
"ismorphic javascript", ma l'ultima volta che ho controllato e' vero che di
fatto convinci il server ad essere un client... ma non mi risulta che tutto
quello che fai sul server possa essere fatto sul client. Il che vuole dire,
che non c'e' nulla di "isomorfo": la parte chiave del concetto e'
l'invertibilita', che io non vedo.

Ah, solo per completezza, sudetto Rauschmeyer e' piu' specifico:
isomorfismo come isomorfismo topologico. Non gli basta quello algebrico,
apparentemente. Vuole proprio quello topologico. Ora, il problema e' che in
topologia gli isomorfismi sono funzioni topologicamente continue (su spazi
topologici). Ah, sempre invertibili, ovviamente. Il che quando mi dice
isomorphic javascript vorrei capire se intende che javascript e' uno spazio
topologico (il linguaggio [0]) o se intende dire che Javascript dovrebbe
essere una funzione continua fra non so cosa.

Comunque si... e' techno babble: qualcuno ha perso termini altisonanti e li
sta usando a sproposito. E' un po' come quando nei film parlando di
informatica mettono insieme termini a caso per simulare un discorso tecnico.



---
[0] ora studiare spazi topologici di linguaggi (come enti matematici) e'
piuttosto interessante; sfortunatamente un linguaggio che possa essere
gestito da un computer deve essere ricorsivamente enumerabile, il che lo
rende un ente relativamente semplice di cui non e' eccessivamente
interessante fare uno studio dal punto di vista topologico...








-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Luca Bacchi]

Le SPA tipicamente ricevono dal server degli oggetti JSON che devono
renderizzare lato client con un motore di templating JavaScript tipo quelli
che avete citato sopra.

Tipicamente la SPA non riceve dal server pagine HTML, tranne nella prima
chiamata, ovviamente.

Proprio nella prima chiamata può avere senso inviare la pagina completa, e
non solo un container vuoto da dover poi riempire con successive chiamate
Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
caricamento dell'applicazione.

È in questo passaggio che probabilmente si può riutilizzare lo stesso
codice di rendering, lato server e lato client.

Non credo che sia una cazzata o una moda. Credo che grossomodo le SPA
vadano più o meno fatte in questo modo.

Il giorno 3 ottobre 2015 15:24, Carlos Catucci 
ha scritto:

>
> 2015-10-03 14:53 GMT+02:00 Giovanni Porcari 
> :
>
>> Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)
>
>
> +1
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Giovanni Porcari]

> Il giorno 03 ott 2015, alle ore 13:56, enrico franchi 
>  ha scritto:
> 
> 
> 2015-10-02 18:10 GMT+01:00 m :
> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
> che ha un significato preciso in matematica, sia stata presa e usata a
> sproposito ?
> 
> No. Non sei l'unico. Ad essere sinceri anche nella community il termine non 
> piace a molti e cercano alternative.
> Tra l'altro... si, il termine e' mal scelto; ma mi sta facendo divertire un 
> mondo... tipo ho acchiappato il post di Rauschmeyer sull'argomento, in cui 
> tenta di spiegare che si, isomorfismo e' un buon termine per affinita' con 
> "il concetto topologico di ismorfismo". A questo punto spara la definizione 
> di isomorfismo in topologia... ed e' sbagliata. Di brutto: tipo sembra 
> ignorare il punto chiave di essere un'isomorfismo in topologia (altrimenti 
> detto omeomorfismo), che e' un concetto in un certo senso molto piu' forte -- 
> dal concetto di isomorfismo in algebra.
> 
> Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un 
> isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici *e* 
> che sia invertibile. Ovviamente, parlare di Javascript *isomorfico* e' 
> strano: di solito dici che *due* (o piu' cose) sono isomorfe o che *un* ente 
> (che appunto e' una funzione) e' un'isomorfismo. "Isomorphic Javascript" non 
> ha particolarmente senso: se hai un solo elemento nel discorso, grazie tante 
> ... A e' isomorfo ad A. Ma comunque... l'altro pezzo interessante e' che la 
> mappa e' invertibile. Questo lascia pensare ad un rapporto biunivoco fra le 
> due cose. Ora io non sono un esperto di sto "ismorphic javascript", ma 
> l'ultima volta che ho controllato e' vero che di fatto convinci il server ad 
> essere un client... ma non mi risulta che tutto quello che fai sul server 
> possa essere fatto sul client. Il che vuole dire, che non c'e' nulla di 
> "isomorfo": la parte chiave del concetto e' l'invertibilita', che io non vedo.
> 
> Ah, solo per completezza, sudetto Rauschmeyer e' piu' specifico: isomorfismo 
> come isomorfismo topologico. Non gli basta quello algebrico, apparentemente. 
> Vuole proprio quello topologico. Ora, il problema e' che in topologia gli 
> isomorfismi sono funzioni topologicamente continue (su spazi topologici). Ah, 
> sempre invertibili, ovviamente. Il che quando mi dice isomorphic javascript 
> vorrei capire se intende che javascript e' uno spazio topologico (il 
> linguaggio [0]) o se intende dire che Javascript dovrebbe essere una funzione 
> continua fra non so cosa.
> 
> Comunque si... e' techno babble: qualcuno ha perso termini altisonanti e li 
> sta usando a sproposito. E' un po' come quando nei film parlando di 
> informatica mettono insieme termini a caso per simulare un discorso tecnico.
> 
> 
> 
> ---
> [0] ora studiare spazi topologici di linguaggi (come enti matematici) e' 
> piuttosto interessante; sfortunatamente un linguaggio che possa essere 
> gestito da un computer deve essere ricorsivamente enumerabile, il che lo 
> rende un ente relativamente semplice di cui non e' eccessivamente 
> interessante fare uno studio dal punto di vista topologico... 
> 
> 
> 
> 


Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-03 13:49 GMT+01:00 Marco Beri :

> Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...
>
Ah... non fanno piu' i salumieri di una volta...


> P.s. Avrei pure preso 26 all'esame di algebra... Non mi ricordo più una
> mazza...
>

E' probabile che voi chiamaste algebra quella che normalmente si chiama
algebra lineare. Che e' una cosa abbastanza diversa (o meglio, quando si fa
*anche* algebra si trova la connessione)


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 1 ottobre 2015 17:25, Luca Bacchi  ha scritto:

> Scusatemi, ho sbagliato Thread... Incollo qui la mail che ho scritto anche
> dall'altra parte.
>
>
> Lavorando molto sul frontend di applicazioni web lavoro in JavaScript
> ormai da anni e sinceramente ne apprezzo alcune caratteristiche.
>
> [...]

> A conti fatti direi che non c'è poi tanto da sputarci sopra.
>
Sono d'accordo, Luca. Avere nodejs nel proprio stack tecnlologico è quasi
una necessità oggi: hai gratis isomorfismo e rendering server-side di
applicazioni single-page.

Poi nella parte più bassa dell'application tier, python secondo me è
meglio, ma questo soprattutto perchè lo conosco meglio.

Ciao
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-10-02 8:43 GMT+02:00 Marco Paolini :

> Sono d'accordo, Luca. Avere nodejs nel proprio stack tecnlologico è quasi
> una necessità oggi: hai gratis isomorfismo e rendering server-side di
> applicazioni single-page.
>

Forse ho capito male io ma mi e' sembrato Luca spezzasse una lancia a
favore di JS in se, e non di Node (che non so so neppure se usa).

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-02 7:43 GMT+01:00 Marco Paolini :

> Avere nodejs nel proprio stack tecnlologico è quasi una necessità oggi:
> hai gratis isomorfismo e rendering server-side di applicazioni single-page.


Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
importante per determinate scelte di carriera, ma di qui a chiamarla una
"necessita'" ne passa.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-10-02 12:42 GMT+02:00 enrico franchi :

> 2015-10-02 7:43 GMT+01:00 Marco Paolini :
>> Avere nodejs nel proprio stack tecnlologico è quasi una necessità oggi:
>> hai gratis isomorfismo e rendering server-side di applicazioni single-page.
>
> Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
> importante per determinate scelte di carriera, ma di qui a chiamarla una
> "necessita'" ne passa.

Intendi per le stesse "scelte di carriera" per cui Java for Dummies™ è
diventato fenomeno editoriale, giusto? =D

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-02 13:18 GMT+01:00 Carlo Miron :

> > Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
> > importante per determinate scelte di carriera, ma di qui a chiamarla una
> > "necessita'" ne passa.
>
> Intendi per le stesse "scelte di carriera" per cui Java for Dummies™ è
> diventato fenomeno editoriale, giusto? =D


Grosso modo.




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 2 ottobre 2015 12:42, enrico franchi 
ha scritto:

>
> 2015-10-02 7:43 GMT+01:00 Marco Paolini :
>
>> Avere nodejs nel proprio stack tecnlologico è quasi una necessità oggi:
>> hai gratis isomorfismo e rendering server-side di applicazioni single-page.
>
>
> Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
> importante per determinate scelte di carriera, ma di qui a chiamarla una
> "necessita'" ne passa.
>

Per curiosità, come fai il rendering lato server di una app single page
angular/ember/react?

Secondo me se sviluppi app web è prorio una necessità, perchè nodejs ti
offre una serie ti tool interessanti per sviluppare app web.

Lato client è indispensabile, visto che su nodejs si appoggia *tutta* la
toolchain moderna di un programmatore frontend: grunt/gulp, bower, karma,
npm...

Lato server è estremamente comodo usarlo a fianco (o davanti) l'
application tier python per fare appunto rendering server-side e sfruttare
isomorfismo per condividere codice tra client e server.

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 2 ottobre 2015 19:23, Marco Paolini  ha
scritto:

>
>
> Il giorno 2 ottobre 2015 19:10, m  ha scritto:
>
>> * Marco Paolini (markopaol...@gmail.com) [151002 18:29]:
>>
>>>
>>> Lato server è estremamente comodo usarlo a fianco (o davanti) l'
>>> application
>>> tier python per fare appunto rendering server-side e sfruttare
>>> isomorfismo per
>>> condividere codice tra client e server.
>>>
>>>
>> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
>> che ha un significato preciso in matematica, sia stata presa e usata a
>> sproposito ?
>>
>
http://dizionari.repubblica.it/Italiano/I/isomorfismo.php

anche in chimica mineraria ti fanno arrabbiare?

Perchè in questa lista c'è tanta maleducazione

Ciao a tutti
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

On Wed, Sep 30, 2015 at 9:01 AM, Marco Beri  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//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//transaction//add/

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

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-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-30 12:57 GMT+01:00 Carlos Catucci :

> Mah, guarda... bisogna vedere numeri (e caso per caso). Quando si parla di
>> "efficienza" si rischiano sempre di prendere delle cantonate.
>>
>
> Concordo ma in generale a me piace come logica. Sara' che vengo dai tempi
> in cui si cercava di risparmiare i bytes, in tutto (spazio disco, memoria
> gestita, traffico su porte seriali)
>
>

Ma e' proprio questo il punto: se hai metriche e non ti dicono che sei
inefficiente (e dove), vuole dire che non sei inefficiente.
Se *non* hai le metriche, vuole dire che il sistema funziona per caso, che
e' un problema piu' grosso.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Giovanni Porcari]

> Il giorno 30 set 2015, alle ore 22:24, Marco Paolini  
> 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.

Ciao

G
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2015-10-01 13:35 GMT+02:00 enrico franchi :

> 2015-09-30 19:03 GMT+01:00 Manlio Perillo :
>
>>
>> Usando tecnologie web sono costretto ad usare Javascript, ma:
>> 1) Il linguaggio non è object-oriented alla C++/Java (anche se sembra lo
>> vogliano fare diventare)
>> 2) La UI è dichiarativa di default, essendo in HTML
>> 3) Dato che Javascript lo usano tutti, ci sono tool come gopherjs
>>
>
> Manlio ma tiriamo a non capirci? Con una sintetica traduzione in francese,
> io ho detto che node.js mi fa vomitare a getto nel lavandino
> dell'appartamento di fronte.
>
> Al che tu dici, ah, ma e' portabile. E poi salta fuori che stavi parlando
> di web vs. desktop...
>

Sono abbastanza sicuro di averlo detto fin dall'inizio!


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-01 13:32 GMT+01:00 Manlio Perillo :

> Sono abbastanza sicuro di averlo detto fin dall'inizio!
>

Ah, ok. Si allora sono d'accordo. Preferisco web. Questo non vuole dire che
ci sia un buon motibo per usare node.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

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

>
> > Il giorno 30 set 2015, alle ore 22:24, Marco Paolini <
> markopaol...@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
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-30 19:03 GMT+01:00 Manlio Perillo :

>
> Usando tecnologie web sono costretto ad usare Javascript, ma:
> 1) Il linguaggio non è object-oriented alla C++/Java (anche se sembra lo
> vogliano fare diventare)
> 2) La UI è dichiarativa di default, essendo in HTML
> 3) Dato che Javascript lo usano tutti, ci sono tool come gopherjs
>

Manlio ma tiriamo a non capirci? Con una sintetica traduzione in francese,
io ho detto che node.js mi fa vomitare a getto nel lavandino
dell'appartamento di fronte.

Al che tu dici, ah, ma e' portabile. E poi salta fuori che stavi parlando
di web vs. desktop... che si, preferisco avere fra le palle Javascript che
avere fra le palle Qt. Ma questo non vuole dire che devo avere in mezzo
anche node.js ;)

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2015-10-01 15:00 GMT+02:00 enrico franchi :

>
> 2015-10-01 13:32 GMT+01:00 Manlio Perillo :
>
>> Sono abbastanza sicuro di averlo detto fin dall'inizio!
>>
>
> Ah, ok. Si allora sono d'accordo. Preferisco web. Questo non vuole dire
> che ci sia un buon motibo per usare node.
>
>
Io non avevo mai scritto di usare node.
Perchè mai dovrei usarlo?
Forse (e dico forse) l'unico campo per cui *potrei* usarlo è per i test di
codice Javascript.

Per il resto ho avuto la sfortuna di usare npm, ed è lento come se dovesse
compilare Android o LLVM...


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-10-01 15:21 GMT+01:00 Manlio Perillo :

> Io non avevo mai scritto di usare node.
> Perchè mai dovrei usarlo?
> Forse (e dico forse) l'unico campo per cui *potrei* usarlo è per i test di
> codice Javascript.
>

Marco Paolini>  Questo tema sposta l'ago della bilancia a favore di
javascript/nodejs come tecnologia per scrivere applicativi web.

Enrico Franchi> Io tutt'ora fatico a trovare qualcosa che bilanci l'enorme
svantaggio di dovere usare javascript. Il mondo di node.js mi sembra
veramente rotto su piu' livelli.

Manlio Perillo> La portabilità?



Il misunderstanding e' dovuto al fatto che si stava parlando di fatto di
node.js (e la mia menzione a Javascript e' relativa ad uno dei tanti
problemi che vedo in Node.Js -- ovvero, per me uno dei difetti piu' grossi
di node.js e' proprio dover scrivere Javascript), mentre tu non stavi
minimamente parlando di Node.js ma avevi solo estrapolato la parola
Javascript e hai calato tutto in contesto desktop vs. web che non era fra i
punti toccati.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2015-10-01 17:14 GMT+02:00 enrico franchi :

>
> 2015-10-01 15:21 GMT+01:00 Manlio Perillo :
>
>> Io non avevo mai scritto di usare node.
>> Perchè mai dovrei usarlo?
>> Forse (e dico forse) l'unico campo per cui *potrei* usarlo è per i test
>> di codice Javascript.
>>
>
> Marco Paolini>  Questo tema sposta l'ago della bilancia a favore di
> javascript/nodejs come tecnologia per scrivere applicativi web.
>
> Enrico Franchi> Io tutt'ora fatico a trovare qualcosa che bilanci
> l'enorme svantaggio di dovere usare javascript. Il mondo di node.js mi
> sembra veramente rotto su piu' livelli.
>
> Manlio Perillo> La portabilità?
>
>
>
> Il misunderstanding e' dovuto al fatto che si stava parlando di fatto di
> node.js (e la mia menzione a Javascript e' relativa ad uno dei tanti
> problemi che vedo in Node.Js -- ovvero, per me uno dei difetti piu' grossi
> di node.js e' proprio dover scrivere Javascript), mentre tu non stavi
> minimamente parlando di Node.js ma avevi solo estrapolato la parola
> Javascript e hai calato tutto in contesto desktop vs. web che non era fra i
> punti toccati.
>
>
Ok, grazie.
Non avevo proprio assorbito la parola node.js, dato che si parlava di
applicazioni web.
O meglio, io considero node.js una piattaforma per scrivere applicazioni
"tradizionali" usando JavaScript.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Luca Bacchi]

Scusatemi, ho sbagliato Thread... Incollo qui la mail che ho scritto anche
dall'altra parte.


Lavorando molto sul frontend di applicazioni web lavoro in JavaScript ormai
da anni e sinceramente ne apprezzo alcune caratteristiche.

Il suo modello ad oggetti va capito. Prototype-based è molto diverso da
Class-based di Python, questo lo sappiamo tutti. Piuttosto che cercare di
emulare l'ereditarietà classica (nel senso di Class-based, con o senza
librerie di terze parti) l'approccio corretto è capire come si progetta a
oggetti in JavaScript (module pattern, closures, ...). Ma anche questa è
una cosa ovvia che sanno tutti.

Supporta nativamente molti costrutti della programmazione funzionale:
closures, First order functions. E questo lo fa anche Python, ma in
JavaScript si è più portati a utilizzare queste cose, non chiedetemi il
perchè ma a me pare così: non ho forse mai scritto delle closure in Python;
in JavaScript praticamente non faccio altro.

Non che si debba necessariamente usare pattern della programmazione
funzionale, ma in generale mi ci trovo bene. Librerie come Underscore.js
o lodash le trovo meravigliose.

Il modello single-threaded... Non so che dire. Alla fine ci sono le
Promises, non c'è bisogno di impazzire, è un ambiente single-thread,
funziona in quel modo... Non fa poi così schifo.

Con ES6 ci sono un bel po' di novità mettono a disposizione parecchi
strumenti che il programmatore Python conosce bene: Promises, Iterator,
Generators, ...

La community? Non si può ignorare che al momento è la più vasta in
circolazione. E dovrebbe essere uno degli argomenti più forti, direi.

Anche i Big investono molto su JavaScript e anche questo non va ignorato.
Non conosco la storia, ma posso immaginare che se Nodejs è nato è
soprattutto perchè V8 di Google aveva evidentemente raggiunto livelli tali
di performance che potesse essere interessante utilizzarlo anche al di
fuori del browser.

Della possibilità di sviluppare client desktop ne avete già parlato (ne
parlai anche io una volta qui e fui un po' deriso, ma ora ho capito
perchè)... E della possibilità di sviluppare apprivazioni pseudo-native
utilizzando componenti come WebView di Android?

A conti fatti direi che non c'è poi tanto da sputarci sopra.

Il giorno 1 ottobre 2015 17:14, enrico franchi 
ha scritto:

>
> 2015-10-01 15:21 GMT+01:00 Manlio Perillo :
>
>> Io non avevo mai scritto di usare node.
>> Perchè mai dovrei usarlo?
>> Forse (e dico forse) l'unico campo per cui *potrei* usarlo è per i test
>> di codice Javascript.
>>
>
> Marco Paolini>  Questo tema sposta l'ago della bilancia a favore di
> javascript/nodejs come tecnologia per scrivere applicativi web.
>
> Enrico Franchi> Io tutt'ora fatico a trovare qualcosa che bilanci
> l'enorme svantaggio di dovere usare javascript. Il mondo di node.js mi
> sembra veramente rotto su piu' livelli.
>
> Manlio Perillo> La portabilità?
>
>
>
> Il misunderstanding e' dovuto al fatto che si stava parlando di fatto di
> node.js (e la mia menzione a Javascript e' relativa ad uno dei tanti
> problemi che vedo in Node.Js -- ovvero, per me uno dei difetti piu' grossi
> di node.js e' proprio dover scrivere Javascript), mentre tu non stavi
> minimamente parlando di Node.js ma avevi solo estrapolato la parola
> Javascript e hai calato tutto in contesto desktop vs. web che non era fra i
> punti toccati.
>
>
> --
> .
> ..: -enrico-
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Manlio Perillo]

2015-09-30 2:10 GMT+02:00 enrico franchi :

>
> 2015-09-29 18:43 GMT+01:00 Manlio Perillo :
>
>> La portabilità?
>>
>
> Cosa intendi con "portabilita'"? Il senso "tradizionale" chiaramente non
> si applica...
>
>
Diciamo che vorrei essere in grado di sviluppare una GUI per una mia
applicazione (magari in Go) senza
complicarmi la vita.
Dopo averci riflettuto, stavo pensando di usare questo per disperazione:
https://developer.chrome.com/extensions/nativeMessaging
usando Go per il backend e gopherjs per il frontend.

L'alternativa è usare Qt,  che si appoggia ad ANGLE (come chrome), ma che
comporta un minimo di sbattimento per
installare le librerie necessarie se non addirittura compilarsi tutto.

Da notare però che go-qml sono mesi che non viene aggiornato.
Secondo questa pagina:
https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK+
i bindings per le GTK sono messi peggio.

Il fatto stesso che per potermi interfacciare ad una libreria "completa"
per la GUI sia così "incasinato", a meno di non
utilizzare lo stesso linguaggio in cui la libreria/framework è stato
sviluppato, significa che c'è qualcosa di profondamente
sbagliato.
Le GUI moderne usano un linguaggio ad oggetti come C++ o Java, e richiedono
il subclassing per poterle utilizzare.
Come fai in Go? Per fortuna le Qt hanno QML e le GTK sono scritte in C...

Usando tecnologie web sono costretto ad usare Javascript, ma:
1) Il linguaggio non è object-oriented alla C++/Java (anche se sembra lo
vogliano fare diventare)
2) La UI è dichiarativa di default, essendo in HTML
3) Dato che Javascript lo usano tutti, ci sono tool come gopherjs


Ciao  Manlio

Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Nicola Larosa]

Manlio Perillo wrote:
> usando Go per il backend e gopherjs per il frontend.

Una web framework interessante scritto in Go che usa GopherJS è Seven5
. L'ho usato per una semplice admin UI, non è
male. Ho incontrato l'autore, Ian Smith, a luglio alla GopherCon di
Denver, è simpatico e disponibile.

Tieni conto che la community in pratica sono io (o lo ero). Se lo usi
anche tu, saremo in due. :-)

-- 
Nicola 'tekNico' Larosa 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-30 2:08 GMT+02:00 enrico franchi :

> Oh, non abbiamo "alternative". Personalmente non mi sono trovato una
> meraviglia con suddetti tool (linguaggio X -> Javascript). Nel senso che il
> linguaggio X in generale mi piace piu' di Javascript, ma comunque alla fine
> dei conti c'e'
>
[...]

Come temevo, Anche a me non piace il fatto di usare accrocchi. Io scrivo
Python poi trasforma in JS e io non so a che livello cercare il bug. Che
probabilmente ho introdotto io ma perche'lelogiche sono differenti, e
quindi una cosa sensaa in un linguaggio puo' iventare un buco nero se
tradotto, diciamo cosi', "alla lettera".

Il fatto che uno standard "a livello Javascript" si diffonda non e'
> probabilissimo. Potrebbe passare da una larghissima adozione di suddetti
> linguaggi (che a quel punto vengono a loro volta integrati)... ma
> sinceramente non mi sembra eccessivamente probabile. Bisogna mettere
> d'accordo gente come MS e Google. Bisogna capire come e se offrire
> interoperabilita' fra le due tecnologie... mi sembra complicato.
>

Io penso che solo una sorta di plugin dei browser potrebbe permettere di
utilizzare un linguaggio differente. Ma a parte la difficolta' (o devo dire
la possibilita' concreta?) di realizzare un plugin in grado di essere un
motore alternativo, chi vuole fruire della pagina deve avee il plugin
installato. Chi va sulla pagina e non e' un geek se vede che deve
installare qualcosa di strano scappa.

Ilpunto e' che anche JS non e' realmente un standard, a volte magari
qualche side effect tra un browser e l'altro si incontra  (meno di un tempo
pero')

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
riccardo.magliocche...@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."*

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron  wrote:

> On Wed, Sep 30, 2015 at 10:01 AM, Marco Beri  wrote:
>
> > 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."
>
> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
> le complicazioni del caso.



*"The main disadvantage to this algorithm is that it cannot recover in the
event the network is segmented in any manner. The original 3PC algorithm
assumes a fail-stop model, *
*where processes fail by crashing and crashes can be accurately detected,
and does not work with network partitions or asynchronous communication:*

Brrr...


> Probabilmente è vero che l'architettura a
> microservizi è da adottare quando ulteriori evoluzioni o scale up di
> software monolitico diventano troppo
> complesse/costose/rischiose/wathever.
>

Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura
che hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-30 2:40 GMT+02:00 enrico franchi :

> E, sfortunatamente, sara' colpa di troppe fatte male, ma tendo ad odiare
> le single page apps.
>

Potresti illustrare le cose fatte male nelle Single Page Apps? Io le trovo
comode, almeno intendo quelle dove la parte dinamica della pagna cambia
tramite callback REST ajax, senza dover ricaricaricare (inutilmente?) anche
parti gia' caricate nella pagina precedente. Sopratutto se hai una
connessione non brillantissima (problema che ha ancora una parte davvero
grande della popolazione mondiale sebbene chi lavori nel settore sia
abituato a velocita' almeno decenti).

Se invece intendi la moda di avere la pagina enorme che scrolla in
verticale devo dire che la trovo poco fruibile su computer. Capisco che su
device mobile/touch possano avere il loro perche', ma su PC no. E visto che
si puo' sapere con cosa fai la richiesta (OS, browser e relative versioni)
fare dei CSS adattativi non mi sembra impossibile.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-30 1:03 GMT+02:00 Giovanni Porcari :

> Abbastanza curioso come procedimento e in questo caso il server si fa
> carico di una parte di lavoro che sarebbe fattibile dal client con il
> vantaggio di distribuire questo lavoro sulle risorse di elaborazione dei
> client invece che affidare la renderizzazione al server.


Infatti il motivo per cui ancora non ho approcciato node e' questo. la
tentazione di usarlo per fare del multi-process diciamo, cioe' per quelle
cose che Python non fa o fa con fatica, la vrei avuta. Lo so posso usare
Go, o altri linguaggi che lo fanno bene, ma JS e' un linguggio (un male?)
conosciuto, ho meno rischi di scrivere cazzate per poca conoscenza del
linguaggio (quella di scriverle per miei fault e' una cosa differente).
Eppure non riesco a decidermi a mettere js sul server (tranne che come
dipnedenza di qualcosa appunto, come dice Riko).

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

On Wed, Sep 30, 2015 at 10:01 AM, Marco Beri  wrote:

> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti
> :
>> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>> [...]
>>> 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."

Già, è un bel casino. Dato che non sempre la consistenza eventuale è
un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
le complicazioni del caso. Probabilmente è vero che l'architettura a
microservizi è da adottare quando ulteriori evoluzioni o scale up di
software monolitico diventano troppo
complesse/costose/rischiose/wathever.

㎝

[¹]: 

PS: @MarcoP non mi hai convinto (ma probabilmente è impossibile, temo
di essere assolutamente refrattario ;) che JS lato server sia una
buona idea, sorry :P

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

2015-09-30 10:01 GMT+02:00 Marco Beri :

> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
> riccardo.magliocche...@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
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[m]

* Marco De Paoli (depao...@gmail.com) [150930 12:02]:


segnalo questa intervista all'inventore del "CAP theorem", Eric Brewer



Brewer fece la congettura, il teorema è di Gilbert e Lynch (quindi IMHO,
la parte faticosa l'hanno fatta loro, non Brewer)

--
 .*.finelli
 /V\
(/ \) --
(   )   Linux: Friends dont let friends use Piccolosoffice
^^-^^ --

Politicians speak for their parties, and parties never are, never have
been, and never will be wrong.
-- Walter Dwight
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

On 30 September 2015 at 12:10, Carlo Miron  wrote:

> Beh, è noto che gli ingegneri Amazon sono tutti incapaci. Senza eccezioni.


E' una mia impressione o abbiamo qualcuno in llista che e' parte di cotanta
schiera? ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-30 7:56 GMT+01:00 Carlos Catucci :

> Ilpunto e' che anche JS non e' realmente un standard, a volte magari
> qualche side effect tra un browser e l'altro si incontra  (meno di un tempo
> pero')


Lo standard c'e'. Tutto sommato l'effort di seguirlo c'e'. Chi piu'
velocemente chi meno... ma c'e'.

Io non direi che Javascript non e' uno standard. Per dire, magari non e'
ovvio se non ci si ha fatto sopra roba... ma dovremmo dire che anche Unix
(o SuS o POSIX che dir si voglia) non e' uno standard perche' qualche side
effect qui e li si trova (per esempio Linux alcune cose le implementa fuori
standard e immagino anche la maggior parte degli altri OS).

E Python non e' cross platform. Anche li, piu' di qualche glitch anche solo
fra Linux e Windows.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-09-30 10:34 GMT+02:00 Marco Beri :

> On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron  wrote:
>> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
>> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
>> le complicazioni del caso.
>
> "The main disadvantage to this algorithm is that it cannot recover in the
> event the network is segmented in any manner. The original 3PC algorithm
> assumes a fail-stop model,
> where processes fail by crashing and crashes can be accurately detected, and
> does not work with network partitions or asynchronous communication:
>
> Brrr...

Riporto un dialogo immaginario tra me e un personaggio fittizio che
chiamerò Pelatone™ per proteggerne l'identità.

me
non c'è soluzione, al problema del partitioning
ma nemmeno con nessuna replica master-master relazionale
quindi è un problema comune

Pelatone
certo
ma tu useresti un db replicato in una applicazione finanziaria per esempio?

me
se lo devo scalare sui c100k non vedo grosse alternative

Pelatone
ok
100.000 connessioni al secondo in una app finanziaria... uhm...
solo la borsa mi sa
però in quel caso lì io devo essere sicuro delle transazioni...
come faranno?

me
evitano accuratamente che il sistema si partizioni :D

Pelatone
:D :D
bella roba... allora è come dicevo io... non si usano
i microservizi
in una app finanziaria

me
ripeto, il problema del partitioning non è insito nei microservizi
ce l'hai anche nello sharding
solo la replica master/slave ne è immune
ma presenta forti limiti di scalabilità, infatti
poi non è vero che il fail-stop model è sempre la soluzione migliore
per esempio la borsa. se la cina si isola, il sistema borsa crolla?
no, si formano due isole indipendenti; il mercato va avanti da una
parte senza la cina, dall'altra solo con la cina
e poi qualche povero deficente riconcilia il casino ammano :-/
hai indubbiamente perso consistenza. ma è la migliore quantità di
consistenza che puoi ottenere in un sistema distribuito peer
e non c'è nessun "non me lo posso permettere" che tenga, punto.

>> Probabilmente è vero che l'architettura a
>> microservizi è da adottare quando ulteriori evoluzioni o scale up di
>> software monolitico diventano troppo
>> complesse/costose/rischiose/wathever.
>
> Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che
> hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)

non è sempre vero. se hai solo problemi evolutivi, succederà che il
costo evolutivo diventerà insopportabile ed il sistema stagnerà finché
qualcuno non propone una alternativa più economica. se invece devi
anche scalare (per esempio, per adattare il tuo sistema nazionale ad
un nuovo mercato), allora se il costo complessivo di riscrittura è
inferiore a quello evolutivo, riscrivere conviene
(ipotizzando che la riscrittura abbassi la complessità/migliori le
prestazioni/etc di ordini di grandezza)

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

Il 30 settembre 2015 11:22, Riccardo Magliocchetti
 ha scritto:


> http://martinfowler.com/bliki/MonolithFirst.html

Interessante.Grazie. Lo sto leggendo e mi sta dando ulteriori spunti,
ma anche tanti punti interrogativi.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-30 8:05 GMT+01:00 Carlos Catucci :

> Infatti il motivo per cui ancora non ho approcciato node e' questo. la
> tentazione di usarlo per fare del multi-process diciamo, cioe' per quelle
> cose che Python non fa o fa con fatica, la vrei avuta. Lo so posso usare
> Go, o altri linguaggi che lo fanno bene, ma JS e' un linguggio (un male?)
> conosciuto, ho meno rischi di scrivere cazzate per poca conoscenza del
> linguaggio (quella di scriverle per miei fault e' una cosa differente).
> Eppure non riesco a decidermi a mettere js sul server (tranne che come
> dipnedenza di qualcosa appunto, come dice Riko).


Tra l'altro non sono molto convinto che node faccia "bene" cose che Python
fa "male". Anzi, direi che essenzialmente le cose che Python fa davvero
male sono quelle che anche Node fa male.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

>>
>> Quale approccio pratico consigli?
>
marcob...@gmail.com tramite lists.python.it
> Bella domanda... :-)
>
2a domanda collegata: e se parti "green field"cioè in un progetto
nuovo, mettiamo il caso che si rivela essere
tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
successo)quale approccio pratico consigli?
Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
con quale/i criterio/i pratico/i?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Riccardo Magliocchetti]

Il 30/09/2015 11:15, Marco Ippolito ha scritto:


Quale approccio pratico consigli?



marcob...@gmail.com tramite lists.python.it

Bella domanda... :-)


2a domanda collegata: e se parti "green field"cioè in un progetto
nuovo, mettiamo il caso che si rivela essere
tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
successo)quale approccio pratico consigli?
Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
con quale/i criterio/i pratico/i?


http://martinfowler.com/bliki/MonolithFirst.html

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

>>
>> Probabilmente è vero che l'architettura a
>> microservizi è da adottare quando ulteriori evoluzioni o scale up di
>> software monolitico diventano troppo
>> complesse/costose/rischiose/wathever.
>
>
> Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che
> hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)
>
> Ciao.
> Marco.
>

Quindi meglio continuare ad ingro/a-ssare il mammuth?
Quale approccio pratico consigli?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Nicola Larosa]

Marco Ippolito wrote:
> Quindi meglio continuare ad ingro/a-ssare il mammuth?

RethinkDB sembra un NoSQL fatto bene:


Un query language decente, garanzie sulle scritture, MVCC come l'amato
elefante, client Python ufficiale... peccato non sia scritto in Go. ;-)

-- 
Nicola 'tekNico' Larosa 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-09-30 12:02 GMT+02:00 Marco De Paoli :

> sono spesso citati i casi di un ATM mi permette di prelevare soldi che non
> mi appartengono o Amazon che mi lascia ordinare beni che non esistono più...

Beh, è noto che gli ingegneri Amazon sono tutti incapaci. Senza eccezioni.

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2015-09-30 11:22 GMT+02:00 Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com>:

> Il 30/09/2015 11:15, Marco Ippolito ha scritto:
>
>>
 Quale approccio pratico consigli?

>>>
>>> marcob...@gmail.com tramite lists.python.it
>>
>>> Bella domanda... :-)
>>>
>>> 2a domanda collegata: e se parti "green field"cioè in un progetto
>> nuovo, mettiamo il caso che si rivela essere
>> tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
>> successo)quale approccio pratico consigli?
>> Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
>> con quale/i criterio/i pratico/i?
>>
>
> http://martinfowler.com/bliki/MonolithFirst.html



Apperò... Interessante anche questo.

Grazie.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2015-09-30 11:15 GMT+02:00 Marco Ippolito :

> >>
> >> Quale approccio pratico consigli?
> >
> marcob...@gmail.com tramite lists.python.it
> > Bella domanda... :-)
> >
> 2a domanda collegata: e se parti "green field"cioè in un progetto
> nuovo, mettiamo il caso che si rivela essere
> tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
> successo)quale approccio pratico consigli?
> Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
> con quale/i criterio/i pratico/i?
>

2ª bella domanda :-)


-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Beri]

2015-09-30 11:27 GMT+02:00 Carlo Miron :

> 2015-09-30 10:34 GMT+02:00 Pelatone immaginario:
>
> > Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura
> che
> > hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)
>
> non è sempre vero. se hai solo problemi evolutivi, succederà che il
> costo evolutivo diventerà insopportabile ed il sistema stagnerà finché
> qualcuno non propone una alternativa più economica. se invece devi
> anche scalare (per esempio, per adattare il tuo sistema nazionale ad
> un nuovo mercato), allora se il costo complessivo di riscrittura è
> inferiore a quello evolutivo, riscrivere conviene
> (ipotizzando che la riscrittura abbassi la complessità/migliori le
> prestazioni/etc di ordini di grandezza)
>

Yep. Intendevo dire che ti dicono spesso di no (cliente or manager).

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-30 11:33 GMT+02:00 enrico franchi :

>
> Mah, guarda... bisogna vedere numeri (e caso per caso). Quando si parla di
> "efficienza" si rischiano sempre di prendere delle cantonate.
>

Concordo ma in generale a me piace come logica. Sara' che vengo dai tempi
in cui si cercava di risparmiare i bytes, in tutto (spazio disco, memoria
gestita, traffico su porte seriali)


> Non parlo di quello. E non sono completamente certo che il paginone
> funzioni bene sul mobile; concordo che lo trovo in generale scomodo sul
> desktop. Ma lo trovo scomodo anche sul mobile.
>

In effetti puo' esserlo dipende anche dalle dimensioni del device. Sul mi
Galaxy Ace devo dire che trovo scomodo tutto ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Nicola Larosa]

> Nicola Larosa wrote:
>> peccato non sia scritto in Go. ;-)

Carlo Miron wrote:
> Stronzetto, è praticamente scritto in python...
> 
> * C++ 55.8%
> * Python 29.3%

Magra consolazione non avere la sindrome di Stoccolma più grossa da
queste parti...


> * JavaScript 5.0%
> * CoffeeScript 3.7%
> * CSS 2.9%
> * Ruby 0.9%
> * Other 2.4%

Dove l'hai presi 'sti numeri? Me ne risultano altri:



C++ 82.6%
Python 8.4%
Javascript 7.2%

e spiccioli di altro.

(Non potevano continuare a chiamarsi Ohloh, o perlomeno trovare un nome
meno generico? Continuo a dimenticarlo...)

-- 
Nicola 'tekNico' Larosa 

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-09-30 14:32 GMT+02:00 Nicola Larosa :

>> Nicola Larosa wrote:
>>> peccato non sia scritto in Go. ;-)
>
> Carlo Miron wrote:
>> Stronzetto, è praticamente scritto in python...
>>
>> * C++ 55.8%
>> * Python 29.3%
>
> Magra consolazione non avere la sindrome di Stoccolma più grossa da
> queste parti...

Chi/cosa mi avrebbe maltrattato, scusa?

> Dove l'hai presi 'sti numeri? Me ne risultano altri:
> 



㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-09-30 11:21 GMT+02:00 Nicola Larosa :

> RethinkDB sembra un NoSQL fatto bene:
> 
>
> Un query language decente, garanzie sulle scritture, MVCC come l'amato
> elefante, client Python ufficiale... peccato non sia scritto in Go. ;-)

Stronzetto, è praticamente scritto in python...

* C++ 55.8%
* Python 29.3%
* JavaScript 5.0%
* CoffeeScript 3.7%
* CSS 2.9%
* Ruby 0.9%
* Other 2.4%

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Riccardo Magliocchetti]

Il 28/09/2015 21:43, Marco Paolini ha scritto:



Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti
> ha
scritto:

Ciao Marco,

Il 24/09/2015 13:55, Marco Paolini ha scritto:

I pythonisti in tutto il mondo hanno subito sintonizzato le antenne e in
questo
momento c'è un po' di fermento sui porting in python di queste 
tecnologie.
Alcuni riferimenti:

- https://github.com/dittos/graphqllib libreria per gestione request 
graphql
server-side
- https://github.com/syrusakbary/graphene una specie di rest-framework
per graphql
- https://github.com/elastic-coders/py-graphqlparser il porting cython
del parser

Io ci sto giocando da poche settimane e mi sembra essere un passo in 
avanti
significativo nell'ambto dei web services


Perchè? Nel backend usi js o python?

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


La app node è utilissima per via dell'isomorfismo e perchè graphql è molto  +
avanti nel mondo js (per ora). Il backend python è forte per via della
standardizzazione django e dell'alta qualità delle 3rd party e perchè a me piace
di più.


grazie per gli spunti interessanti

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-29 11:34 GMT+01:00 Marco Paolini :

Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
> esempio il codice per la validazione di un modello può essere (in alcuni
> casi) condiviso tra client e server e quindi scrittto una sola volta.
> Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
> tecnologia per scrivere applicativi web.


Io tutt'ora fatico a trovare qualcosa che bilanci l'enorme svantaggio di
dovere usare javascript.

Il mondo di node.js mi sembra veramente rotto su piu' livelli. Intanto
vanno a velocita' forsennata nella creazione di tool (che ha piu' che
qualche implicazione nella creazione di servizi stabili). Un sacco di cose
che vengono fatte sono iniziate e poi abbandonate... sembra che abbiano
imparato l'arte del project manager dai peggio kiddies che facevano le
gemme per ruby.

L'idea stessa che sei asincrono, asincrono oppure asincrono e' sbagliata.
Ci sono task che sono semplicemente CPU bound. Le loro teorie su come
spezzettarli e' davvero roba che non dovrebbe essere esposta a livello
applicativo. E' perfino peggio di quello che succede con Python:
semplicemente dovere spostare a livello architetturale ogni problema di
codice e' bislacco. Con tutti i suoi difetti, perfino il modello di Java e'
piu' sensato.

Ma poi voglio dire... Javascript e' demenziale. Sono anni che cercano di
fare "alternative" a Javascript e qui si propone di muovere Javascript
anche dove non c'era... vedo qualcosa di contraddittorio. Saro' io.

No grazie... node.js mi sembra eleggere a paradigma tutti gli errori che
abbiamo visto nel mondo dello sviluppo javascript client side e in quello
Python e Ruby.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Riccardo Magliocchetti]

Il 29/09/2015 11:18, Marco Ippolito ha scritto:

Il 29 settembre 2015 08:41, Riccardo Magliocchetti
 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


C'è un libro molto interessante e fatto bene sui
microservices:"Building Microservices"-Sam Newman


Letto, piaciuto, fatta una lista degli altri libri consigliati dall'autore [1] 
:) Come panoramica sui microservices è molto utile, ti da una bella lista di 
cose che si complicano e a cui devi pensare se vuoi usare una architettura di 
questo genere.


[1] https://github.com/xrmx/buildingmicroservicesbook


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

>  ha scritto:

> Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
> esempio il codice per la validazione di un modello può essere (in alcuni
> casi) condiviso tra client e server e quindi scrittto una sola volta. Questo
> tema sposta l'ago della bilancia a favore di javascript/nodejs come
> tecnologia per scrivere applicativi web. Inoltre ultimamente sono usciti due
> "porting" ancora non maturi di react su android e ios che si chiamano
> reactnative, questo permette di condividere codice anche all'interno delle
> app mobile *native*.

Queste cose, come ho avuto modo di dire altre volte, sono state dette,
ben anni fa, in un corso Stanford (Coursera)  tenuto da Balaji S.
Srinivasan, entrato l'anno scorso, nell'orbita di in uno dei più
importanti Venture Capitalist (Horowitz "Software is eating the
world").

La mia personale opinione che mi sono fatto nello scontrarmi con i
problemi che man mano mi sorgono in quello che sto facendo, è che ogni
linguaggio ha i suoi pro/contro.Per cui alla fine, bisogna sfruttare i
pro, mitigandone i contro con i pro degli altri linguaggi
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

>> Il 29 settembre 2015 08:41, Riccardo Magliocchetti

> Letto, piaciuto, fatta una lista degli altri libri consigliati dall'autore
> [1] :) Come panoramica sui microservices è molto utile, ti da una bella
> lista di cose che si complicano e a cui devi pensare se vuoi usare una
> architettura di questo genere.
>
> [1] https://github.com/xrmx/buildingmicroservicesbook
>
Ottima lista. grazie!!!
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Ippolito]

Il 29 settembre 2015 08:41, Riccardo Magliocchetti
 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

C'è un libro molto interessante e fatto bene sui
microservices:"Building Microservices"-Sam Newman
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 29 settembre 2015 08:41, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> ha scritto:

> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>
>>
>>
>> Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti
>>  riccardo.magliocche...@gmail.com>> ha
>> scritto:
>>
>> Ciao Marco,
>>
>> Il 24/09/2015 13:55, Marco Paolini ha scritto:
>>
>> I pythonisti in tutto il mondo hanno subito sintonizzato le
>> antenne e in
>> questo
>> momento c'è un po' di fermento sui porting in python di queste
>> tecnologie.
>> Alcuni riferimenti:
>>
>> - https://github.com/dittos/graphqllib libreria per gestione
>> request graphql
>> server-side
>> - https://github.com/syrusakbary/graphene una specie di
>> rest-framework
>> per graphql
>> - https://github.com/elastic-coders/py-graphqlparser il porting
>> cython
>> del parser
>>
>> Io ci sto giocando da poche settimane e mi sembra essere un passo
>> in avanti
>> significativo nell'ambto dei web services
>>
>>
>> Perchè? Nel backend usi js o python?
>>
>> 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
>
> La app node è utilissima per via dell'isomorfismo e perchè graphql è
>> molto  +
>> avanti nel mondo js (per ora). Il backend python è forte per via della
>> standardizzazione django e dell'alta qualità delle 3rd party e perchè a
>> me piace
>> di più.
>>
>
> grazie per gli spunti interessanti


Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
esempio il codice per la validazione di un modello può essere (in alcuni
casi) condiviso tra client e server e quindi scrittto una sola volta.
Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
tecnologia per scrivere applicativi web. Inoltre ultimamente sono usciti
due "porting" ancora non maturi di react su android e ios che si chiamano
reactnative, questo permette di condividere codice anche all'interno delle
app mobile *native*.


>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-29 14:51 GMT+02:00 enrico franchi :

> Ma poi voglio dire... Javascript e' demenziale. Sono anni che cercano di
> fare "alternative" a Javascript e qui si propone di muovere Javascript
> anche dove non c'era... vedo qualcosa di contraddittorio. Saro' io.


Enrtico scusa ma quali alternative abbiamo a js (lato browser)? Ho visto
cento cosi ma non fanno altro che farti scrivere codice nel linguaggio X
che poi traducono in js.
Lo chiedo perche' mi piacerebbe avere alternative, anche se poi magari
dovessi scegliere js invece che l'alternativa in questione.
Al momento cerco di far far e le cose che mi servono a js con l'uso di
librerie. Adesso come adesso dovrei collaborare ad un progetto che usa Dojo
ad esempio, che non toccavo da versioni preistoriche ma mi sembra si sia
evoluto (se bene o male non posso ancora dirlo, sto guardandoci dentro,
quindi pareri illustri di chi ha avuto occasione sono graditi)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

2015-09-29 21:52 GMT+02:00 Carlo Miron :

> 2015-09-29 20:00 GMT+02:00 Marco Paolini :
>
>
> > [...] soprattutto perchè per fare
> > il rendering della pagina single page app lato server hai *comunque*
> bisogno
> > di interprete javascript lato server.
>
> Uhm? In che senso? Puoi elaborare?
>

Una single page app angular per esempio, è composta da una pagina statica
mezza vuota (index.html) che popola il DOM iniziale e carica la app angular
stessa. Appena la app angualr prende il controllo crea dinamicamente lato
client tutti gli elementi del DOM necessari per visualizare correttamtnte
la pagina. Da questo momento in poi, angular ha preso il controllo e
gestisce autonomamente tutto, caricando risorse dal server se ne ha bisogno.

Questa sequenza appena descritta non è ottimale perchè prevede il
caricamento di una pagina "stub" dal server che e poi il caricamento
dell'intera app partendo in pratica da zero.

Per ottimizzare, il server nodejs (con l'aiiuto di vari framework e
librerie) lancia lato server la app angular alla prima visita, in modo da
tornare al browser un html che equivale alla pagina manipolata da angular a
loading completato.

Ah poi node serve per tutta la toolchain dello sviluppo frontend: da
package management (bower) alla fase di build (grunt) fino al testing.

Spero di essere stato chiaro, non sono un espertone

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Giovanni Porcari]

> Il giorno 30 set 2015, alle ore 00:02, Marco Paolini  
> ha scritto:
> 
> 
> 
> 2015-09-29 21:52 GMT+02:00 Carlo Miron :
>> 2015-09-29 20:00 GMT+02:00 Marco Paolini :
>> 
>> 
>> > [...] soprattutto perchè per fare
>> > il rendering della pagina single page app lato server hai *comunque* 
>> > bisogno
>> > di interprete javascript lato server.
>> 
>> Uhm? In che senso? Puoi elaborare?
> 
> Una single page app angular per esempio, è composta da una pagina statica 
> mezza vuota (index.html) che popola il DOM iniziale e carica la app angular 
> stessa. Appena la app angualr prende il controllo crea dinamicamente lato 
> client tutti gli elementi del DOM necessari per visualizare correttamtnte la 
> pagina. Da questo momento in poi, angular ha preso il controllo e gestisce 
> autonomamente tutto, caricando risorse dal server se ne ha bisogno.
> 
> Questa sequenza appena descritta non è ottimale perchè prevede il caricamento 
> di una pagina "stub" dal server che e poi il caricamento dell'intera app 
> partendo in pratica da zero.
> 
> Per ottimizzare, il server nodejs (con l'aiiuto di vari framework e librerie) 
> lancia lato server la app angular alla prima visita, in modo da tornare al 
> browser un html che equivale alla pagina manipolata da angular a loading 
> completato.
> 
> Ah poi node serve per tutta la toolchain dello sviluppo frontend: da package 
> management (bower) alla fase di build (grunt) fino al testing.
> 
> Spero di essere stato chiaro, non sono un espertone
> 

Abbastanza curioso come procedimento e in questo caso il server si fa carico di 
una parte di lavoro che sarebbe fattibile dal client con il vantaggio di 
distribuire questo lavoro sulle risorse di elaborazione dei client invece che 
affidare la renderizzazione al server. 

Non ne comprendo il vantaggio.  Inoltre lato server a mio avviso linguaggi come 
python sono più 'adatti' e non ti costringono a fare tutto asincrono come con 
node.js. 

Di javascript ne usiamo tanto ma se posso evitarmelo almeno sul server lo 
ritengo una benedizione ;)


G___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-29 15:47 GMT+01:00 Carlos Catucci :

> Enrtico scusa ma quali alternative abbiamo a js (lato browser)? Ho visto
> cento cosi ma non fanno altro che farti scrivere codice nel linguaggio X
> che poi traducono in js.


Oh, non abbiamo "alternative". Personalmente non mi sono trovato una
meraviglia con suddetti tool (linguaggio X -> Javascript). Nel senso che il
linguaggio X in generale mi piace piu' di Javascript, ma comunque alla fine
dei conti c'e' sempre il problema che trapela qua e la, che devi chiamare
librerie scritte in Javascript (e anche li, a volte ci sono pezzi di API
che potrebbero non avere un eccesso di senso senza un wrapper), se devi
debuggare hai due layer, se il customer ha un problema lui sta eseguendo
Javascript, ma tu hai scritto X e devi mappare le due cose insieme.

Il fatto che uno standard "a livello Javascript" si diffonda non e'
probabilissimo. Potrebbe passare da una larghissima adozione di suddetti
linguaggi (che a quel punto vengono a loro volta integrati)... ma
sinceramente non mi sembra eccessivamente probabile. Bisogna mettere
d'accordo gente come MS e Google. Bisogna capire come e se offrire
interoperabilita' fra le due tecnologie... mi sembra complicato.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-29 18:43 GMT+01:00 Manlio Perillo :

> La portabilità?
>

Cosa intendi con "portabilita'"? Il senso "tradizionale" chiaramente non si
applica...


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-29 19:00 GMT+01:00 Marco Paolini :

> Quindi lo sviluppatore full-stack deve conoscere javascript. Viene
> naturale usare lo stesso linguaggio per l'intero stack, soprattutto perchè
> per fare il rendering della pagina single page app lato server hai
> *comunque* bisogno di interprete javascript lato server.
>

Si. Ma devono passare sul mio cadavere prima di mettere in produzione
node.js. Davvero.
Per ora non ho fatto eccessive storie per node.js in quanto dipendenza di
grunt, ma la cosa deve finire li.

Tra l'altro, io ho serissimi dubbi che questo approccio sia sempre
vincente. E' vero che guadagni il fatto di non spedire lo stub e hai un
loading piu' rapido della pagina. D'altra parte, appunto, hai spostato roba
lato server. Il che non e' un problema immenso (e' qualcosa che almeno a
livello parziale si vuole fare quasi sempre). Detto questo, non mi e'
davvero chiaro come scalare bene roba come Angular a livelli interessanti.
E, sfortunatamente, sara' colpa di troppe fatte male, ma tendo ad odiare le
single page apps.

Javascript è il primo linguaggio per popolarià su github.
>

Certo. Il secondo e' Java. Il quarto e' PHP. Quindi?

Tra l'altro la popolarita' di JS su Github si spiega piuttosto facilmente.
In primo luogo anche progetti non in Javascript potrebbero avere fette
considerevoli in Javascript. Questo da solo non basta, ma aiuta. In secondo
luogo e' una comunita' molto attiva (direi forsennata) che ogni due mesi
buoni butta fuori un nuovo aggeggio per ogni funzione o poco ci manca.



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-30 0:03 GMT+01:00 Giovanni Porcari :

> Abbastanza curioso come procedimento e in questo caso il server si fa
> carico di una parte di lavoro che sarebbe fattibile dal client con il
> vantaggio di distribuire questo lavoro sulle risorse di elaborazione dei
> client invece che affidare la renderizzazione al server.
>

Dipende molto dallo use-case, chiaramente, ma avere pezzi prefabbricati che
si possono servire aiuta, per lo meno, ad usare come si deve una CDN. Tra
l'altro, se hai un milione di richieste al secondo (ma anche 100K...) e
queste richieste sono "servimi una pagina", hai un problema (pure
relativamente banale se la pagina e' statica).

Se invece questa pagina per funzionare fa altre 10 chiamate http (che e'
pure poco, per certi versi)... beh, ecco che devi metterti in testa che
devi gestire 10M richieste al secondo. E ogni frontendista che salta su con
il suo widget che si fa le sue 2-3 chiamate diventa un costo insostenibile.




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 29 settembre 2015 19:43, Manlio Perillo 
ha scritto:

> 2015-09-29 14:51 GMT+02:00 enrico franchi :
>
>>
>> 2015-09-29 11:34 GMT+01:00 Marco Paolini :
>>
>> Figurati. Aggiungo che l'isomorfismo è estremamente comodo in quanto per
>>> esempio il codice per la validazione di un modello può essere (in alcuni
>>> casi) condiviso tra client e server e quindi scrittto una sola volta.
>>> Questo tema sposta l'ago della bilancia a favore di javascript/nodejs come
>>> tecnologia per scrivere applicativi web.
>>
>>
>> Io tutt'ora fatico a trovare qualcosa che bilanci l'enorme svantaggio di
>> dovere usare javascript.
>>
>
> > [...]
>
> La portabilità?
>
> Il web è l'unico campo dove esistono standard che sono seguiti da tutti i
> maggiori protagonisti.
> Lato desktop la situazione è pessima. Ignorando la GUI, anche voler usare
> OpenGL ES significa avere problemi dato che Windows
> non lo supporta.
>
> Una volta che hai un linguaggio che semplicemente *funziona*, sembra sia
> una conseguenza naturale che lo usano tutti.
>

Si esattamente Manlio. Lato browser javascript è il linguaggio e basta. I
vari coffescript o dart (che poi ovviemente compilano in js) sono delle
nicchie molto piccole e un po' in disuso. Javascript si usa anche per le
applicazioni "native" desktop (per esempio il client di slack credo sia in
javascript) anche se non so bene quanto sia diffuso li.

Quindi lo sviluppatore full-stack deve conoscere javascript. Viene naturale
usare lo stesso linguaggio per l'intero stack, soprattutto perchè per fare
il rendering della pagina single page app lato server hai *comunque*
bisogno di interprete javascript lato server.

Javascript è il primo linguaggio per popolarià su github. Anche python è
molto popolare! http://githut.info/

Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlo Miron]

2015-09-29 20:00 GMT+02:00 Marco Paolini :


> [...] soprattutto perchè per fare
> il rendering della pagina single page app lato server hai *comunque* bisogno
> di interprete javascript lato server.

Uhm? In che senso? Puoi elaborare?

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Marco Paolini]

Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> ha scritto:

> Ciao Marco,
>
> Il 24/09/2015 13:55, Marco Paolini ha scritto:
>
>> C'è fermento nell'ambito dei servizi web negli ultimi mesi.
>>
>> Stavolta è facebook a turbare le quiete acque del REST dove noi ci siamo
>> abbeverati così a lungo
>>
> >
>
>> Graphql https://facebook.github.io/graphql/ contine la specifica del
>> protocollo
>> e le direttive per implementarlo al meglio lato server
>>
>> c'è il parser scritto in c++ https://github.com/graphql/libgraphqlparser
>>
>> e l'implementazione di riferimento in javascript lato server
>> https://github.com/graphql/graphql-js
>>
>
> Per finire il puzzle manca relay che è quello che dovrebbe semplificare la
> gestione di come e quando prendere i dati da un server graphql:
> https://facebook.github.io/relay/

si in python è stato implementato in graphene listato qua sotto (ancora in
super alpha eh)


>
>
> Non ho ancora provato graphql /relay ma li guardo con favore. Sono molto
> grato a facebook per aver tirato fuori react.js che ci ha evitati l'odiosa
> monocultura angular.


Conosco abbastanza bene angular e lo ho molto appreazzato. Ora provando
react (ancora sono un newbie ma ho un buon maestro) devo dire che è più
intuitivo, però può essere anche solo una sensazione.


>
> I pythonisti in tutto il mondo hanno subito sintonizzato le antenne e in
>> questo
>> momento c'è un po' di fermento sui porting in python di queste tecnologie.
>> Alcuni riferimenti:
>>
>> - https://github.com/dittos/graphqllib libreria per gestione request
>> graphql
>> server-side
>> - https://github.com/syrusakbary/graphene una specie di rest-framework
>> per graphql
>> - https://github.com/elastic-coders/py-graphqlparser il porting cython
>> del parser
>>
>> Io ci sto giocando da poche settimane e mi sembra essere un passo in
>> avanti
>> significativo nell'ambto dei web services
>>
>
> Perchè? Nel backend usi js o python?


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/

La app node è utilissima per via dell'isomorfismo e perchè graphql è molto
 + avanti nel mondo js (per ora). Il backend python è forte per via della
standardizzazione django e dell'alta qualità delle 3rd party e perchè a me
piace di più.


>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[enrico franchi]

2015-09-26 18:26 GMT+01:00 Ivo Reano :

> >> Ciao Marco mi chiamo chiara,potrei chiederti una cosa?
>
>
>> > Se è qualcosa inerente a questo post, chiedi e basta, non ci sono
>> > autorizzazioni da chiedere...
>>
>>
>
>> >Byez
>> --
>> >Gollum1 - http://www.gollumone.it
>>
>
> E se fosse per invitarlo a "cena"? Avrebbe usato il giusto tono, leggero e
> non confidente.
>

Mi sembra che nel caso sarebbe rientrato nella casistica delineata da
Gollum fra le cose che interessano a Marco e fine della fiera. Ma mi sembra
veramente un esempio mal scelto.



> Secondo me non è "ancora" andata [OT]. E non era da richiamare! O forse sì?
>

Non e' stata "richiamata". Le sono state spiegate le regole, e in modo
amichevole. Ovvero: se hai una domanda su questo argomento, falla e basta.
Altrimenti procedi come delineato.




-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Riccardo Magliocchetti]

Ciao Marco,

Il 24/09/2015 13:55, Marco Paolini ha scritto:

C'è fermento nell'ambito dei servizi web negli ultimi mesi.

Stavolta è facebook a turbare le quiete acque del REST dove noi ci siamo
abbeverati così a lungo

>

Graphql https://facebook.github.io/graphql/ contine la specifica del protocollo
e le direttive per implementarlo al meglio lato server

c'è il parser scritto in c++ https://github.com/graphql/libgraphqlparser

e l'implementazione di riferimento in javascript lato server
https://github.com/graphql/graphql-js


Per finire il puzzle manca relay che è quello che dovrebbe semplificare la 
gestione di come e quando prendere i dati da un server graphql:

https://facebook.github.io/relay/

Non ho ancora provato graphql /relay ma li guardo con favore. Sono molto grato a 
facebook per aver tirato fuori react.js che ci ha evitati l'odiosa monocultura 
angular.



I pythonisti in tutto il mondo hanno subito sintonizzato le antenne e in questo
momento c'è un po' di fermento sui porting in python di queste tecnologie.
Alcuni riferimenti:

- https://github.com/dittos/graphqllib libreria per gestione request graphql
server-side
- https://github.com/syrusakbary/graphene una specie di rest-framework per 
graphql
- https://github.com/elastic-coders/py-graphqlparser il porting cython del 
parser

Io ci sto giocando da poche settimane e mi sembra essere un passo in avanti
significativo nell'ambto dei web services


Perchè? Nel backend usi js o python?

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Gollum1]

Il 24 settembre 2015 16:24,   ha scritto:
> Ciao Marco mi chiamo chiara,potrei chiederti una cosa?

Se è qualcosa inerente a questo post, chiedi e basta, non ci sono
autorizzazioni da chiedere...
Se è qualcosa inerente a python, ma non a questo post, devi aprire un
nuovo thread...
Se è qualcosa non inerente a python, ma che possa interessare la
comunità, nuovo thread con nell'oggetto la nomenclatura "[OT]"
Se è qualcosa che non interessa a nessuno, se non a Marco, scrivi a
Marco e non alla lista...


Byez
-- 
Gollum1 - http://www.gollumone.it
Tesoro, dov'é il mio teoro...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-26 19:26 GMT+02:00 Ivo Reano :

> E non era da richiamare! O forse sì?


Gollum e' troppo tempo che non interviene, stava andando in crisi di
astinenza ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Ivo Reano]

>> Ciao Marco mi chiamo chiara,potrei chiederti una cosa?


> > Se è qualcosa inerente a questo post, chiedi e basta, non ci sono
> > autorizzazioni da chiedere...
>
>

> >Byez
> --
> >Gollum1 - http://www.gollumone.it
>

E se fosse per invitarlo a "cena"? Avrebbe usato il giusto tono, leggero e
non confidente.
Secondo me non è "ancora" andata [OT]. E non era da richiamare! O forse sì?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Carlos Catucci]

2015-09-24 13:55 GMT+02:00 Marco Paolini :

>
> Cosa ne pensate?
>

A occhio sembra carino. Certo io "timeo faceass et dona ferentes", e con
REST sto bene, ma se e' qualcosa di meglio perche' no?

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[chiara_dodaro]

Ciao Marco mi chiamo chiara,potrei chiederti una cosa?

Inviato da Libero Mail per iOS


giovedì 24 settembre 2015, 13:55 +0200 da Marco Paolini  
:
>C'è fermento nell'ambito dei servizi web negli ultimi mesi.
>
>Stavolta è facebook a turbare le quiete acque del REST dove noi ci siamo 
>abbeverati così a lungo
>
>Graphql  https://facebook.github.io/graphql/ contine la specifica del 
>protocollo e le direttive per implementarlo al meglio lato server
>
>c'è il parser scritto in c++  https://github.com/graphql/libgraphqlparser
>
>e l'implementazione di riferimento in javascript lato server  
>https://github.com/graphql/graphql-js
>
>
>I pythonisti in tutto il mondo hanno subito sintonizzato le antenne e in 
>questo momento c'è un po' di fermento sui porting in python di queste 
>tecnologie. Alcuni riferimenti:
>
>-  https://github.com/dittos/graphqllib libreria per gestione request graphql 
>server-side
>-  https://github.com/syrusakbary/graphene una specie di rest-framework per 
>graphql
>-  https://github.com/elastic-coders/py-graphqlparser il porting cython del 
>parser
>
>
>Io ci sto giocando da poche settimane e mi sembra essere un passo in avanti 
>significativo nell'ambto dei web services
>
>Vi invito a partecipare anche nello slack sul canale #python  
>https://graphql.slack.com/messages/python (ste cose non si fanno più via IRC 
>ormai!)
>
>Cosa ne pensate?
>
>Marco
>___
>Python mailing list
>Python@lists.python.it
>http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python