Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST
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
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
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
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
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
> 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
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] Presentazione
Benvenuto! Il giorno Mar 29 Set 2015 19:19 Giovanni Porcari < giovanni.porc...@softwell.it> ha scritto: > > > Il giorno 29/set/2015, alle ore 18:42, Salvo Rapisarda < > salvor...@yahoo.it> ha scritto: > > > > Ciao, > > > > mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato > allo sviluppo nel linguaggio Python (che trovo fantastico!) e nel relativo > web framework Django. > > > > Ho deciso di imparare a programmare in Python grazie al fatto che ho > utilizzato la piattaforma cloud OpenStack che è interamente scritta in > questo linguaggio. > > > > Dopo cosi' tanto tempo ho notato che esiste anche un community italiana > su Python e quindi ho deciso di iscrivermi a questa mailing list. > > > > Spero di essere il benvenuto! :) > > > > Salvo. > > > > > > Ciao Salvo e benvenuto :) > > G > > ___ > 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-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
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
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. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Presentazione
> Il giorno 29/set/2015, alle ore 18:42, Salvo Rapisarda > ha scritto: > > Ciao, > > mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato allo > sviluppo nel linguaggio Python (che trovo fantastico!) e nel relativo web > framework Django. > > Ho deciso di imparare a programmare in Python grazie al fatto che ho > utilizzato la piattaforma cloud OpenStack che è interamente scritta in questo > linguaggio. > > Dopo cosi' tanto tempo ho notato che esiste anche un community italiana su > Python e quindi ho deciso di iscrivermi a questa mailing list. > > Spero di essere il benvenuto! :) > > Salvo. > > Ciao Salvo e benvenuto :) G ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Presentazione
Ciao, mi chiamo Salvo Rapisarda e da un anno a questa parte mi sono avvicinato allo sviluppo nel linguaggio Python (che trovo fantastico!) e nel relativo web framework Django. Ho deciso di imparare a programmare in Python grazie al fatto che ho utilizzato la piattaforma cloud OpenStack che è interamente scritta in questo linguaggio. Dopo cosi' tanto tempo ho notato che esiste anche un community italiana su Python e quindi ho deciso di iscrivermi a questa mailing list. Spero di essere il benvenuto! :) Salvo. -- Salvo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST
On 09/26/2015 07:26 PM, Ivo Reano wrote: O forse sì? Forse si. Le prove sono: - Top quoting; - Don't ask, ask! Enrico ___ 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-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
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
> 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
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
>> 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
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
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