Sviluppo web lato client: gestione dell'autenticazione durante lo sviluppo

Tutti i codici angolari possono essere serviti come file statici? Se il front-end può essere servito in questo modo, puoi creare un semplice web server per servire file statici.

Per il back-end, dipende dal tipo di risposte API necessarie per lavorare su angolare. Se riesci a prendere in giro le risposte servendo file JSON statici, allora lo fai semplicemente. Per ogni risposta API necessaria, creare un file JSON con alcuni dati di esempio e servirli come file statico con una risposta di 200. Se è necessario un endpoint di autenticazione per restituire un token per simulare un "flusso di accesso", è sufficiente restituire un token non senso.

Ideally, I would like for us to have a "development" flag that we turn on so that we can merrily go about developing on our local machine without dealing with configuring back-end services that aren't really required in order to perform general coding.

Ok. Vai avanti!

Nei miei progetti, ho fatto varie cose, a seconda delle necessità. Abbiamo sollevato copie di sviluppo delle nostre API, sempre disponibili. Abbiamo creato mock di servizio lato client, API client complete che persistono nell'archiviazione locale. E abbiamo creato proiettori davvero sottili, risposte statiche per ogni metodo.

Dipende interamente dalle tue esigenze. Fai quello che devi fare per essere efficiente senza perdere la fedeltà con i tuoi servizi attuali. Le uniche risposte sbagliate sono quelle che non funzionano o portano a rotture nel tuo ambiente di sviluppo.

Un possibile approccio: avere un server che serve tutte le funzionalità che non necessitano di autenticazione, cioè non ha contenuto per utente. Assicurati che il tuo firewall non ne consenta l'accesso esterno. Aggiungi regole al tuo server pubblico che ne fa un proxy inverso al server interno; assicurati che sia disponibile solo per gli utenti autenticati.

Un altro approccio possibile: rendere le pagine del modello pubbliche. Metti tutto il contenuto che richiede l'autenticazione nei servizi web, chiamato da richieste AJAX che utilizzano un token AUTH.

O accedi alle partizioni dell'app in una parte pubblica e a una parte sicura.

Un modo in cui ho visto questo fatto è usare qualcosa come Swagger per documentare prima l'API. Swagger ha un numero di client fittizi che sono facili da usare e che fondamentalmente si basano su serrvizi fittizi basati sulla progettazione dell'API. I giocatori finiscono male e quelli di back-end scrivono codice server che soddisfa (ed è testato contro) lo stesso contratto e poi ad un certo punto si integrano i due. Ma l'integrazione sta semplicemente cambiando l'URL dal server mock locale al server reale.

Inoltre, sembra che tu non stia usando alcun tipo di strumento di costruzione clientide (es. webpack). Ci sono molti buoni motivi per usarne uno, ma uno di questi è essere in grado di fare build che variano in base all'ambiente.

Ho lavorato a progetti che mischiano servizi web tra servizi condivisi (come l'autenticazione) e i servizi specifici su cui avevo bisogno di lavorare. I servizi che le applicazioni devono interagire con tutti devono essere configurabili.

Supponiamo che tu stia lavorando alla schermata di controllo del carrello e che devi anche lavorare sul servizio web di pagamento.

Quindi configurate l'app Angular locale per effettuare una chiamata a un servizio di autenticazione di sviluppo condiviso (ad es. auth.dev-api.company.com). Quindi configuralo per accedere al servizio web di pagamento locale (ad esempio localhost / api / pagamenti).

Quindi la tua app AngularJS locale invia richieste di autenticazione a auth.dev-api.company.com, ma le chiamate al servizio web di pagamento colpiscono localhost / api / pagamenti.

Fondamentalmente, gli URL per ciascun servizio Web devono essere configurabili in modo da poter utilizzare i servizi Web "condivisi" per le cose che non ti interessano e utilizzare i servizi web locali in esecuzione su localhost per i pezzi effettivamente necessari modifica o debug.

L'ho gestito in modi diversi a seconda di cosa era "richiesto" e di cosa era "bello avere" per poterlo sviluppare. Come hai identificato, a volte non ti interessa solo far ruotare tutte le diverse parti e pezzi per alzare l'app in modo da poter controllare una correzione CSS. Il modo in cui lo gestisci dipende dal tuo ambiente.

Configurazione per l'utilizzo dei servizi esistenti

Se si dispone di un ambiente di sviluppo / test stabile con i servizi richiesti, può essere facile modificare semplicemente il file di configurazione per utilizzare tali servizi. Perché attivare la propria versione dell'API che non è cambiata da mesi quando è possibile utilizzare la versione identica sul server di sviluppo? Ciò si basa sulla stabilità di tali cose e sulla possibilità di accedere a tali servizi. Alcuni servizi non saranno disponibili in questo modo, quindi potrebbe non funzionare.

Un'altra opzione sarebbe installare IIS / Apache / etc localmente e configurare i servizi appropriati per essere sempre pronti. Quindi non devi mai preoccuparti di avviarli ogni volta che vuoi sviluppare. Sono lì solo ad aspettarti quando ne hai bisogno.

DI

Se non è possibile utilizzare i servizi esistenti, se si dispone di una buona iniezione di dipendenza, è possibile sfruttarla. Una volta abbiamo dovuto fare alcuni test di una pagina web del carrello. E volevamo eseguire test automatici che avrebbero dovuto colpire l'API del gateway di pagamento solo per ottenere una risposta in modo che il codice potesse proseguire. Ma il nostro server CI è stato siloedato in modo tale da non poter accedere a tali API. Quindi abbiamo usato alcuni trucchi di configurazione e DI per utilizzare alcune classi di API di pagamento test / simulate. (Dato che testare l'API di terze parti non era la parte importante del test, andava bene.) Abbiamo appena soppresso una classe che restituirebbe una risposta "abbastanza buona" per il nostro codice. Se possibile, potresti essere in grado di disattivare un servizio di accesso di autenticazione fittizio che restituisce sempre una buona risposta solo per lo sviluppo.

Rendi tutto più semplice

Sugli altri progetti, prendere in giro cose con DI non era un'opzione praticabile e non c'erano opzioni davvero buone per l'utilizzo dei servizi test / server di sviluppo. In quei casi abbiamo trascorso un po 'di tempo a rendere più semplice l'impostazione. In un progetto abbiamo creato un contenitore Docker che avremmo potuto avviare e che avrebbe avviato tutti i piccoli servizi di cui avevamo bisogno. Un comando di shell veloce, aspetta un po 'per l'avvio e BAM, tutto ciò di cui avevamo bisogno. In un altro progetto, abbiamo appena scritto uno script di shell per avviare solo i progetti / i siti web / gli ex appropriati. Questo è il tipo di soluzione a forza bruta per cui non esiste un'alternativa migliore. Funziona quando non puoi sfruttare altre tecniche.