Utilizzo dei servizi REST: client o server

4

Sto lavorando a un nuovo progetto in cui stiamo attualmente decidendo quali tecnologie e framework utilizzeremo. L'applicazione alla fine sarà multipiattaforma. Pertanto, per il lato server, useremo un'API REST scritta in Java Spring.

Ora stiamo decidendo quale tecnologia useremo per l'applicazione web front-end.

Le opzioni sono le seguenti:

  1. Usando un framework javascript front-end (probabilmente userember js). Le pagine verranno visualizzate esclusivamente in JavaScript, tutte le richieste REST verranno inviate da Ember

  2. Utilizzo di un framework per server PHP (Laravel). Tutte le chiamate REST verranno effettuate da Laravel. Rendering della pagina lato server

La mia domanda: quale approccio è il migliore? E perché? Se optassimo per l'opzione 2 (usando laravel per fare le richieste), non sarebbe eccessivo usare Laravel perché lo useremmo solo per generare viste e fare le chiamate alle API REST? (tutta la logica proviene dall'API REST) Ciò che mi dà fastidio nell'opzione 1 è che il rendering verrà eseguito lato client, il che influirà sul tempo di caricamento iniziale. L'applicazione sarà ampiamente utilizzata anche dagli utenti con hardware di fascia bassa.

Qualsiasi input è benvenuto! Se hai altri suggerimenti o opzioni migliori, per favore fatemelo sapere!

    
posta Arnout 23.01.2016 - 22:16
fonte

2 risposte

7

Come spesso accade, dipende

Con un framework JS puro

  • si spinge molta elaborazione ai client. Ciò significa che il tuo server web per l'applicazione client servirà solo file statici che possono essere memorizzati nella cache.
  • i tuoi clienti devono essere in grado di gestire quell'elaborazione e hanno bisogno di un po 'di potenza di calcolo
  • i tuoi clienti devono supportare pienamente tutte le funzionalità JS utilizzate dal framework front-end e sono in qualche modo legate al supporto offerto da framework per i browser meno recenti. Se la versione più recente del tuo framework deciderà di abbandonare il supporto per alcune versioni di IE più vecchie su cui i tuoi clienti fanno ancora affidamento, sarai bloccato da questo.
  • gli endpoint dell'API REST devono essere accessibili da tutti i client che potrebbero essere un problema

Avere un livello intermedio significa

  • metti la potenza di elaborazione nel tuo singolo server, che è qualcosa che puoi controllare e, se necessario, aggiungere più risorse a. Per i clienti questo è più difficile e talvolta impossibile
  • hai la possibilità di controllare le chiamate all'API REST e, ad esempio, i dati della cache in modo da non dover colpire l'API ogni volta
  • hai più controllo sulla sicurezza poiché gli endpoint per l'API REST non devono essere pubblici
  • hai un controllo più preciso sull'HT reso e non sei legato ai componenti forniti dal tuo framework. È possibile creare un componente che inizialmente utilizza JS per creare parte di una vista e quando le prestazioni diventano un problema sostituirlo con HTML generato dal server
  • è necessario eseguire e mantenere un server con alcune funzionalità del linguaggio di programmazione lato server

La domanda è: quale di questi problemi è importante per te e quali no. Se hai l'esigenza di supportare hardware di fascia bassa, starei lontano dai framework front-end di JS. È molto difficile controllare le prestazioni in questo modo e tu sei molto limitato nelle ottimizzazioni che puoi eseguire.

    
risposta data 24.01.2016 - 11:03
fonte
0

Voglio aggiungere un punto a JDT da un'altra prospettiva.

In teoria, abbiamo un server ma molti client. Quindi, se mettiamo la logica del business fino in fondo nel lato server, non dobbiamo rifarlo per ogni client. Perché questo è il vero punto di un'API. Utilizziamo le nostre API per il web, Android, iOS e così via.

Tuttavia, se alcune funzionalità variano da client a client, inseriscile sul lato client.

    
risposta data 18.11.2017 - 16:35
fonte

Leggi altre domande sui tag