it-swarm.it

Vantaggi / svantaggi delle applicazioni web "separate"

Sono in procinto di progettare un'applicazione Web PHP/MySQL (che sarà presto disponibile) piuttosto grande. Sono arrivato a un bivio per quanto riguarda l'architettura interna; Posso creare il sito Web come un'applicazione Web "tradizionale" in cui, quando si effettua una richiesta, il server crea una pagina HTML, ti invia l'intera pagina e il browser la rende, oppure posso costruirla come "separata" "applicazione Web in cui l'intera struttura HTML e il codice dell'applicazione vengono forniti al browser al caricamento iniziale e l'applicazione utilizza i callback JavaScript per ottenere dati specifici o inviare comandi tramite un'API unificata. Inoltre, intendo che ci siano più versioni del sito (desktop, mobile, iPhone/Android mobile, motore di ricerca compatibile, ecc.) E ad un certo punto, forse anche app mobili o desktop indipendenti.

Quali vantaggi/svantaggi hai, come sviluppatori web, con ciascuna di queste architetture? C'è un chiaro motivo per cui dovrei andare l'uno sopra l'altro? È più una preferenza per gli sviluppatori?

3
Adam Maras

Prima di tutto, se vai su un sito Web pesante asincrono o meno, non influirà molto sulla tua capacità di creare app per iPhone/Mobile e desktop perché non ha nulla a che fare con loro. Ad ogni modo non sarai in grado di riutilizzare il tuo codice.

Inoltre, i siti asincroni possono essere altrettanto lenti o più lenti dei siti normali. Di solito, questo tipo di funzionalità viene aggiunto per un motivo, in particolare per un'esperienza utente arricchita. L'uso di JavaScript tende a farti del male sul SEO perché i webcrawlers non riescono a comprendere appieno l'intento del JavaScript e quindi lo ignorano principalmente.

Penso che quello che stai cercando sia un modo per ridurre il sovraccarico di sviluppo scrivendo il tuo livello funzionale (intermedio) una sola volta e usando lo stesso per tutte le tue app. In questo caso penso che ci sia valore, ma francamente questi tipi di architetture sono più difficili da configurare e richiedono molto tempo. Sarei dell'opinione che dovresti sviluppare il tuo sito web nel miglior modo possibile e mantenere il tuo codice di livello intermedio più forte che puoi. In questo modo quando arriva il momento di aggiungere un'app per iPhone o qualsiasi altra cosa sarai in grado di passare a un modello con un livello medio comune più facilmente

Quello che sto davvero sostenendo qui è fare piccoli passi. Non provare a scrivere codice ora per gestire cose che non conosci ancora. Scrivi il codice che ti serve e rendilo il più flessibile possibile.

4
Ben Hoffman

Penso che l'idea di un'applicazione "separata" che si basa fortemente su JavaScript/AJAX ti metterà nei guai. Alcune cose dalla cima della mia testa:

  1. Sarebbe un male per il SEO poiché Google avrà difficoltà a indicizzare qualcosa.
  2. Sarà difficile renderlo "segnalibro"
  3. Ti divertirai con i dispositivi mobili poiché molti di loro hanno un supporto javascript molto limitato (o rotto).
5
Eric Petroelje

In primo luogo, senza offesa se questa risposta è troppo ovvia o di base. L'uso di "separato" anziché di termini come Ajax o jQuery mi fa presumere meno esperienza con questo argomento. Ovviamente potrei aver letto male la domanda, quindi mi scuso se è così.

Usa entrambi, ma saggiamente

Pensa alla tua scelta di attività lato server o lato client in termini di dove e come un'attività viene eseguita in modo più efficiente. Questo ti aiuterà a renderizzare rapidamente le pagine (sul server), ma scarica il lavoro sul browser dove ha senso farlo. E ci saranno aree grigie in cui devi solo fare una chiamata di giudizio. Il tuo compito è trovare una divisione intelligente del lavoro.

Cosa appartiene al lato server?

(Questo è un esempio estremo per illustrare il punto.) Supponi di scrivere un'app Web che esegue un certo tipo di ricerca. Non si scrive Javascript sul lato browser per chiamare un servizio Web PHP sul lato server per recuperare un intero database da 2 GB per "liberare il server" e scaricare la ricerca sul computer dell'utente. Quello che fai è ottenere i termini di ricerca dall'utente con un modulo, POST tornare al server per interrogare direttamente il database, quindi inviare i risultati dal server al browser.

