Parliamo di software 2: Dudeswave

[amigaunicorn]

@Aethiss

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]

@teflon said in Parliamo di software 2: Dudeswave:

maledetto, ci sono cascat

questi vanno:

https://www.theyarehuge.com/

https://www.bigboobspictures.com/busty/

[Aethiss]

@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/233442

Hai 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]

@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 Semantics

per esempio

Cache-Control: max-age=3600, must-revalidate
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

non 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.

[Aethiss]

@amigaunicorn

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.

[amigaunicorn]

@Aethiss

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.

[Aethiss]

@amigaunicorn

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]

@amigaunicorn

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.

[amigaunicorn]

@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-Encoding	Descrizione del formato e codifica del contenuto	6 – Presentazione	Gestione di formato, lingua e codifica dei dati
Content-Length, Transfer-Encoding	Gestione e trasformazione del corpo del messaggio	6 – Presentazione	Controllano come viene interpretato il payload
Authorization, WWW-Authenticate	Autenticazione, avvio di sessione logica	5 – Sessione	Stabiliscono un contesto utente
Set-Cookie, Cookie	Persistenza della sessione utente	5 – Sessione (concettuale)	Permettono sessioni, ma sono header applicativi
Connection, Keep-Alive	Gestione della persistenza della connessione TCP	5 – Sessione	Controllano se tenere aperta la connessione TCP
Host, Referer, User-Agent	Informazioni contestuali sulla richiesta	7 – Applicazione	Header informativi, propri di HTTP
Cache-Control, ETag, Expires, Last-Modified	Gestione semantica della cache	7 – Applicazione	Agiscono solo a livello logico HTTP
Accept, Accept-Encoding, Accept-Language	Preferenze sul formato della risposta	6 – Presentazione	Il client dichiara come preferisce ricevere i dati
Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Accept	Negoziazione per cambio protocollo (es. WebSocket)	5 – Sessione	Implicano transizione di protocollo su TCP
Date, Server, Via	Metadati e diagnostica	7 – Applicazione	Informazioni accessorie

[amigaunicorn]

@Aethiss me ne rendo conto. E sto scancherando non poco. Ma, se solo metto un piccolo nginx con cache di fronte, vedo che il traffico sul backend cala drasticamente, specialmente alla voce "Ragazze sgargianti".

Siamo di nuovo li'. ALla fine non e' VUE che fa calare il traffico....ne' l'uso della CPU.

[Aethiss]

@amigaunicorn said in Parliamo di software 2: Dudeswave:

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.

Fermo restando che mi trovi d'accordo. Con un infrastruttura fatta bene, il linguaggio con cui scrivi il sito diventa sempre piu' irrilevante (tranne per il fatto che scrivi 1/3 del codice e produci il doppio, se ad esempio volessimo comparare proprio il codice React vs Php [ad esempio!!]).

C'e' solo un appunto, e cioe' dove ha una lacuna la tua risposta (forse non hai capito la mia), e cioe' :
Con una single page application, me ne infischio se non ho in cache i dati anche se accedo ad una pagina -> sezione -> sottoSezione per la prima volta.

Il bundle e' cachato, non arrivo nemmeno al server. cosa che con un qualsiasi altro linguaggio non posso fare.

[amigaunicorn]

@Aethiss

certo che la metti in cache, te lo fa una CDN, o te lo fa il reverse proxy che mette in cache i contenuti static, ed e' qui il punto.

Lo so che mentre i programmatori stanno chiusi nella loro stanzetta e testano il codice su localhost , o su un sistema di sviluppo che non ha niente in mezzo - perche' e' vero, testare coin le cache torna scomodo - si creano il loro mondo di favole ove l'infrastruttura e' trasparente e neutrale.

Ma quando esci dal mondo di favole, scopri che persino il tuo bundle, almeno in parte, lo aggiorni mediante una CDN, e che non passa quasi nessuna differenza - se non per i costi e le latenze della rete mobile - averlo in locale o scaricarlo dalla cdn di turno. Puo' fare differenza di costi sulla rete mobile, se proprio vogliamo, ma sulla CPU dei server, e' praticamente invisibile. I frontend cacheranno con un bel "Vary: User-Agent" e verranno salvati su disco per essere messi in cache.

Tra qualche giorno, appena avro' testato a dovere, mettero' un cache proxy davanti a nodeBB, non so ancora se usero' varnish o nginx, se non squid, e praticamente scaricherai i contenuti solo se sono cambiati. Il resto te lo fornira' come contenuto statico un server.

E servire un contenuto come contenuto statico e' molto diverso da generare il contenuto, che normalmente richiede CPU.

Ripeto, spesso chi fa il codice e' convinto di avere il nulla piatto , trasparente e neutrale tra client e server. Invece, oggi e' letteralmente impossibile farlo, perche' se anche ignori la cache, ti becchi un bel 301, 30x, o simili, e vieni rediretto ad una CDN.

Da quando e' arrivato il mondo mobile, con modelli di costo a consumo, non esistono piu' connessioni trasparenti E neutre.

Il vantaggio che hai avendo il bundle sul telefono, spesso, non e' nemmeno misurabile sui server rispetto al browser.

