Copie o endereço para o front end do Vercel abrindo-o e olhando para a barra de endereços. Retornando ao Spring, adicione esse domínio às origens permitidas no controlador:
package com.example.iwreactspring.controller
//…
@RestController
@CrossOrigin(origins = "https://iw-react-java-part3-frontend-vizl.vercel.app")
public class MyController { … }
Agora, reconstrua o Spring e execute novamente. Você só deve fazer isso uma vez, mas é reconhecidamente desajeitado. Para melhorar a situação, poderíamos extrair o local de hospedagem do front-end do Vercel para uma propriedade e injetá-lo no controlador, para que não tenhamos que modificar o código se o local mudar.
Se você se deparar com o navegador desautorizando o certificado autoassinado, confira este recurso. A solução alternativa é dar ao navegador permissão para aceitar certificados autoassinados para o domínio da sua VM.
Por fim, você verá um aplicativo totalmente funcional que usa o MongoDB Atlas, uma máquina virtual do GCP e o Vercel para hospedar os três componentes, conforme mostrado aqui:
Figura 5. O aplicativo Spring-React-MongoDB em execução em produção.
Mateus Tyson
Conclusão
O maior atalho que tomamos aqui é em relação ao certificado autoassinado. Caso contrário, esses componentes estão todos em ambientes legítimos de hospedagem de produção. Claro, muito é desejável para operações contínuas limpas. Poderíamos dedicar atenção considerável para tornar esses componentes simples de implantar e testar e garantir lançamentos suaves.
A desvantagem dessa configuração são as chamadas de rede inerentes entre os componentes. Poderíamos reduzi-las auto-hospedando tudo dentro de nossa nuvem pública. No lado positivo, temos serviços altamente isolados em cada componente, suportando uma separação mais fácil de equipes, projetos e pipelines de implantação.