Sviluppo web Java

3

Ho iniziato a sviluppare applicazioni web non molto tempo fa, quindi per me ci sono molte cose sconosciute in questo campo. La mia domanda riguarda lo sviluppo web usando il linguaggio Java. Supponiamo di dover sviluppare un'applicazione client-server, in cui il client è un browser. Per quanto ne so, ci sono almeno due modi per comunicare.

  1. Un server HTTP funziona sul lato server e un contenitore per un'applicazione Java (back-end). Il server HTTP reindirizza le richieste a un'altra porta, che è associata con l'applicazione Java. L'applicazione Java invia alle pagine client con contenuto dinamico da un database, ad esempio, come risposta a una richiesta concreta del client. L'applicazione utilizza un modello enginge per questo. Timeleaf o Velocity, ad esempio.

  2. Un server HTTP invia solo file statici (pagine HTML, file CSS e Javascript) e inoltre un client inizia a inviare richieste asincrone al server utilizzando il codice Javascript. Le richieste vengono inviate tramite HTTP / HTTPS nel formato JSON (o XML). Questo approccio utilizza i principi REST. Un'applicazione server scritta in Java accetta queste richieste da una determinata porta, le elabora e invia le risposte nello stesso modo. Una pagina si aggiorna dinamicamente sul lato client, senza ricaricare.

Anche se ho scritto su Java, questi approcci sono usati con altri linguaggi di programmazione, ad esempio Python.

Mi è stato detto che il primo approccio è considerato negativo nella comunità Java. Ma non ho sentito argomenti concreti. Mi piacerebbe conoscerli.

Mille grazie per il tuo tempo e le tue risposte.

    
posta Sergey Gatich 02.08.2018 - 16:22
fonte

1 risposta

10

I dettagli di implementazione (cioè l'uso di Java) che stai descrivendo nella tua domanda sono meno importanti dell'architettura che stai cercando di descrivere, quindi permettimi di semplificare un po 'le descrizioni.

Ecco i due approcci, in poche parole:

  1. Il server Web invia pagine Web completamente popolate con dati al client. Questo approccio è chiamato rendering lato server
  2. Il server Web invia al client una pagina Web vuota e il browser Web richiede i dati dal server e inserisce la pagina Web con esso. Questo approccio è chiamato rendering lato client

Nessun approccio è "buono" o "cattivo". La differenza sta nel grado di interattività tra l'utente e il suo dispositivo che ciascun approccio consente. L'approccio che scegli (e in ultima analisi le tecnologie che utilizzi) dipenderà dai requisiti specifici del tuo progetto software.

Con il rendering lato server, l'interattività dell'utente è limitata ai post della pagina. Ogni volta che un utente inserisce i dati nella pagina Web, deve inviare la pagina al server in modo che l'applicazione possa procedere al passaggio successivo.

Con il rendering lato client, l'interattività viene espansa per includere le interazioni in tempo reale sulla stessa pagina. Un utente può inviare dati parziali e la pagina può richiedere aggiornamenti dei dati senza richiedere una nuova pagina. Questo approccio rende le pagine Web più simili alle applicazioni desktop e supporta lo sviluppo di più tipi di client (come i dispositivi mobili nativi).

Ma non tutte le pagine web hanno bisogno di questo livello di interattività. Se stai progettando una pagina di configurazione per un router o un altro dispositivo incorporato, ad esempio, è molto improbabile che utilizzerai il rendering lato client. Né la tua applicazione necessita necessariamente del rigore completo di un'infrastruttura di livello enterprise.

In passato, tutta la complessità della creazione di applicazioni Web era concentrata sul server. Ma le applicazioni web si sono evolute verso il rendering lato client per anni. L'eccessiva complessità è sempre stata un problema reale in questo tipo di applicazioni, ma ci sono alcune prove che le tecniche di sviluppo stanno diventando sempre più "standard" e che le applicazioni web stanno diventando più semplici e più potenti da sviluppare. Le cose che prima erano molto complicate (come l'associazione di dati e lo stile di pagina) sono diventate molto più semplici, perché ora sono disponibili ottime librerie Javascript in grado di eseguire molti lavori pesanti.

In breve, la tua scelta sarà basata su idoneità, non sulla nozione vaga di qualcuno di ciò che considerano "buono" o "cattivo".

    
risposta data 02.08.2018 - 17:06
fonte

Leggi altre domande sui tag