Ripeto: in situazioni reali. Su localhost (AKA "works on my laptop") o sulla rete di test (AKA: please, operations, no cache we need testing) , ovviamente e' come dici tu. Solo che non e' la realta' in cui vivi quando sei in produzione.

Il problema e' che i developers tendono a creare un mondo di fiabe nella loro stanzetta, e finiscono col meritarsi questo:

https://varnish-cache.org/docs/trunk/phk/notes.html

[absc]

@Aethiss

Ehm... te davvero consideri "server" e "servizio che fornisce i dati" come due cose diverse?

Perché quello che scrivi, in informatica, non ha senso.

[absc]

@Aethiss

In qualsiasi altro linguaggio non lo puoi fare per un motivo semplice. Un web browser capisce solo Javascript.

Esticazzi, ce lo scriviamo?

Se il browser potesse interpretare ed eseguire php/go/altro sarebbe un paragone che potresti fare, ma non puoi. Di nuovo paragoni fischi con fiaschi.

Ed ha ragione @amigaunicorn riguardo il caching. Non ha senso appesantire l'esperienza dell'utente (sí, non mi venire a raccontare che le webapp sono belle ed efficenti, ho un pc di dieci anni fa), quando le CDN fanno già il lavoro di alleggerire i tuoi server.

[Aethiss]

@absc said in Parliamo di software 2: Dudeswave:

Ehm... te davvero consideri "server" e "servizio che fornisce i dati" come due cose diverse?

Perché quello che scrivi, in informatica, non ha senso.

Era un esempio

Client, Dove hai il web-server (chiamala macchina, Vm o quello che vuoi), altro microservizio.
Su, e' ovvio che si semplifica in un forum.

[Aethiss]

@amigaunicorn

mm, si.. ni. Una CDN ha dei costi eh. Non e' detto che vuoi cachare tutto tutto. Pero' vero in ogni caso tutto quello che dici.
Cosi' come e' vero che ad oggi, anno del signore 2025, il risultato di un qualsiasi "sito" (mi limito solo al web) fatto con un qualsiasi framework moderno (spoiler: sono tutti framework javascript), ha una resa decisamente superiore ai suoi competitor anni 2000 (php & co ... o qualsiasi voglia scegliate voi). In fatto di resa finale all'utente, in fatto di sviluppo, ed anche per quanto discusso prima (ma mettiamo che NON SIA VERA QUESTA ULTIMA AFFERMAZIONE!)

Netflix

Ferrari

Zalando

Asos

e potrei andare avanti, ma sarebbe parlare dell'ovvio.

Persino pornhub, che di base fu fatto in php, ci hanno messo sopra vue.js, e' rimasto ancora vecchio codice legacy, che da quello che mi avevan detto alcuni ragazzi che ci lavorano, doveva essere rimosso anni fa, ma vedo e' ancora la'.

Il mondo e' tutto scemo (ok, battute facili) ? O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?

[absc]

@Aethiss

Bonariamente: non semplificare in un forum, non ne hai bisogno!

Non è un social e non è una chat!

[amigaunicorn]

@Aethiss said in Parliamo di software 2: Dudeswave:

O forse c'e' un perche' sui siti moderni si sviluppa con determinate tecnologie ?

o forse perche' si tratta dei sistemi consigliati dai maggiori produttori di telefoni, social network, eccetera?

Per diventare "industry standard" non servono dei razionali.
Ma ti sfido a misurare qualsiasi impatto sulla CPU dei backend, passando con milioni di utenti da browser puro a Vue, o React.
Uno standard di fatto puo' vivere anche semplicemente perche' e' quello che conoscono tutti i programmatori che si trovano sul mercato. Nessuno vuole aspettare mesi per trovare programmatori esperti in Erlang.

Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.

[Aethiss]

@amigaunicorn said in Parliamo di software 2: Dudeswave:

Non ho negato che esistano motivi per usare vue o react, ho solo detto che non sono quelli che dici tu. Tutto qui.

Rispetto la tua opinione, ma non la condivido (appieno).

[absc]

@Aethiss

Te l'ho scritto prima: un browser web è in grado di eseguire codice php?

No. Un browser web conosce solo javascript e di conseguenza, se tu vuoi fare "cose" sul client, dovrai usare Javascript.

Ma tu stai mescolando framework front-end con il back-end e ti ripeto. Il mio pc di 10 anni fa, con una SPA "moderna", si caga addosso.

E sí, l'informatica è moda, e tutti usano Javascript non perché è intrinsecamente una scelta migliore, ma perché facebook dice che è fico fare tutto in Javascript.

Cosa dici che succede alla tua SPA se togliamo V8 da chrome, dove google ha speso miliardi per far sí che Javascript fosse gestito in maniera passabile?

La storia del "eh tutti fanno cosí" ha stancato. L'informatica è peggio del fashion e quando chiedi motivazioni tecniche VERE, quasi tutti i programmatori ti rispondono "ma Guggle fa cosí, quindi DEVE essere buono" e si segue l'hype per gonfiare il CV. Non ci sono motivazioni tecniche.

Dire che ub framework Javascript è "moderno", è stupido e insensato, dato che sul client puoi usare solo javascript.

E sí, le web app devono morire, sono lente, farragginose, inconsistenti e non ne ho trovata una che non richiedesse una centrale nucleare per funzionare, soprattutto quando scritte con framework "moderni".