Il mio prototipo di microservice attualmente ha un'applicazione MVC di avvio Spring come front-end. L'applicazione esegue il rendering della vista completamente nel back-end. Effettua chiamate di resto verso altri microservizi come OrderService o ShippingService dietro un gateway API. Scalare i micro-servizi dietro il gateway API non è un problema. Ma scalare il front-end MVC con una sessione non è così grande, immagino. Posso implementare Oauth2 e potrei impostare il fronted anche stateless!?
Vedo spesso esempi di architettura di microservizi con un JavaScript completo con front-end come Angular. È normale utilizzarlo con un client JavaScript nel browser? Quando dovrei utilizzare il rendering lato server e quando il lato client esegue il rendering con JavaScript?
Perché voglio utilizzare il rendering lato server: voglio rendere tutti i microservizi un sistema autonomo. Ogni servizio come un servizio di spedizione (risorsa) e l'OrderService (risorsa) hanno il proprio front-end lato server MVC Spring (che fornisce il lato e alcuni JavaScript per le chiamate di back-end solo relative a quel servizio). Quando OrderSerivce si interrompe, ad esempio, il servizio di spedizione è ancora completamente utilizzabile. Solo i collegamenti a OderService non sono inclusi perché il servizio non è disponibile.
Altrimenti, quando uso un portale web (applicazione Spring MVC) che fornisce all'utente il client JavaScript, avrebbe lo stesso comportamento, ma cosa succederebbe se il portale web fosse inattivo?
Che dire di tutto il codice JavaScript correlato a tutti i diversi microservizi? Ci sarà sempre una strong dipendenza o no?
Vorrei anche sapere se è meglio invece di aggiungere un'app MVC di avvio di primavera a ciascun microservizio se aggiungo semplicemente l'HTML a OrderService e fornisco un collegamento. Quando l'utente fa clic su di esso, il browser mostrerà la pagina HTML visualizzata da OrderSerice invece di avere un'API REST?