Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST
Il 28/09/2015 21:43, Marco Paolini ha scritto: Il giorno 27 settembre 2015 10:38, Riccardo Magliocchetti mailto: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 -- 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
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
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] On the road to world domination (GO)
* enrico franchi (enrico.fran...@gmail.com) [150928 11:00]: E' BS. concordo p.s.: la 'S' sta per Silvio ? -- .*.finelli /V\ (/ \) -- ( ) Linux: Friends dont let friends use Piccolosoffice ^^-^^ -- Sto muovendo grandi passi verso il Fallimento, ma lo sto facendo con passione: a Bazzano sarebbero fieri di me. Ciabba G (@ciabba_g) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] On the road to world domination (GO)
On Sat, Sep 26, 2015 at 6:05 PM, Carlos Catucci wrote: > post.oreilly.com/rd/9z1zt8vv2pgakltgs0sjcm6gdubsjaihlc965j6m8og > Non da poco: mi piacerebbe che avesse ragione, ma mi sembra assolutamente fuori misura. Mi sembrano affermazioni da fiera della cicciolata. Anche l'unico punto vagamente oggettivo (100% containerization technology is in Go) mi sembra una troiata. Voglio dire... alla fine della fiera e' vero che lo strato superiore (o intermedio, a seconda di come lo vediamo) e' scritto in Go, ma il cuore che rende tutto possibile e' pur sempre un bel po' di C che gira nel Kernel. E comunque se la mia infrastruttura di virtualizzazione e' scritta in Go, questo non vuole dire che debba scrivere in Go anche quello che faccio girare nei container. E' come dire che Ruby domina il mondo perche' (fra chef e puppet) buona parte dell'orchestration e' scritta in Ruby (con un po' di gente che usa Ansible). Possibile che ci siano anche altri big player -- tipo roba interna alle aziende -- che non mi sta venendo in mente. E' BS. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
