DOMANDA Programmazione lato server

[Anto0699]

Ciao a tutti, sono uno studente universitario al primo anno di informatica. Prima di cominciare l' università, per passione, mi ero già "tuffato" in alcuni linguaggi di programmazione, tra questi Python e JavaScript (jQuery compreso). In questo momento, insieme ad un mio amico, sono intento alla realizzazione di un' applicazione che reputiamo interessante ma abbiamo un punto di domanda grande al momento riguardo la programmazione: l' organizzazione lato Server(?). Il fatto è che non abbiamo molta esperienza in questo campo, stavamo pensando però di utilizzare il Node.js. Leggevo però che anche il Python può essere sfruttato per il Web. Volevo sapere se qualcuno poteva darmi qualche chiarimento in merito, cioè sulle funzionalità lato Web del Python in generale e poi anche su quelle lato Server.

 

[DarkSmasher]

Ciao a tutti, sono uno studente universitario al primo anno di informatica. Prima di cominciare l' università, per passione, mi ero già "tuffato" in alcuni linguaggi di programmazione, tra questi Python e JavaScript (jQuery compreso). In questo momento, insieme ad un mio amico, sono intento alla realizzazione di un' applicazione che reputiamo interessante ma abbiamo un punto di domanda grande al momento riguardo la programmazione: l' organizzazione lato Server(?). Il fatto è che non abbiamo molta esperienza in questo campo, stavamo pensando però di utilizzare il Node.js. Leggevo però che anche il Python può essere sfruttato per il Web. Volevo sapere se qualcuno poteva darmi qualche chiarimento in merito, cioè sulle funzionalità lato Web del Python in generale e poi anche su quelle lato Server.

Spoiler

https://wiki.python.org/moin/WebFrameworks

 

[pabloski]

punto di domanda grande al momento riguardo la programmazione: l' organizzazione lato Server(?). Il fatto è che non abbiamo molta esperienza in questo campo, stavamo pensando però di utilizzare il Node.js. Leggevo però che anche il Python può essere sfruttato per il Web. Volevo sapere se qualcuno poteva darmi qualche chiarimento in merito, cioè sulle funzionalità lato Web del Python in generale e poi anche su quelle lato Server.

Onestamente il problema del server side e' piu' l'architettura che il linguaggio. Puoi usare il linguaggio piu' figo del mondo, poi pero' ti ritrovi col server down perche' il servizio non scala come si deve.

Pertanto la prima cosa da fare e' mettersi a tavolino ed analizzare che cosa state facendo, quanti utenti avra' questo servizio, quanti saranno connessi simultaneamente, quanta banda verra' consumata, quanta cpu, quanta ram.

Perche' giustamente tiri in ballo Node.js che e' il figo del momento. Peccato che Node.js sia single-thread e dunque un cancro per la scalabilita'. Giusto un esempio per capire che le cose non sono semplici dietro le quinte e purtroppo i servizi web sono cose molte onerose.

 

[Anto0699]

Ok capito. Diciamo che in generale il modo in cui dovrebbe lavorare sarebbe gestire delle richieste a dei database preesistenti. Eventualmente modificarne dei dati… per es. in base alla disponibilità di determinati prodotti ecc.… Ovviamente quindi anche mostrare all' utente precisi contenuti sempre basandosi sugli stessi DB. Più o meno come andrebbe impostata la cosa..?

 

[pabloski]

Ok capito. Diciamo che in generale il modo in cui dovrebbe lavorare sarebbe gestire delle richieste a dei database preesistenti. Eventualmente modificarne dei dati… per es. in base alla disponibilità di determinati prodotti ecc.… Ovviamente quindi anche mostrare all' utente precisi contenuti sempre basandosi sugli stessi DB. Più o meno come andrebbe impostata la cosa..?

Mi pare che in questo caso il lavoro pesante lo faccia il DBMS. Al che e' fondamentale scegliere un DBMS adeguato. Per esempio in passato mi sono trovato malissimo con MySQL con engine MyISAM. Perche' il motore del dbms lockava intere tabelle per fare gli aggiornamenti e quindi era impossibile scalare, cioe' fargli fare piu' modifiche su righe diverse simultaneamente. Il tutto diventava rapidamente ingestibile nei momenti in cui il traffico era elevato.

