Non sono un "full stack developer" e mi ci tengo lontano qualche miliardo di chilometri.
Diciamo alla distanza del Big Bang (giusto perche' non si riesce ad andare piu' lontano) ;-)
COMUNQUE, ogni tanto mi e' capitato di implementare sitarelli web che sono, fondamentalmente, delle "applicazioni desktop" in versione web.
Giusto qualche pulsante, text area, combo box, tabellina, ecc.
Tiente di "fantasmagorico". Banale, banale.
.
Tra i tanti approcci, quello che ho trovato il piu' "pulito" e "concettualmente semplice" e' il seguente:
Single Page Application ( https://en.wikipedia.org/wiki/Single-page_application )
L'applicazione e' suddivisa in DUE parti TOTALMENTE distinte
- lato client
- lato server
.
Il lato client e' implementato in HTMP+CSS+Javascript, con l'aggiunta di qualche libreria aggiuntiva e qualche framework MOOOLTO basilare:
- jQuery: praticamente INDISPENSABILE ( https://jquery.com/ )
- JQWidgets: un sacco di componentini decisamente bellini per fare l'interfaccia utente ( https://www.jqwidgets.com )
- Backbone: framework per semplificare un po' l'implementazione del modello Model View Controller ( https://backbonejs.org/ )
.
In aggiunta, se devi fare dei diagrammini, ci sono librerie per il plotting "stratosfericamente carine". AL minimo D3.js ( https://d3js.org/ ).
Ma c'e' ne sono per tuti i gusti.
La parte interessante e' che piu' o meno tutte le librerie funzionano allo stesso modo. Quindi capita una, comprendere le altre diventa abbastanza semplice.
Mi tengo lontano da cose piu' complicate come Angular, React, Ember, ecc. Per quello che devo fare, non mi servono.
.
Il lato server lo puoi implementare in quello che vuoi.
L'implementazione consiste in un RESTFul Services Server.
SEMBRA una cosa complicata ma e' DECISAMENTE una stupidaggine:
devi avere un serverino web che risponde ad un po' di URL che accetta e ritorna dati in formato JSON.
Stop.
.
Diciamo che nel tuo caso, devi aggiungere un "Web Server" ad Access.
Di librerie .NET che implementatono Web Server minimali (che e' TUTTO quello che ti serve) ne trovi a camionate.
Il problema sara' trovare quello che puo' essere usato CON Access.
Al limite, fai in modo che sia il Web Server a chiamare Access, per fare le cose che deve fare.
Mi aspetto che la cosa sia "fattibile in modo semplice", anche se NON "in modo banale".
.
Quindi lo sviluppo dell'applicazione procede in questo modo:
- ti serve una funzionalita' lato client? fai l'implementazione che ti serve ed i dati li richiedi al server
- sul serve aggiungi una URL che viene chiamata dal client, gli vengono passati i parametri in formato JSON, fa quello che deve fare e ritorna il risultato in formato JSON
- il client rieceve il risultato in formato JSON e fa quello che deve fare
.
Hai DUE sviluppi SEPARATI ma che implementi in modo "organico".
E, COSA FONDAMENTALE, li puoi testare SEPARATAMENTE, in modo abbastanza semplice:
- il server lo testi con il browser
- il client, anche, MA quando deve richiedere dei dati al server, puo' semplicemente chiamare una URL che ritorna sempre lo stesso file JSON che ti sei preparato per il test.
.
Ora, da nessuna parte c'e' scritto che il RESTFul Services Server debba fare cose piu' complicate che non ritornare file HTML, immagini o file di testo/file CSV.
MA, filosoficamente, se hai un'applicazione WEB, DEVI ragionare in questi termini: client & server.
.
Diventa alquanto "incasinato" procedere quando devi far condividere nello stesso momento la parte client con la parte server, cosi' come si fa un PHP, con le JSP in Java, in ASP.NET, ed in n-mila altri casi.
.
WordPress lo lascerei perdere: e' come sparare con un obice da 150mm ad un moscerino :-)
.