La logica qui è che il DB stesso sa come eseguire al meglio la query, il server è più vicino ai dati di origine e meno dati devono essere spostati tra i componenti. Il browser richiede solo ciò che viene visualizzato, quindi non inviarlo tutto al browser. (Per non parlare delle prestazioni linguistiche relative.)

Cosa appartiene al browser?

Il codice lato browser è il tuo scenario "separato" (se ho capito bene). Ma affinché il browser possa fare quasi tutto in modo intelligente, deve avere una collaborazione server.

Ok, hai la tua app di ricerca funzionante ma vuoi abbellirla con alcuni pantaloni fantasia Ajax. Scrivi un servizio web PHP per prendere alcune lettere e restituire i termini di ricerca corrispondenti, alla la funzione "suggerimento di ricerca" di Bing , Google, ecc. Scrivi il codice del tuo browser per suggerire i termini solo dopo che l'utente ha digitato tre o quattro lettere, quindi l'elenco dei suggerimenti è piccolo. Di nuovo sul server, indicizza il tuo database su quel campo in modo che la ricerca sia veloce, veloce, veloce.

Qui il pensiero è che "suggerimento di ricerca" è una funzione che deve essere suddivisa tra il server e il client. Il browser può gestire rapidamente pile di dati mirati e di dimensioni ridotte. Il server può ottenere quel mucchio di dati mirato e di piccole dimensioni e fornirli al client. Una divisione scadente sarebbe per il server di rendere un elenco di mostri (per esempio, 500.000 articoli) di possibili valori di campo come isola XML incorporata nella pagina HTML, quindi fare in modo che il browser lo cerchi mentre l'utente digita. (a) l'invio di tutti i dati al browser è lento, (b) la ricerca in Javascript non sarà mai mai veloce come consentire al DB di cercarli, e (c) è probabile che tu faccia esplodere la macchina di un utente stipando tutti quei dati nello spazio dell'app del browser. D'altra parte, è necessario accertarsi che la chiamata Ajax al server e la successiva query e restituzione siano superveloci. Nessun diligente in giro.

Dov'è l'area grigia?

Anche in questo caso è una chiamata di giudizio. Sopra, ho parlato del server che esegue la ricerca, quindi invia i risultati al browser. Tuttavia, sorge la domanda: si consente al browser di inviare i termini di ricerca con il modulo e si fa in modo che il server visualizzi la pagina dei risultati o si utilizza Ajax/Javascript sul lato client per inviare i termini di ricerca e recuperare i risultati, quindi renderli in un DIV per evitare un aggiornamento della pagina? Entrambi sono validi Per quanto riguarda le risorse, non c'è nessun vero vantaggio in entrambi i casi. Il modo Ajax può fornire un'esperienza utente migliore ma, a seconda della tua app e delle circostanze, potrebbe presentare alcune altre sfide (ad esempio sicurezza).

Linea di fondo

Utilizzare entrambi in modo appropriato. Non lesinare sul pensiero e l'apprendimento delle prestazioni e dell'efficienza dell'architettura. Sposta meno dati, meno volte. Ti toglierai un carico dai server, dai database e dai browser degli utenti.

2
b w

Per poter riutilizzare il codice, puoi sempre guardare XSLT per la generazione di landing page e quindi avere interfacce XML/JSON per AJAX (utilizzando l'interfaccia XML per le landing page XSLT).

Normalmente permetteresti che il contenuto e l'interazione funzionino su un'interfaccia RESTful con un prefisso/json/... e/xml/... e Ospita il tuo contenuto principale, convertito in mark-up tramite XSLT su/...

In questo modo le persone possono atterrare su qualsiasi pagina e improvvisamente avere l'intero sito Web AJAX. I ragni possono eseguire la scansione del tuo sito e ti sei concentrato innanzitutto sul contenuto/sulle interfacce - sembra una vittoria/vittoria.

I siti Web mobili a volte hanno bisogno di layout diversi (siti su misura per iPhone solo per chiunque?) Una semplice conversione XSLT qua e là per clienti di utenti diversi può riutilizzare tutto ciò che hai fatto finora.

Ricorda di progettare per un semplice output HTML e navigazione, possono seguire le semplificazioni AJAX.

PS - Esegue il lato server di trasformazioni XSLT

1
Metalshark