Nel caso di MySQL si sarebbe potuto scegliere un altro engine e lavorare alla configurazione per ottimizzare il tutto. Oppure ( la scelta che feci io ) sostituirlo con PostgreSQL, che e' un dbms alla pari di Oracle.

E questo discorso vale per i linguaggi. Scegliere un linguaggio con scarse capacita' multithread e' un suicidio. Python ha la GIL, Node.js ha un singolo thread. Ragion per cui Golang si e' diffuso in pochissimi anni proprio sul backend.

 

[Anto0699]

Capito, grazie ancora!

 

[cdtux]

E questo discorso vale per i linguaggi. Scegliere un linguaggio con scarse capacita' multithread e' un suicidio. Python ha la GIL, Node.js ha un singolo thread. Ragion per cui Golang si e' diffuso in pochissimi anni proprio sul backend.

Nel suo caso capacità multithread mi sembrano piuttosto ininfluenti visto che il grosso del lavoro lo farà il db (concordo su PG vs Mysql, il primo stà una spanna sopra..).
Poi anche golang non è multurhread ma concurrent, se non erro.. ma è un dettaglio ininfluente (perchè è comunque un ottimo linguaggio, se non fosse per la rottura dei workspace).
Node è si single thread, però bisogna tenere presente che si può clusterizzare molto semplicemente e con poco sforzo (vedi PM2 o docker & co).
Concordo con quanto detto precedentemente, ovvero che l'architettura del progetto è più importante del linguaggio/framework, anche se quest'ultimo deve essere scelto con cautela (visto che tutti hanno dei "contro").

Tornando in topic: se conoscete solamente python e javascript, usate quello che conoscete meglio.
Comunque se dovete solamente fare da "passacarte" (passatemi il termine..) tra client e db, probabilmente node sarà più performante (anche se più insidioso).
In più vi consiglio di dare uno sguardo a tecnologie come docker (con swarm/kubernetes), che potrebbero essere molto utili sia per far scalare il backend in modo semplice, sia per avere un ambiente di dev identico per tutti.

 

[pabloski]

Nel suo caso capacità multithread mi sembrano piuttosto ininfluenti visto che il grosso del lavoro lo farà il db (concordo su PG vs Mysql, il primo stà una spanna sopra..).

Dipende da cosa deve fare e come lo fara'. Se creera' un web service, dovra' per forza di cose accettare/elaborare centinaia, forse migliaia di richieste simultaneamente. Quindi non sara' solo il dbms a doversi sobbarcare l'onere di svolgere tantissime operazioni.

Poi anche golang non è multurhread ma concurrent

Il multithread e' uno dei metodi per implementare la concorrenza. Golang definisce le goroutines come entita' di concorrenza, ma le implementa tramite threading nativo e green threads.

Node è si single thread, però bisogna tenere presente che si può clusterizzare molto semplicemente e con poco sforzo

Avere tanti processi e' molto piu' oneroso che avere tanti thread. Perche' sprecare memoria e cicli di cpu? Node e' utile quando l'applicazione e' I/O centrica, altrimenti va nel pallone molto rapidamente.

 

[cdtux]

Dipende da cosa deve fare e come lo fara'. Se creera' un web service, dovra' per forza di cose accettare/elaborare centinaia, forse migliaia di richieste simultaneamente. Quindi non sara' solo il dbms a doversi sobbarcare l'onere di svolgere tantissime operazioni.

Per questo node potrebbe essere la scelta migliore (rispetto ad un django/flesk) visto l'elevato I/O.
Se alla fine si tratta di fare query al db e ritornare il risultato già strutturato (lato db), node+postgres mi sembra un'ottima soluzione, anche se più insidiosa da implementare (sia per via del codice asincrono di node, che per le query più "impegnative" da implementare).

Il multithread e' uno dei metodi per implementare la concorrenza. Golang definisce le goroutines come entita' di concorrenza, ma le implementa tramite threading nativo e green threads.

Grazie delle info, conosco poco golang.. (mi sta sui cojotes la storia dei workspace e quindi non lo uso.. lo so che è idiota come scusa.. :asd:)

Avere tanti processi e' molto piu' oneroso che avere tanti thread. Perche' sprecare memoria e cicli di cpu? Node e' utile quando l'applicazione e' I/O centrica, altrimenti va nel pallone molto rapidamente.

Concordo, ma alla fine è tutta una questione di compromessi..

 

