Métodos de separação de front-end e back-end com javascript de pilha cheia?

Suponha que eu tenha um front-end, que é principalmente um aplicativo de página única, escrito usando angular, grunhido e caramanchão. E suponha que eu possua um back-end, que na maioria das vezes é apenas uma API REST em cima de um ORM, que armazena / recupera objetos de um banco de dados, usando coisas como grunhir, expressar e sequenciar.

O aplicativo angular faz todo o material visual que o usuário vê, mas faz isso por ser uma GUI sobre os serviços fornecidos pelo back-end.

Seria desejável separá-los em duas bases de código diferentes, para permitir desenvolvimento independente, versionamento, integração contínua, push to development, etc.

Minha pergunta é: quais métodos existem para fazer isso de forma limpa? Existem práticas recomendadas para javascript de pilha completa?

A opção 1 parece ser um monólito, ou seja, "não os separe". O profissional é que a cadeia de construção é simples e tudo está em um só lugar - mas parece haver muitos contras; mais difícil de versão independentemente, uma frente quebrada significa uma traseira não implantável e assim por diante.

A opção 2 parece ser um quase-monólito, em que a cadeia de criação do front-end resulta na gravação de vários arquivos no back-end. O distdiretório no front-end se referiria a algum diretório no back-end, portanto, essencialmente, quando o front-end reduz, uglifica, etc, acaba publicando no back-end, que executa tudo.

A opção nº 3 parece ter separação total: o front-end e o back-end executam seus próprios servidores em portas diferentes e são projetos totalmente separados. A desvantagem parece que eles precisam ser configurados para conhecer as portas um do outro; o back-end deve permitir o CORS a partir do front-end e precisa saber onde todos esses pontos de extremidade devem estar.

A opção 4 pode ser usar algo como docker-compose para montar a coisa toda.

Tenho certeza que existem outras opções. Qual é a melhor prática recomendada?

É um aplicativo front-end, back-end, com uma interface REST no meio. Você já tem separação completa.

Meu voto é para a opção 3. Você parece preocupado com a configuração, mas esse é o ponto principal. A configuração permite que você tenha uma separação completa sem precisar de ligações de código fortemente acopladas. Se você está preocupado com o CORS, coloque tudo em um domínio. Se você precisar do CORS, a melhor maneira de gerenciar isso é uma configuração.

Mas não há "boas práticas" aqui. A melhor prática é aquela que melhor atenderá às suas necessidades específicas.

Sim, você deve separar os dois e tratar o aplicativo front-end como um aplicativo de terceiros - você pode adicionar outro cliente, um aplicativo móvel, por exemplo, e se o primeiro cliente tiver sido construído dessa maneira, sua vida será mais fácil.

O uso de contêineres de docker ou outro sistema de implantação pertence principalmente ao back-end, pois o front-end do seu aplicativo são apenas ativos estáticos que precisam ser resolvidos. Você pode hospedar esses ativos estaticamente em seu servidor ou em outro lugar como uma CDN como a cloudfront.

Evitar cors economizará uma configuração Little, mas, como a resposta acima mencionada, esse é o tipo de questão. O uso de cors (e autenticação de token) também preparará melhor o seu back-end para outros clientes.

Editar: no que diz respeito às práticas recomendadas de pilha cheia js - eu diria apenas isso, seja consistente. Se você estiver usando promessas (e deveria), faça-o dos dois lados. Mantenha o mesmo estilo e formatação js, ​​use as mesmas bibliotecas de teste (sempre que possível) etc.