Parliamo di software 2: Dudeswave
-
@Aethiss said in Parliamo di software 2: Dudeswave:
Detto questo, ma non c'erano Tette un tempo. Che caxx e' successo
Sono nel settore "Cose da Maschi", cui si accede dopo una certa selezione, diciamo oltre una certa reputazione.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
Sono nel settore "Cose da Maschi", cui si accede dopo una certa selezione, diciamo oltre una certa reputazione.
ah ok.
si l'avevo letto mi sa.That's fine.
-
e che posso ribattere? E' tutto vero, e' tutto giusto.
Io a 20 anni lavoravo sugli as400.
Mi sono venduto al vil denaro. Si. E' un mondo giusto, No.
Questo abbiamo, Netanyahu e Javascript. E ci dobbiamo convivere.ma posso postare tette ?
@Aethiss said in Parliamo di software 2: Dudeswave:
ma posso postare tette
e' una domanda? Secondo me hai messo il punto interrogativo per sviarci. Toglilo.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
-
questo discorso suonerebbe bene, se
- il software non andasse deployato da operations (no, DevOps e' solo il termine piu' fallito della storia dell' IT).
- il software non andasse distribuito, e la catena di distribuzione di quella merda e' , sul piano della security, penosa. npm stocazzo.
- non fossimo in un mondo ove la containerizzazione domina, e il software ha bisogno di essere disegnato bene, per essere containerizzato.
il punto e' semplicemente, e' che quando il programmatore javascript ha fatto la sua push, e' pagato e se ne va a casa. Operations e' quella che verra' tirata giu' dal letto perche' qualche fottuto pacchetto npm e' diventato deprecato e al restart i container non si avviano piu'. o perche' qualcuno ha sostituito la liberia con qualcosa che e' figlio di Satana e Suor Germana.
Onestamente, dopo trent'anni di IT, ne ho piene le palle, lo dico come sfogo, di nuovi paradigmi che sono costruiti allo scopo preciso di consentire al programmatore Tandoori della situazione di sbarcare il lunario, convinti che "se abbassiamo ancora l'asticella dela competenza avremo un milione di programmatori in piu'", e adesso abbiamo un linguaggio di scripting che e' diventato un linguaggio di programmazione.
Mi aspetto di leggere CV di "programmatori autoexec.bat" da un momento all'altro. Per non parlare di "specialisti del power button". Tutta gente che ci spieghera' quanto e' sensato usare solo il power button per programmare, che non c'e' bisogno di imparare a programmare , perche' se sai usare "bene" il power button, sai quanto piu' veloce vada tutto se lo premi al momento giusto.
Ah, no. Esiste gia'. Si chiama Vibe Programming.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
no, DevOps e' solo il termine piu' fallito della storia dell' IT
questa mi interessa... ci apro un thread apposta
https://dudes.keinpfusch.net/topic/95/devops-e-solo-il-termine-piu-fallito-della-storia-dell-it
-
Non pensavo interessasse cosi' tanto, ma un tempo non c'erano Tette ?
comunque mi rendo conto che ho scritto rapidamente e senza spiegazioni capisco che il mio post vuol dire tutto e niente, quoto passo passo
@amigaunicorn said in Parliamo di software 2: Dudeswave:
aha. e se vuoi svilupare videogiochi, col javascript cosa ci fai? Per non parlare di AS400. Come usi il javascript su AS400?
Quindi, javascript non serve.
Partiamo dal: "Js Merda! Sempre!" Eh no, su AS400 non ci fai nulla. E no, nemmeno videogiochi (quasi: https://phaser.io/
) . Comunque io avevo specificato "web".@absc said in Parliamo di software 2: Dudeswave:
Stai paragonando pere con mele ;).
Io ho superato il "mi piace/non mi piace" da molto. Erlang è l'unico sistema che ti permette di costruire sistemi distribuiti senza vendere l'anima al diavolo.
Ni, se dalla tua descrizione parli di CMS, Blog.. social. Insomma roba accessibile via web.
Erlang fa il suo lavoro. Si. E' un must in quello che fa' ? No. E non e' questione di piacere o non piacereLato back-end Go/Java sono ancora un must. NodeJs gia' con node 18.x.x era a livello lato server di fare un lavoro eccellente sia in tempi di risposta, seppur ancora carente nel consumo delle risorse. Siamo a Node 24.x.x (Se fai tu stesso 2 prove facili facili, nel tuo server casalingo, vedrai che la comparazione e' impietosa).
@absc said in Parliamo di software 2: Dudeswave:
Non ho capito però: intendevi dire che Javascript scala? E se mi dici anche che ti piace quell'aborto chiamato "programmazione ad eventi", Spero di no perché altrimenti noi due abbiamo un problema.
Vedo di spiegarmi meglio. Come scala un app ha molte sfaccettature. Molte volte ho sentito da persone piu' varie che i framework javascript vengono usati per moda. In realta' e' falso. Facebook (che ha tirato fuori React), Google (che ha prodotto Angular), l'hanno fatto per un motivo ben preciso. E cioe' spostare il carico dal server ai client, avere applicazioni web piu' veloci e belle da usare, e delegare le comunicazioni server ai vari microservizi (Json its your friend!). Piu' ne hai, meglio scali, meglio tieni botta per tutte le problematiche relative ai big-data.
Un app web JS comparata a ,ignoriamo Erland, mettiamo php, escludendo per il momento il layer di caching, consuma 1/100 delle risorse lato server. Letteralmente scarichi il js sul tuo browser, ed e' TUTTO client. E se sono 100 utenti a navigare, i 100 con un app in React (ad esempio), parlano con il web server 1 volta, un app php ad ogni pagina che naviga.Poi se si vuole andare piu' nel profondo (sicurezza e/o indicizzazione) , bisogna iniziare a parlare di app isomorfiche (https://en.wikipedia.org/wiki/Isomorphic_JavaScript), ma mi fermo qua' che altrimenti sembra che voglio fare il professore (CHE NON SONO).
Anzi, ti dico questo. Se per caso vuoi una qualsiasi mano (non nei miei unici 10gg di vacanza adesso ehehe), nei miei limiti di tempo e non, lo faccio con voglia e piacere
Detto questo, ma non c'erano Tette un tempo. Che caxx e' successo ?
@Aethiss said in Parliamo di software 2: Dudeswave:
Ni, se dalla tua descrizione parli di CMS, Blog.. social. Insomma roba accessibile via web.
Erlang fa il suo lavoro. Si. E' un must in quello che fa' ? No. E non e' questione di piacere o non piacereLato back-end Go/Java sono ancora un must. NodeJs gia' con node 18.x.x era a livello lato server di fare un lavoro eccellente sia in tempi di risposta, seppur ancora carente nel consumo delle risorse. Siamo a Node 24.x.x (Se fai tu stesso 2 prove facili facili, nel tuo server casalingo, vedrai che la comparazione e' impietosa).
Non confondere "web" con "infrastruttura". Erlang serve il payload al tuo browser e poi non fa altro che rispondere a delle chiamate HTTP con un processo erlang (processo interno alla BEAM) per richiesta.
Go e Java sarebbero dei must su quali basi, di grazia? Per i web framework? Altrimenti qualsiasi linguaggio che abbia un server web decente funziona, se non si bada esclusivamente alla moda.
E no, l'idea di concorrenza di Node (callbacks) e' una merda che deve morire e male. Troppa gente crede che quello sia un modo scalabile di programmare. Non lo e', fa cacare e ti limita tutto ad un processo su una sola macchina. Go va gia' meglio con le goroutines ed i channels. Erlang va oltre, rendendo tutto trasparente fra un set piu' o meno grande di nodi computazionali connessi in una rete di macchine.
Se vuoi, vai a vedere quanto e' schifoso programmare ad eventi in C e tutti vengono a sbragare su libevent e simili. Sono retaggi del preistorico che porca puttana, nessuno ha il coraggio di urlare: "NO! L'I/O NON BLOCCANTE FICCATEVELO NEL CULO!".
Vedo di spiegarmi meglio. Come scala un app ha molte sfaccettature. Molte volte ho sentito da persone piu' varie che i framework javascript vengono usati per moda. In realta' e' falso. Facebook (che ha tirato fuori React), Google (che ha prodotto Angular), l'hanno fatto per un motivo ben preciso. E cioe' spostare il carico dal server ai client, avere applicazioni web piu' veloci e belle da usare, e delegare le comunicazioni server ai vari microservizi (Json its your friend!). Piu' ne hai, meglio scali, meglio tieni botta per tutte le problematiche relative ai big-data.
Un app web JS comparata a ,ignoriamo Erland, mettiamo php, escludendo per il momento il layer di caching, consuma 1/100 delle risorse lato server. Letteralmente scarichi il js sul tuo browser, ed e' TUTTO client. E se sono 100 utenti a navigare, i 100 con un app in React (ad esempio), parlano con il web server 1 volta, un app php ad ogni pagina che naviga.Poi se si vuole andare piu' nel profondo (sicurezza e/o indicizzazione) , bisogna iniziare a parlare di app isomorfiche (https://en.wikipedia.org/wiki/Isomorphic_JavaScript), ma mi fermo qua' che altrimenti sembra che voglio fare il professore (CHE NON SONO).
Io parlo di scalabilita' lato back-end. Se vuoi spingere la complessita' lato client sei liberissimo di farlo. Quello che io voglio e' aggiungere un nodo, fare un ping, ed averlo a rispondere a richieste in un secondo. Ma andiamo ai tuoi argomenti.
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi, quando nel 99% dei casi una banale chiamata a funzione sarebbe stata sufficente. Hai mai scritto un parser JSON da zero? Tutti quelli che mi vengono a raccontare che serializzare e deserializzare stringhe UTF-8, incluso l'escaping e' un modo efficente di trasmettere dati fra decine se non centinaia di processi, devono essere malmenati :).
JSON e' una merda e le architetture a microservizio devono morire.
Ah! Un cluster erlang ti da un architettura a microservizio in automatico, inclusa service discovery e senza bisogno di JSON. Ma qui me la tiro dai
Anzi, ti dico questo. Se per caso vuoi una qualsiasi mano (non nei miei unici 10gg di vacanza adesso ehehe), nei miei limiti di tempo e non, lo faccio con voglia e piacere
Detto questo, ma non c'erano Tette un tempo. Che caxx e' successo ?
Tette nella sezione apposita. Potrebbe essermi utile una mano con il front-end, quella si. Non sono un programmatore web purtroppo!
Un'ascia e' per sempre
-
@absc
Perché dici un aborto la programmazione ad eventi?
Un event(o packet, task, job, formaggio) loop e annesso dispatcher è un'ottima maniera per avere comportamenti precisi e definiti con un insieme eterogeneo di input.Certo, porcate come loop, dispatcher ed executor nello stesso thread, spaghettate di effetti laterali e tutte le cosine che i tizi del frontend amano sono appunto porcate, ma il concetto in se mi sembra buono.
Nello specifico intendo la programmazione ad eventi legata al I/O.
Un conto e' la programmazione ad eventi per gestire cose come: "ho schissato un tasto sulla tastiera", ma per dirmi: "Oh hai dati sun una socket!" no, dovrebbe esserci un processo, o thread, anche bloccante solo per quella socket.
Ci rendiamo conto che la programmazione ad eventi spacciata da nodejs cone "asincrona", e' un retaggio di 50 anni fa, quando stavano a malapena scoprendo come gestire la concorrenza?
Il modello di Go funziona, come anche quello di Erlang (una goroutine/processo per socket/richiesta) e rende tutto piu' semplice e chiaro da gestire.
Mai provato a programmare ad eventi in C? O con quella porcheria di libevent?
-
@Aethiss said in Parliamo di software 2: Dudeswave:
Ni, se dalla tua descrizione parli di CMS, Blog.. social. Insomma roba accessibile via web.
Erlang fa il suo lavoro. Si. E' un must in quello che fa' ? No. E non e' questione di piacere o non piacereLato back-end Go/Java sono ancora un must. NodeJs gia' con node 18.x.x era a livello lato server di fare un lavoro eccellente sia in tempi di risposta, seppur ancora carente nel consumo delle risorse. Siamo a Node 24.x.x (Se fai tu stesso 2 prove facili facili, nel tuo server casalingo, vedrai che la comparazione e' impietosa).
Non confondere "web" con "infrastruttura". Erlang serve il payload al tuo browser e poi non fa altro che rispondere a delle chiamate HTTP con un processo erlang (processo interno alla BEAM) per richiesta.
Go e Java sarebbero dei must su quali basi, di grazia? Per i web framework? Altrimenti qualsiasi linguaggio che abbia un server web decente funziona, se non si bada esclusivamente alla moda.
E no, l'idea di concorrenza di Node (callbacks) e' una merda che deve morire e male. Troppa gente crede che quello sia un modo scalabile di programmare. Non lo e', fa cacare e ti limita tutto ad un processo su una sola macchina. Go va gia' meglio con le goroutines ed i channels. Erlang va oltre, rendendo tutto trasparente fra un set piu' o meno grande di nodi computazionali connessi in una rete di macchine.
Se vuoi, vai a vedere quanto e' schifoso programmare ad eventi in C e tutti vengono a sbragare su libevent e simili. Sono retaggi del preistorico che porca puttana, nessuno ha il coraggio di urlare: "NO! L'I/O NON BLOCCANTE FICCATEVELO NEL CULO!".
Vedo di spiegarmi meglio. Come scala un app ha molte sfaccettature. Molte volte ho sentito da persone piu' varie che i framework javascript vengono usati per moda. In realta' e' falso. Facebook (che ha tirato fuori React), Google (che ha prodotto Angular), l'hanno fatto per un motivo ben preciso. E cioe' spostare il carico dal server ai client, avere applicazioni web piu' veloci e belle da usare, e delegare le comunicazioni server ai vari microservizi (Json its your friend!). Piu' ne hai, meglio scali, meglio tieni botta per tutte le problematiche relative ai big-data.
Un app web JS comparata a ,ignoriamo Erland, mettiamo php, escludendo per il momento il layer di caching, consuma 1/100 delle risorse lato server. Letteralmente scarichi il js sul tuo browser, ed e' TUTTO client. E se sono 100 utenti a navigare, i 100 con un app in React (ad esempio), parlano con il web server 1 volta, un app php ad ogni pagina che naviga.Poi se si vuole andare piu' nel profondo (sicurezza e/o indicizzazione) , bisogna iniziare a parlare di app isomorfiche (https://en.wikipedia.org/wiki/Isomorphic_JavaScript), ma mi fermo qua' che altrimenti sembra che voglio fare il professore (CHE NON SONO).
Io parlo di scalabilita' lato back-end. Se vuoi spingere la complessita' lato client sei liberissimo di farlo. Quello che io voglio e' aggiungere un nodo, fare un ping, ed averlo a rispondere a richieste in un secondo. Ma andiamo ai tuoi argomenti.
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi, quando nel 99% dei casi una banale chiamata a funzione sarebbe stata sufficente. Hai mai scritto un parser JSON da zero? Tutti quelli che mi vengono a raccontare che serializzare e deserializzare stringhe UTF-8, incluso l'escaping e' un modo efficente di trasmettere dati fra decine se non centinaia di processi, devono essere malmenati :).
JSON e' una merda e le architetture a microservizio devono morire.
Ah! Un cluster erlang ti da un architettura a microservizio in automatico, inclusa service discovery e senza bisogno di JSON. Ma qui me la tiro dai
Anzi, ti dico questo. Se per caso vuoi una qualsiasi mano (non nei miei unici 10gg di vacanza adesso ehehe), nei miei limiti di tempo e non, lo faccio con voglia e piacere
Detto questo, ma non c'erano Tette un tempo. Che caxx e' successo ?
Tette nella sezione apposita. Potrebbe essermi utile una mano con il front-end, quella si. Non sono un programmatore web purtroppo!
@absc said in Parliamo di software 2: Dudeswave:
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Bho, non ho mai avuto problemi con il mio portatile a vedere siti web (che non siano veramente scritti con i piedi da cani). Mi linki un sito web che ti risulta lento ? Riguardo alla questione bundle js, capisco che intendi, ma come si diceva prima... sappiamo come e' andata a finire
@absc said in Parliamo di software 2: Dudeswave:
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
No mi dispiace, non ci siamo capiti in questo senso. un applicazione php, che risponde html, passa da un web-server, con un plugin per il php, fa il lavoro chesso', di comunicare con un db o altro, poi formatta la risposta html lato server, e la risputa al client.
Io intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application).
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
@absc said in Parliamo di software 2: Dudeswave:
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi
Questo pero' e' lo standard. Il mondo usa per il 99% Json per le comunicazioni tra microservizi. Ok, non ti piace. Ma le alternative ?
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Si certo, aiuto lato html te lo do piu' che volentieri -
@absc said in Parliamo di software 2: Dudeswave:
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Bho, non ho mai avuto problemi con il mio portatile a vedere siti web (che non siano veramente scritti con i piedi da cani). Mi linki un sito web che ti risulta lento ? Riguardo alla questione bundle js, capisco che intendi, ma come si diceva prima... sappiamo come e' andata a finire
@absc said in Parliamo di software 2: Dudeswave:
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
No mi dispiace, non ci siamo capiti in questo senso. un applicazione php, che risponde html, passa da un web-server, con un plugin per il php, fa il lavoro chesso', di comunicare con un db o altro, poi formatta la risposta html lato server, e la risputa al client.
Io intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application).
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
@absc said in Parliamo di software 2: Dudeswave:
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi
Questo pero' e' lo standard. Il mondo usa per il 99% Json per le comunicazioni tra microservizi. Ok, non ti piace. Ma le alternative ?
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Si certo, aiuto lato html te lo do piu' che volentieriLeggero! E' tutto permesso, qui!
-
@absc said in Parliamo di software 2: Dudeswave:
"Spostare carico dal server al client". Mi spieghi allora perche' il mio laptop suda ad usare una qualsiasi app scritta con React o Angular? Non e' che forse, ma dico forse, a questo punto queste applicazioni sarebbero dovute essere native e girare come codice macchina vero e non come un bundle di Javascript obeso dentro un browser web altrettanto obeso?
Bho, non ho mai avuto problemi con il mio portatile a vedere siti web (che non siano veramente scritti con i piedi da cani). Mi linki un sito web che ti risulta lento ? Riguardo alla questione bundle js, capisco che intendi, ma come si diceva prima... sappiamo come e' andata a finire
@absc said in Parliamo di software 2: Dudeswave:
Puoi spostare la complessita' anche lato client se vuoi, nessuno te lo vieta. Ma se vuoi dati aggiornati dovrai andare dal server, per postarli, o almeno richiederli, no? Dove starebbe la differenza con un'applicazione PHP in questo caso? Non capisco il nesso. Non c'e' scritto da nessuna parte che un'applicazione scritta in PHP lato back-end non possa servire lo stesso Javascript che usi nella tua fantasmagorica app react. PHP risponde a richieste HTTP come una qualsiasi altra tecnologia simile, come e quante volte la tua applicazione contatta il server, esula dalla tecnologia usata.
Non c'e' nulla in PHP di diverso da Node in questo senso. Sono due tecnologie diverse che fanno la stessa cosa.
No mi dispiace, non ci siamo capiti in questo senso. un applicazione php, che risponde html, passa da un web-server, con un plugin per il php, fa il lavoro chesso', di comunicare con un db o altro, poi formatta la risposta html lato server, e la risputa al client.
Io intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application).
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
@absc said in Parliamo di software 2: Dudeswave:
Una parentesi sui microservizi e JSON: i microservizi devono morire e l'idea che JSON sia un buon formato di interscambio dati deve morire con essi
Questo pero' e' lo standard. Il mondo usa per il 99% Json per le comunicazioni tra microservizi. Ok, non ti piace. Ma le alternative ?
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Si certo, aiuto lato html te lo do piu' che volentieriIo intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application ).
Ho capito che parlavi di XMLHttpRequest, ma davvero non c'e' nulla nello stack PHP che ti impedisca di fare lo stesso. Uno script PHP e' giusto quello, uno script PHP. Che sputi fuori HTML o JSON non importa e oltre al classiclo plugin per apache, puoi usarlo tramite fastcgi, o lightspeed se vuoi performance migliori.
Zabbix per dire: ha il front-end scritto in PHP, usa XMLHttpRequest per recuperare i dati da delle API tramite JSON e le API sono esposte tramite PHP.
Hai sempre potuto farlo, che PHP fosse usato perlopiu' per generare HTML prima che XMLHttpRequest fosse la nuova bibbia, e' un altro paio di maniche.
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
I benchmark hanno sempre lasciato il tempo che trovano e onestamente, non sono mai stati realistici.
Mettiamoci di mezzo un database, mentre in Erlang uso il suo Mnesia e poi ne riparliamo.
Ma a parte questo, sono molto, molto convinto che confrontassero anche li', modelli diversi. Non puoi confrontare Node che e' single-thread con Erlang, dove di default se usi un qualsiasi web framework o web server, la prima cosa che viene fatta e' spawnare un processo interno per questioni di concorrenza. Inoltre, parliamo di un linguaggio imperativo e mutabile contro un linguaggio funzionale e immutabile.
Un sistema come Node vincera' sempre, su un benchmark "hello world", ma non scalera' allo stesso modo e non avra' le stesse garanzie di latenza. Che non significa essere il piu' veloce, in assoluto, ma fornire le stesse performance in modo consistente, pur avendo un garbage collector. La questione e' molto, molto piu' complessa di un banale benchmark.
Spero sia chiaro il punto.
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
E dove sarebbe diverso rispetto all'avere moduli specifici? Badaben che non ho detto no ai servizi, sto dicendo no alla proliferazione incontrollata di microservizi.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Non scusarti per questo. Sono sempre discussioni interessanti! Qui siamo al bar, e non ci prendiamo troppo seriamente.
Un'ascia e' per sempre
-
Io intendo: App-Js --> XHTTP request (Json) --> aggiorna App-js (no caricamenti, leggi : https://en.wikipedia.org/wiki/Single-page_application ).
Ho capito che parlavi di XMLHttpRequest, ma davvero non c'e' nulla nello stack PHP che ti impedisca di fare lo stesso. Uno script PHP e' giusto quello, uno script PHP. Che sputi fuori HTML o JSON non importa e oltre al classiclo plugin per apache, puoi usarlo tramite fastcgi, o lightspeed se vuoi performance migliori.
Zabbix per dire: ha il front-end scritto in PHP, usa XMLHttpRequest per recuperare i dati da delle API tramite JSON e le API sono esposte tramite PHP.
Hai sempre potuto farlo, che PHP fosse usato perlopiu' per generare HTML prima che XMLHttpRequest fosse la nuova bibbia, e' un altro paio di maniche.
Non ho parlato di node. ne ho parlato solo se confronti un server node ed un server in erlang che ti restituiscono "hello world". Node vince. Ma perde vs Go/Java. Non lo dico io, lo dicono i benchmark. Ma puoi testarlo facile tu stesso.
I benchmark hanno sempre lasciato il tempo che trovano e onestamente, non sono mai stati realistici.
Mettiamoci di mezzo un database, mentre in Erlang uso il suo Mnesia e poi ne riparliamo.
Ma a parte questo, sono molto, molto convinto che confrontassero anche li', modelli diversi. Non puoi confrontare Node che e' single-thread con Erlang, dove di default se usi un qualsiasi web framework o web server, la prima cosa che viene fatta e' spawnare un processo interno per questioni di concorrenza. Inoltre, parliamo di un linguaggio imperativo e mutabile contro un linguaggio funzionale e immutabile.
Un sistema come Node vincera' sempre, su un benchmark "hello world", ma non scalera' allo stesso modo e non avra' le stesse garanzie di latenza. Che non significa essere il piu' veloce, in assoluto, ma fornire le stesse performance in modo consistente, pur avendo un garbage collector. La questione e' molto, molto piu' complessa di un banale benchmark.
Spero sia chiaro il punto.
Bho, sara' che mi sto facendo vecchio. Sara' che lato web o app per cellulari ho usato (in produzione) tutta la storia degli ultimi 25 anni. Quando hai app con un livello di complessita', mole di dati imponente, pagamenti anche... no mi dispiace. Divide et Imperat: Microservizi specifici > Monolite.
E dove sarebbe diverso rispetto all'avere moduli specifici? Badaben che non ho detto no ai servizi, sto dicendo no alla proliferazione incontrollata di microservizi.
Importante: Mi sono reso conto che ho fatto una cosa che odio in generale. E cioe' portare la discussione verso tutto un altro discorso mentre tu parlavi del tuo progetto, e di questo me ne scuso.
Non scusarti per questo. Sono sempre discussioni interessanti! Qui siamo al bar, e non ci prendiamo troppo seriamente.
@absc ma in realta' mi trovi d'accordo in larga parte eh, vengo da programmazione old school anche io. E' vero che i benchmark lasciano il tempo che trovano.
solo una cosa, lasciatelo dire da chi ci ha passato la vita, prima su php, poi (aimhe') su javascript.
Esempio: hai un servizio pornJson, che restituisce la lista delle pornostar, e delle categorie alle quali appartengono, ed ha un database di video di queste signorine. E' un servizio esterno, pronto funzionante. Lo puoi usare, e non preoccuparti di niente. Ti manca quindi solo di fare :
- Un sito in php (no javascript) che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
- Un sito in React, che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
Uno di questi e' una 127, uno di questi e' una ferrari.
Se, per qualche strano motivo, questo sito tramite passa-parola, inizia ad essere visitato da milioni di persone (non saprei mai perche' dovrebbero, ma mettiamo sia vero), uno dei 2, ti richiedera' 100 volte piu' risorse.ah, il sito si chiama tettepertutti.org !!!
-
@absc ma in realta' mi trovi d'accordo in larga parte eh, vengo da programmazione old school anche io. E' vero che i benchmark lasciano il tempo che trovano.
solo una cosa, lasciatelo dire da chi ci ha passato la vita, prima su php, poi (aimhe') su javascript.
Esempio: hai un servizio pornJson, che restituisce la lista delle pornostar, e delle categorie alle quali appartengono, ed ha un database di video di queste signorine. E' un servizio esterno, pronto funzionante. Lo puoi usare, e non preoccuparti di niente. Ti manca quindi solo di fare :
- Un sito in php (no javascript) che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
- Un sito in React, che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
Uno di questi e' una 127, uno di questi e' una ferrari.
Se, per qualche strano motivo, questo sito tramite passa-parola, inizia ad essere visitato da milioni di persone (non saprei mai perche' dovrebbero, ma mettiamo sia vero), uno dei 2, ti richiedera' 100 volte piu' risorse.ah, il sito si chiama tettepertutti.org !!!
@Aethiss said in Parliamo di software 2: Dudeswave:
ah, il sito si chiama tettepertutti.org
maledetto, ci sono cascato
-
@absc ma in realta' mi trovi d'accordo in larga parte eh, vengo da programmazione old school anche io. E' vero che i benchmark lasciano il tempo che trovano.
solo una cosa, lasciatelo dire da chi ci ha passato la vita, prima su php, poi (aimhe') su javascript.
Esempio: hai un servizio pornJson, che restituisce la lista delle pornostar, e delle categorie alle quali appartengono, ed ha un database di video di queste signorine. E' un servizio esterno, pronto funzionante. Lo puoi usare, e non preoccuparti di niente. Ti manca quindi solo di fare :
- Un sito in php (no javascript) che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
- Un sito in React, che fa vedere la lista delle pornostar, selezionare/filtrare per categorie, e fa vedere il video.
Uno di questi e' una 127, uno di questi e' una ferrari.
Se, per qualche strano motivo, questo sito tramite passa-parola, inizia ad essere visitato da milioni di persone (non saprei mai perche' dovrebbero, ma mettiamo sia vero), uno dei 2, ti richiedera' 100 volte piu' risorse.ah, il sito si chiama tettepertutti.org !!!
guarda , tutto questo andava bene, diciamo, fino ai primi del 2000, quando si faceva il "sizing" dei server confrontando domanda e capacita'.
Poi l'uomo bianco ha inventato delle cose.
-
I primi programmatori hanno cominciato a chiedersi, per esempio , quante volte cambia il numero di film che fa una pornostar in un anno. In un giorno. In una settimana. E cosi' prima e' arrivata la cache. Un meccanismo fantastico, quasi sconosciuto ai programmatori, che consente di aggiornare molto meno. Ma il programmatore di oggi non legge gli RFC, perche' mai dovrebbe? Non scrive documentazione, figuriamoci se la legge.
-
Poi sono arrivati quei bastardi degli architetti di sistema, e la cache ha cominciato ad evolversi , sino a raggiungere il concetto di "CDN".Content delivery Network. Credi davvero che ogni chiamata raggiunga il server di Facebook? Davvero aumenta il load di qualsiasicosa?
-
Poi e' arrivato il cloud, ed ecco che puo' addirittura succedere che usi solo le risorse che effettivamente consumi. (se lo fai bene). E puf, tutto questo discorso e' ridondante. Infine il cloud si e' evoluto nei vari SAAS, e oggi si, dell'efficienza del client non frega piu' niente a nessuno.
-
Il tutto si e' evoluto, per il settore mobile, in un "edge computing", per cui alla fine dei conti, il tuo server di traffico ne serve davvero poco. Anche quando usi il browser. A meno che tu non VOGLIA fare tutto da server, a carico tuo.
Nel frattempo, pero', il problema era di trasformare in programmatori piu' incompetenti possibile, in modo da abbassare gli stipendi aumentando l'offerta. E cosi' abbiamo i programmatori javascript. Gente che faceva gli effetti speciali nella pagina web delle pizzerie, e adesso parla di UI/UX.
E questo per un semplice motivo: perche' spostare il traffico da server a client ha senso solo se il traffico ti costa pochissimo. Ma tra client e server c'e' la rete, e almeno per il mondo mobile, una rete che costa molto. Quindi, abbassare il costo della capacita' dei server (che costa sempre meno) a spese del traffico mobile - che non e' decisamente economicissimo oggi - ha senso solo quando ha senso.
Ho visto succedere questa cosa tante di quelle volte, ormai, partendo da Java , che non mi preoccupo piu'. Per via di due teoremi.
- ogni tentativo di abbassare il reddito dei programmatori alza il reddito dei sistemisti
- ogni tentativo di abbassare il reddito dei sistemisti alza il reddito dei programmatori
E questi due teoremi sono inamovibili, per una semplice ragione: "informatica" significa che del software gira su dell'hardware. Quello che togli da una parte, va dall'altra.
i fessi che continuano a proporre nuove tecnologie per tagliare i costi, insomma, non fanno altro che, nel lungo termine, alzarti il reddito, che tu sia un sistemista, o un programmatore. A spese di complicarti la vita al lavoro.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@Aethiss said in Parliamo di software 2: Dudeswave:
ah, il sito si chiama tettepertutti.org
maledetto, ci sono cascato
-
guarda , tutto questo andava bene, diciamo, fino ai primi del 2000, quando si faceva il "sizing" dei server confrontando domanda e capacita'.
Poi l'uomo bianco ha inventato delle cose.
-
I primi programmatori hanno cominciato a chiedersi, per esempio , quante volte cambia il numero di film che fa una pornostar in un anno. In un giorno. In una settimana. E cosi' prima e' arrivata la cache. Un meccanismo fantastico, quasi sconosciuto ai programmatori, che consente di aggiornare molto meno. Ma il programmatore di oggi non legge gli RFC, perche' mai dovrebbe? Non scrive documentazione, figuriamoci se la legge.
-
Poi sono arrivati quei bastardi degli architetti di sistema, e la cache ha cominciato ad evolversi , sino a raggiungere il concetto di "CDN".Content delivery Network. Credi davvero che ogni chiamata raggiunga il server di Facebook? Davvero aumenta il load di qualsiasicosa?
-
Poi e' arrivato il cloud, ed ecco che puo' addirittura succedere che usi solo le risorse che effettivamente consumi. (se lo fai bene). E puf, tutto questo discorso e' ridondante. Infine il cloud si e' evoluto nei vari SAAS, e oggi si, dell'efficienza del client non frega piu' niente a nessuno.
-
Il tutto si e' evoluto, per il settore mobile, in un "edge computing", per cui alla fine dei conti, il tuo server di traffico ne serve davvero poco. Anche quando usi il browser. A meno che tu non VOGLIA fare tutto da server, a carico tuo.
Nel frattempo, pero', il problema era di trasformare in programmatori piu' incompetenti possibile, in modo da abbassare gli stipendi aumentando l'offerta. E cosi' abbiamo i programmatori javascript. Gente che faceva gli effetti speciali nella pagina web delle pizzerie, e adesso parla di UI/UX.
E questo per un semplice motivo: perche' spostare il traffico da server a client ha senso solo se il traffico ti costa pochissimo. Ma tra client e server c'e' la rete, e almeno per il mondo mobile, una rete che costa molto. Quindi, abbassare il costo della capacita' dei server (che costa sempre meno) a spese del traffico mobile - che non e' decisamente economicissimo oggi - ha senso solo quando ha senso.
Ho visto succedere questa cosa tante di quelle volte, ormai, partendo da Java , che non mi preoccupo piu'. Per via di due teoremi.
- ogni tentativo di abbassare il reddito dei programmatori alza il reddito dei sistemisti
- ogni tentativo di abbassare il reddito dei sistemisti alza il reddito dei programmatori
E questi due teoremi sono inamovibili, per una semplice ragione: "informatica" significa che del software gira su dell'hardware. Quello che togli da una parte, va dall'altra.
i fessi che continuano a proporre nuove tecnologie per tagliare i costi, insomma, non fanno altro che, nel lungo termine, alzarti il reddito, che tu sia un sistemista, o un programmatore. A spese di complicarti la vita al lavoro.
@amigaunicorn said in Parliamo di software 2: Dudeswave:
I primi programmatori hanno cominciato a chiedersi, per esempio , quante volte cambia il numero di film che fa una pornostar in un anno. In un giorno. In una settimana. E cosi' prima e' arrivata la cache.
Sempre che si discuteva senza mettere in mezzo layer di cache o CDN.
E sempre volendo semplificare:hai un sito di donnine con 24354332 pagine diverse.
Io vedo questa con 2 tette fantastiche, e voglio condividere con te la mia scoperta:
ti mando il link : www.tettextutti.org/categories/super-tette/sylvia-a-pecora-2/233442Hai un sito in php, Che cache mandi ?
Hai un sito in React -> cache del bundle -> hey guarda sylvia !!ripeto: sto semplificando. Eh si, io sono cloud addicted, so bene che le soluzioni architetturali sono molteplici.
Ma lato web "puro", una single page application con un qualsiasi framwork js, ad oggi, batte qualsiasi altro "sito web" fatto in perl/php/fra-cazzi-da-velletri-framework.
-
-
@amigaunicorn said in Parliamo di software 2: Dudeswave:
I primi programmatori hanno cominciato a chiedersi, per esempio , quante volte cambia il numero di film che fa una pornostar in un anno. In un giorno. In una settimana. E cosi' prima e' arrivata la cache.
Sempre che si discuteva senza mettere in mezzo layer di cache o CDN.
E sempre volendo semplificare:hai un sito di donnine con 24354332 pagine diverse.
Io vedo questa con 2 tette fantastiche, e voglio condividere con te la mia scoperta:
ti mando il link : www.tettextutti.org/categories/super-tette/sylvia-a-pecora-2/233442Hai un sito in php, Che cache mandi ?
Hai un sito in React -> cache del bundle -> hey guarda sylvia !!ripeto: sto semplificando. Eh si, io sono cloud addicted, so bene che le soluzioni architetturali sono molteplici.
Ma lato web "puro", una single page application con un qualsiasi framwork js, ad oggi, batte qualsiasi altro "sito web" fatto in perl/php/fra-cazzi-da-velletri-framework.
@Aethiss said in Parliamo di software 2: Dudeswave:
Hai un sito in php, Che cache mandi ?
che tu mi creda o meno, ci sono degli header, menzionati in un posto chiamato RFC, che se ne sbattono il cazzo di che linguaggio usi il tuo sito, e usando etag con i dovuti parametri, possono fare in modo che il tuo client metta in cache una risposta.
RFC 9110 – HTTP Semantics
RFC 9111 – HTTP Caching
RFC 9111 – HTTP Caching
RFC 9110 – HTTP Semantics
RFC 9110 – HTTP Semanticsper esempio
Cache-Control: max-age=3600, must-revalidate ETag: "abc123" Last-Modified: Wed, 21 Oct 2015 07:28:00 GMTnon c'entra se a generare abc123 sia php o erlang, il tuo browser la mette in cache per un'ora. Poi , e solo poi, se la va a riprendere.
E no, non esiste un sitino in php, esiste il client ed esiste il server.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@Aethiss said in Parliamo di software 2: Dudeswave:
Hai un sito in php, Che cache mandi ?
che tu mi creda o meno, ci sono degli header, menzionati in un posto chiamato RFC, che se ne sbattono il cazzo di che linguaggio usi il tuo sito, e usando etag con i dovuti parametri, possono fare in modo che il tuo client metta in cache una risposta.
RFC 9110 – HTTP Semantics
RFC 9111 – HTTP Caching
RFC 9111 – HTTP Caching
RFC 9110 – HTTP Semantics
RFC 9110 – HTTP Semanticsper esempio
Cache-Control: max-age=3600, must-revalidate ETag: "abc123" Last-Modified: Wed, 21 Oct 2015 07:28:00 GMTnon c'entra se a generare abc123 sia php o erlang, il tuo browser la mette in cache per un'ora. Poi , e solo poi, se la va a riprendere.
E no, non esiste un sitino in php, esiste il client ed esiste il server.
Gia' Parliamo di 2 livelli di cache diversi. Tu parli a livello browser, io ti parlo di layer di cache a livello infrastruttura. Ma Ignoriamo il mio, e prendiamo il TUO esempio, partendo dal mio.
- mio browser: "hey, guarda che tette!! ora mando il link ai miei amici !!"
- browser amico 1 (App React): click -> bundle cachato -> "che tette !!"
- browser amico 2 (App php): click -> non ha cache di questa pagina, e non potrebbe (EDIT: se non qualche tag "abc123") -> chiama server -> server fa suo lavoro -> client -> tette.
-
Gia' Parliamo di 2 livelli di cache diversi. Tu parli a livello browser, io ti parlo di layer di cache a livello infrastruttura. Ma Ignoriamo il mio, e prendiamo il TUO esempio, partendo dal mio.
- mio browser: "hey, guarda che tette!! ora mando il link ai miei amici !!"
- browser amico 1 (App React): click -> bundle cachato -> "che tette !!"
- browser amico 2 (App php): click -> non ha cache di questa pagina, e non potrebbe (EDIT: se non qualche tag "abc123") -> chiama server -> server fa suo lavoro -> client -> tette.
siamo davvero nel 2025 a discutere del fatto che la cache funziona SOLO dopo la prima volta? E' ovvio che non puoi evitare la prima chiamata.
Ma la foto di tette non cambia, ed e' contenuto statico. Finira' in CDN. Che bisogno hai di programmare ad hoc un client, solo perche'.... boh.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
siamo davvero nel 2025 a discutere del fatto che la cache funziona SOLO dopo la prima volta? E' ovvio che non puoi evitare la prima chiamata.
Ma la foto di tette non cambia, ed e' contenuto statico. Finira' in CDN. Che bisogno hai di programmare ad hoc un client, solo perche'.... boh.
Pero' sembriamo ubriachi che si accompagnano a casa a vicenda
Assumendo che siamo 2 persone le quali tutti e 2 sanno di che parlano, e SEMPLIFICANDO (ignoriamo CDN etc...)App in React:
- hey che sito e' questo ? click -> chiamo server che restituisce bundle -> browser mette in cache il bundle -> Tette&Culi via PornJsonService
- figo, voglio Tette ! click -> bundle cachato -> tette via PornJsonService
- mah, forse preferivo culi ! click -> bundle cachato -> culi ....
App in quello che vuoi (No SPA/ No Js)
- hey che sito e' questo ? click -> chiamo server -> server contatta PornJsonService -> restituisce al client -> cache RFC -> Tette&Culi
- figo, voglio Tette ! click -> chiamo server -> server contatta PornJsonService -> restituisce al client che sa gia' che deve renderizzare "abc123" (irrilevante) -> Tette
- mah, forse preferico culi ! click -> come sopra -> culi ...
la prima app non ci parla piu' con il server, perche' dovrebbe ? parla con il servizio che deve fornire i dati (culi e tette)
la seconda app fa parlare il server ad ogni chiamata con il servizio che deve fornire dati di culi e tette.puoi cachare "abc", "123" e quello che vuoi, ma i contenuti sono quelli rilevanti, che sara' il server a fornire. Ad ogni chiamata.
-
siamo davvero nel 2025 a discutere del fatto che la cache funziona SOLO dopo la prima volta? E' ovvio che non puoi evitare la prima chiamata.
Ma la foto di tette non cambia, ed e' contenuto statico. Finira' in CDN. Che bisogno hai di programmare ad hoc un client, solo perche'.... boh.
Questo stesso servizio che hai messo su :
usa Vue.js !
Se vuoi puoi anche mettere su il buon vecchio https://www.phpbb.com/
Fanno lo stesso eh. Secondo me e' come usare una fiat 127 (che per carita' andra'), rispetto ad una macchina moderna. -
Pero' sembriamo ubriachi che si accompagnano a casa a vicenda
Assumendo che siamo 2 persone le quali tutti e 2 sanno di che parlano, e SEMPLIFICANDO (ignoriamo CDN etc...)App in React:
- hey che sito e' questo ? click -> chiamo server che restituisce bundle -> browser mette in cache il bundle -> Tette&Culi via PornJsonService
- figo, voglio Tette ! click -> bundle cachato -> tette via PornJsonService
- mah, forse preferivo culi ! click -> bundle cachato -> culi ....
App in quello che vuoi (No SPA/ No Js)
- hey che sito e' questo ? click -> chiamo server -> server contatta PornJsonService -> restituisce al client -> cache RFC -> Tette&Culi
- figo, voglio Tette ! click -> chiamo server -> server contatta PornJsonService -> restituisce al client che sa gia' che deve renderizzare "abc123" (irrilevante) -> Tette
- mah, forse preferico culi ! click -> come sopra -> culi ...
la prima app non ci parla piu' con il server, perche' dovrebbe ? parla con il servizio che deve fornire i dati (culi e tette)
la seconda app fa parlare il server ad ogni chiamata con il servizio che deve fornire dati di culi e tette.puoi cachare "abc", "123" e quello che vuoi, ma i contenuti sono quelli rilevanti, che sara' il server a fornire. Ad ogni chiamata.
@Aethiss said in Parliamo di software 2: Dudeswave:
puoi cachare "abc", "123" e quello che vuoi, ma i contenuti sono quelli rilevanti, che sara' il server a fornire. Ad ogni chiamata.
solo se i contenuti cambiano tra una chiamata e l'altra. Altrimenti, anche escludendo le CDN, ci pensa la cache del frontend, bigIP o quant'altro. Ma se c'erano header di cache, succedera' ogni ora, non ad ogni refresh.
abc123 e' il nome dell'etag. Un tempo indicava l' inode del file statico sul server, ora non piu'.
E non c'e' affatto bisogno di rigenerare un contenuto statico, mi spiace. Se non cambia ad ogni click, puoi servirlo da una cache, anche su disco, se proprio detesti le CDN. Quella chiamata non arriverebbe mai al server, dove sta la business logic, si fermerebbe al reverse proxy di frontend.
Adesso mi dirai "ignora anche il proxy di frontend e gli RFC.
E allora, il tuo problema si esprime con:
siamo nel 1984, quando non esistevano CDN, non esistevano frontend proxy, e quando non esistevano gli header HTTP , cioe' nemmeno HTTP.Il nostro client si connette, usando un modem 28800 BAUD, alla BBS, e deve scaricare il file tette.zip dalla libreria "cose zozze". Come faccio una app react?"
E la risposta sara' "usa QWK con rz/sz".
Ma ripeto, nel 2025, avendo le CDN, avendo il cloud, avendo i proxy di frontend, avendo ottimizzatori del TCP come BigIP, avendo gli header cache, l'idea che tu migliori la vita al server solo perche' usi react mi fa alquanto ridere, onestamente.
Header HTTP Funzione Livello OSI Note Content-Type,Content-Encoding,Content-Language,Content-Transfer-EncodingDescrizione del formato e codifica del contenuto 6 – Presentazione Gestione di formato, lingua e codifica dei dati Content-Length,Transfer-EncodingGestione e trasformazione del corpo del messaggio 6 – Presentazione Controllano come viene interpretato il payload Authorization,WWW-AuthenticateAutenticazione, avvio di sessione logica 5 – Sessione Stabiliscono un contesto utente Set-Cookie,CookiePersistenza della sessione utente 5 – Sessione (concettuale) Permettono sessioni, ma sono header applicativi Connection,Keep-AliveGestione della persistenza della connessione TCP 5 – Sessione Controllano se tenere aperta la connessione TCP Host,Referer,User-AgentInformazioni contestuali sulla richiesta 7 – Applicazione Header informativi, propri di HTTP Cache-Control,ETag,Expires,Last-ModifiedGestione semantica della cache 7 – Applicazione Agiscono solo a livello logico HTTP Accept,Accept-Encoding,Accept-LanguagePreferenze sul formato della risposta 6 – Presentazione Il client dichiara come preferisce ricevere i dati Upgrade,Sec-WebSocket-Key,Sec-WebSocket-AcceptNegoziazione per cambio protocollo (es. WebSocket) 5 – Sessione Implicano transizione di protocollo su TCP Date,Server,ViaMetadati e diagnostica 7 – Applicazione Informazioni accessorie