[pabloski]

Per questo node potrebbe essere la scelta migliore (rispetto ad un django/flesk) visto l'elevato I/O.
Se alla fine si tratta di fare query al db e ritornare il risultato già strutturato (lato db), node+postgres mi sembra un'ottima soluzione, anche se più insidiosa da implementare (sia per via del codice asincrono di node, che per le query più "impegnative" da implementare).

Il problema e' che non sappiamo cosa fara' questo backend che dovrebbe implementare. Se si ritrovera' ad aver bisogno di fare anche una modesta quantita' di operazioni cpu-bound, saltera' in banco e dovra' riscrivere tutto con un altro linguaggio. Non che sia strano in questo ambiente, anzi e' la norma.

 

[Andretti60]

Il problema e' che non sappiamo cosa fara' questo backend che dovrebbe implementare. Se si ritrovera' ad aver bisogno di fare anche una modesta quantita' di operazioni cpu-bound, saltera' in banco e dovra' riscrivere tutto con un altro linguaggio. Non che sia strano in questo ambiente, anzi e' la norma.

Concordo.
Solo alcune precisazioni (in ordine sparso) in aggiunta alle ottime date da tutti voi:

• un server backend non dovrebbe mai avere un alto carico di CPU, significa fare lavorare poco e male il database (che e' quello che deve fare)
• quando si progetta un sistema come questo, direi che il 99% del risultato finale dipende da come e' implementato il database, io ho scritto molti applicativi di supporto per grossi database semplicemente nel vecchio, single-threaded, criticatissimo VB6, sfruttando le chiamate asincrone del database (Microsoft SQL server, scelto per complicate ragioni).
• una volta che il database e' stato configurato, occorre provarlo e testarlo, niente meglio che un semplice scripting language (tipo Python) per farlo, in una mezza giornata si possono scrivere semplici programmi di test, e a quel punto si vede se il database e' stato bene progettato, trovando i vari "colli di bottiglia" e iniziando a ottimizzare. A quel punto non ha ancora senso scrivere applicativi ne' tantomeno applicazioni back-end, se poi si deve cambiare il tutto.
• Infine ricordarsi che non esiste una soluzione "one size fits all", ecco perche' il nostro lavoro e' sempre interessante :)

 

[Anto0699]

Sinceramente non sto capendo molto con tutte queste terminologie:cry:ahahah. Spiego con un esempio come dovrebbe essere gestito il tutto. Il nostro server dovrebbe agganciarsi a database esterni, non creati da noi, e possibilmente manipolarli. Ad esempio, mettiamo che il programma debba mostrare dei box ed ogni box ha un database che elenca gli oggetti che sono contenuti nel box stesso. Quello che deve succedere è che se l'utente fa clic su uno dei box, il server deve mandare una richiesta al database di quel preciso box per ottenere gli oggetti contenuti in esso e mostrarli all'utente. Se ora l'utente decide di prendere uno degli oggetti, il server deve sottrarre 1 dal totale e aggiornare il database del box di cui sopra. Naturalmente deve essere pronto a gestire molte richieste insieme.

 

[pabloski]

E' praticamente la stessa cosa. Solo che invece di un dbms locale ci sono tanti dbms e db remoti. Suppongo ovviamente che abbiate le credenziali per l'accesso a questi database, altrimenti nisba.

 

[Anto0699]

Sì per quanto riguarda l' accesso non è un problema. Piuttosto quindi che linguaggio mi converrebbe usare per la gestione delle richieste o comunque del server in generale? Inoltre sarebbe da considerare anche il fatto che per l' hardware dovremmo aderire ad un servizio esterno, sarebbe inutile oltre che dispendioso se dovessimo comprare i pezzi ed assemblarlo. Ma ripeto in materia sono ignorante quindi se dico stupidaggini spero mi perdonerete ahahah.

 

[pabloski]

Piuttosto quindi che linguaggio mi converrebbe usare per la gestione delle richieste o comunque del server in generale?

Dipende dalle conoscenze che si hanno e dalle attivita' che questi script dovranno svolgere. Imho userei Go per implementare dei webservices altamente concorrenti.

Inoltre sarebbe da considerare anche il fatto che per l' hardware dovremmo aderire ad un servizio esterno

Nessuno assembla dei propri server. Ci sono addirittura multinazionali che girano sul cloud di Amazon.