Temos um web-service, o(s) frontend(s) para o qual é dividido em vários aplicativos que são entregues por endpoints cloudfront. Atualmente, todos eles têm seus próprios subdomínios, como, por exemplo, service-a.mydomain.com, service-b.mydomain.com, etc.
No entanto, subdomínios quase não têm impacto em como o Google estabelece autoridade de domínio atualmente, e a autoridade de domínio se tornou o Santo Graal do SEO. Então, para fins de otimização de mecanismos de busca, queremos mover tudo para um caminho em um domínio de nível superior. Então, depois, deve ser meudominio.com/serviço-a, meudominio.com/serviço-b etc.
Obviamente, isso parece exigir um proxy, como um gateway de API ou algo assim, para rotear tudo. O problema com isso é... bem, se tudo passa pelo mesmo proxy, então as principais vantagens do cloudfront (ou qualquer outro CDN) praticamente vão por água abaixo. Claro que você pode executá-lo por trás do proxy, mas tudo o que você tem então é um cache. Adeus, edge locations. Nesse ponto, faria mais sentido ter o cache no próprio proxy, realmente.
Então, minha pergunta é: ainda há alguma maneira de usar os locais de borda do cloudfront se eu não puder dar a cada ponto final seu próprio subdomínio? Ou essa forma de design de domínio simplesmente requer abandonar as vantagens de uma CDN?
Eu olhei como a própria AWS está fazendo isso. Afinal, eles têm uma vasta gama de aplicativos frontend, todos entregues de um subdomínio regional, então eles devem ter o mesmo problema.
A resposta, ao que parece, parece ser entregar um arquivo HTML do domínio real, que carrega todos os seus ativos (css, scripts, fontes etc.) por meio do CDN. Então, basicamente, apenas entregar a página de título do domínio real, enquanto todo o resto do site entra furtivamente pela porta dos fundos.
No nosso caso, os aplicativos frontend são escritos em angular, o que traz alguns desafios para conseguir isso, mas funciona.