Best practice: inclusione delle chiamate URL endpoint in JavaScript e chiamate back-end

Naviga le tue risposte
1

Sto costruendo un'applicazione web che recupererà i risultati da un server remoto e li userà per rendere alcuni grafici e mappe. Il server remoto è già stato implementato e contiene una grande quantità di API, scritte in Java Spring Framework . Lo sviluppatore che li ha implementati mi ha dato accesso a un insieme di URL dell'endpoint non pubblici , che interrogherò e otterrò i risultati in formato JSON. Tieni presente che in un prossimo futuro alcune di queste API saranno sensibili e dovrebbero essere limitate solo agli utenti autenticati.

Da parte mia, sto sviluppando solo il frontend con ReactJS . L'intera logica dei calcoli, la manutenzione dell'utente, l'autorizzazione / autenticazione come anche l'input dell'utente, avviene sul server remoto tramite queste chiamate API.

Ora, la mia domanda è questa: dove è un buon posto per mettere le chiamate al servizio web? Per quanto mi riguarda, ci sono due opzioni:

  • Crea chiamate% co_de asincrone% nel codice AJAX esistente, che recupererà i dati richiesti e renderizzerà i grafici
  • Crea un secondo back-end, scritto in ReactJS framework, che eseguirà tutte queste chiamate API, isolandole in modo efficace (sono soggette a modifiche) dall'applicazione Django e fornendo un modo per "nascondere" in modo sicuro le informazioni per quanto riguarda gli URL effettivi da un potenziale intruso. Il backend "parlerà" con il mio frontend tramite una serie di chiamate, diverse da quelle del server esterno.

Il modo più semplice e veloce è seguire il primo approccio. Ma è una buona pratica avere chiamate API sensibili, che a causa della natura dell'applicazione sono soggette a modifiche in qualsiasi momento, nel codice ReactJS che è solo per il rendering lato client?

Avendo una seconda serie di chiamate nel mio back-end locale, mi è consentito disaccoppiare le API remote dalla mia applicazione, mantenerle più facilmente, cambiarle e proteggerle e rimuovere l'abilità da un utente finale di ispezionare il codice della pagina web e vedere gli URL effettivi in formato semplice.

So, naturalmente, che l'utente finale potrà vedere alcune chiamate API, ma sono più a mio agio nel vedere le mie API (entrare nel mio backend ), che dargli la possibilità di vedere (e forse usare) le API remote .

Ecco un semplice schizzo delle due alternative:

C'è qualche ovvio guadagno seguendo il secondo approccio o sto analizzando questo?

    
posta Lefteris008 06.03.2018 - 20:29
fonte

2 risposte

2

Un framework / linguaggio o qualsiasi altra tecnologia non ti salveranno. Con questo intendo che Django non è la tua unica opzione. Quello su cui dovresti concentrarti è la progettazione e l'implementazione della tecnologia con cui hai più familiarità (se questo non è solo un progetto personale). Tenendo questo a mente, proverei a rendere entrambe le estremità tanto indipendenti quanto possono essere. Ciò significa che ReactJS (o il frontend) non deve contenere dati, che non devono essere presentati all'utente.

Un approccio che penso avrebbe funzionato:

  • Crea entità JSON con cui le estremità anteriore e posteriore possono comunicare tra loro. Per esempio. {"query" : "give me something from the DB <NOT SQL>", "id":"random uuid"} con una risposta dal livello intermedio (leggi sotto) {"result" : "contains what you need", "id" : "uuid used before"} .
  • Crea il backend "secondo", che in realtà è un livello intermedio, che converte i tuoi dati nei dati contenuti nel modello dati esistente ed è responsabile della comunicazione del frontend e del backend esistente. Questo strato eseguirà il recupero dei dati, l'autenticazione degli utenti, gli eventi push, ecc.
  • Evitare di mescolare le responsabilità della presentazione dei dati all'utente e il recupero effettivo delle informazioni. L'ho già affermato, ma tieni presente che JS può essere sottoposto a debug nel tuo browser in modo che non desideri che i dati sensibili esistano lì.

Per quanto riguarda la comunicazione un'alternativa ad AJAX sarebbe websocket.

    
risposta data 06.03.2018 - 22:29
fonte
0

  1. Non stai facendo del lavoro extra per lo sviluppatore dell'API che dovrebbe aver posto al primo posto una solida sicurezza e autenticazione su un'API pubblica?

  2. La complessità e le modifiche dell'API possono anche essere incapsulate da una classe / servizio separato nel codice ReactJS stesso. Spostarlo su un altro server non ha alcuno scopo.

Queste due preoccupazioni, sicurezza e incapsulamento devono essere affrontate in diversi punti dello stack tecnologico.

    
risposta data 07.03.2018 - 14:51
fonte

Leggi altre domande sui tag

Memorizzazione di un ID di un carrello acquisti in un cookie per utente non autenticato Nell'architettura dei microservizi, è ragionevole che il servizio che emette l'evento lo ascolti?