Suggerimento per interfaccia web <--> microcontroller

[boiler]

Io userei Apache.

nginx mi sembra piú semplice (ma forse mi sbaglio). Per quale motivo propendi per Apache?

HTML/CSS/WASM/C

WASM non sarebbe sufficiente a rimpiazzare HTML e CSS? Quale è il ruolo di questi due nel contesto di un'applicazione WASM?

Ti consiglio di fare un reposistorio pubblico su GitHub e farti aiutare da ChatGPT Pro sia per la generazione del codice dell'applicazione che del codice delle funzioni di test.

No, per diversi motivi non è un'opzione.

Boiler

[fairyvilje]

Usi qualcosa off-the-shelf o l'hai scritto tu? Nel primo caso, se mi puoi indicare qualcosa te ne sarei grato.

Dipende dal linguaggio, ma sono poche linea di codice assumendo di avere una libreria di base decente .
In C++, usando Crow sono poche linee di codice visto che websocket è molto simile ai socket unix. Per esempio https://github.com/lazy-eggplant/vs.log ... 9C9-L706C8

In javascript/typescript non ho un esempio pubblico ma è similmente semplice. I maggiori runtime che usano quei linguaggi (io uso Bun o txiki di solito) hanno una buona libreria che già supporta socket e websocket, e bindarne un paio è grossomodo simile.

[EnricoMigliore]

Ciao,

Io userei Apache.
nginx mi sembra piú semplice (ma forse mi sbaglio). Per quale motivo propendi per Apache?

Apache l'ho usato per la prima volta nel 2001 e mi sono trovato subito a mio agio.

Dietro Apache c'e' la fondazione Apache che garantisce la qualita' del software

Nginx probabilmente performa meglio perche' sulla stessa socket TCP e' in grado di servire piu' utenti. Tuttavia mi fido di piu' del made in USA piuttosto che del made in USSR.

HTML/CSS/WASM/C

WASM non sarebbe sufficiente a rimpiazzare HTML e CSS? Quale è il ruolo di questi due nel contesto di un'applicazione WASM?

WASM non rimpiazza HTML e CSS.

WASM e' codice pseudo-assembler che viene tradotto dal brower in tempo reale nell'assembler nativo della piattaforma x86 o ARM. E' il futuro del Web perche' esegue codice 10/20 volte piu' veloce di Javascript che e' interpretato.

WASM e' generato da un compilatore C, C++, C#, Java, Python, Rust, ...

WASM serve per scrivere il front-end della web application cioe' la parte di web application che gira nel browser.

La rimanente parte della web application, cioe' il Back-end, gira sul computer server.

Front-end e Back-end si parlano tramite HTTP, quindi sul computer server ti serve un web server.

----

Al momento i moduli WASM sono invocati da 2 righe di codice Javascript. Cioe' nella pagina HTML devi mettere queste 2 righe Javscript per indicare al browser di caricare dal server di provenienza e di eseguire il modulo WASM.

[fairyvilje]

E' il futuro del Web perche' esegue codice 10/20 volte piu' veloce di Javascript che e' interpretato.

Una piccola nota. Non è il futuro del web perché nella maggior parte dei casi rompe totalmente gli strumenti di accessibilità. Ma è sicuramente utile per un buon gruppo di applicazioni che sarebbero comunque rotte perché basate su canvas, o per delegare computazione.
Anche la figura 10/20x è del tutto fuorviante. Javascript non è più esclusivamente interpretato da anni nei principali browser, ma soggetto a JIT compilation che lo rende molto prossimo ad avere prestazioni native, e lo stesso processo avviene per WASM. La differenza di performance fra Javascript e WASM è legato al fatto che Javascript ha tipizzazione dinamica, mentre la maggior parte dei linguaggi che hanno WASM come target no.

Detto ciò, concordo che in generale non sia possibile usare WASM nel contesto di una webapp senza gli altri elementi della magica triade :).

[boiler]

Grazie fairyvilje, ho visto il link a Crow, devo studiarmelo con comodo.

EnricoMigliore, attenzione a come quoti, stavo per saltare metà della tua risposta.

Per quel che riguarda WASM, evidentemente avevo un'idea sbagliata di come funziona. I stand corrected.

Boiler

[EnricoMigliore]

E' il futuro del Web perche' esegue codice 10/20 volte piu' veloce di Javascript che e' interpretato.

Una piccola nota. Non è il futuro del web perché nella maggior parte dei casi rompe totalmente gli strumenti di accessibilità.
Ma è sicuramente utile per un buon gruppo di applicazioni che sarebbero comunque rotte perché basate su canvas, o per delegare computazione.

Scrivere una WebApp in C/C++/C#/Java che gira nei browser di Smartphone e PC e' una grande traguardo.

Debuggare un'applicazione in C/C++/C#/Java e' decisamente piu' veloce di Javascript.

WASM e' stato creato dal W3C e non e' un prodotto Google o Microsoft o Apple. Questa cosa garantisce tutti.

Secondo me WASM e' il futuro del Web perche' permettera' di scrive applicazioni con esecuzione veloce della business logic e con UI basata su HTML e CSS.
Secondo me Flutter, Swift e MAUI non hanno scampo e andranno in pensione velocemente.


WASM permette inoltre di non esporre piu' codice sorgente Javascript ai client i quali vedranno solo codice binario.

Anche la figura 10/20x è del tutto fuorviante. Javascript non è più esclusivamente interpretato da anni nei principali browser, ma soggetto a JIT compilation che lo rende molto prossimo ad avere prestazioni native, e lo stesso processo avviene per WASM. La differenza di performance fra Javascript e WASM è legato al fatto che Javascript ha tipizzazione dinamica, mentre la maggior parte dei linguaggi che hanno WASM come target no.

Concordo con quanto scrivi. Javascript compilato con JIT ha delle ottime performance in velocita'.

[boiler]

Update: ieri sera ho provato Flask per la prima volta e forse potrebbe fare al caso mio.

Sul Raspberry avrei questi processi:

• gestione dei parametri in memoria: probabilmente un wrapper attorno ad un key-value dictionary con la possibilità di definire eventi "onChanged" e relativi callback
• business logic: funzioni che vengono chiamate da uno degli eventi del wrapper di cui sopra
• comunicazione con la MCU:
  • update MCU --> RPi: polling periodico iniziato dal RPi
  • update RPi --> MCU: iniziato da evento onChanged causato dalla business logic
• comunicazione con il client: webserver via Flask
  • update server --> client: probabilmente un Javascript sulla pagina che rinfresca i dati
  • update client --> server: tramite HTTP GET o POST

Vi sembra una soluzione accettabile o ci vedete dei problemi di principio?
Avrebbe il vantaggio di essere gestita completamente in un unico linguaggio/programma/processo. Che è anche il suo svantaggio (il linguaggio sarebbe Python ).

Boiler

[EnricoMigliore]

Flask promette bene. E' un micro framework per scrivere applicazioni Web totalmente in Python.

Se prosegui con Flask, tienici informati su come procede il lavoro.

[lelerelele]

EnricoMigliore devi limitare le citazioni al minimo indispensabile, non puoi citare l'intero messaggio, questo non è semplice da leggere ne utile oltretutto rende odiosa la pagina.

[claudiocedrone]

EnricoMigliore, leggi la guida all'uso del forum e il regolamento del forum (il regolamento peraltro lo hai accettato al momento della iscrizione quindi sei pregato di attenertici) per favore.