É design normal desacoplar completamente aplicativos da web de back-end e front-end e permitir que eles se comuniquem com a API REST (JSON)?

Estou criando um novo aplicativo Web de negócios e quero alcançar:

• Use as melhores tecnologias de seus respectivos domínios. Quero uma estrutura de back-end confiável com ORM sólido. E eu quero a estrutura SPA mais avançada (aplicativo de página única) com o uso dos recursos mais atualizados de HTML e Javascript para o aplicativo front-end
• Expor entidades de back-end e serviços de negócios para o uso de diferentes tipos de aplicativos - por exemplo, aplicativos Web, dispositivos móveis (Android) e possivelmente outros tipos (dispositivos inteligentes, etc.)

Portanto, para atender a ambos os requisitos, estou inclinado a separar completamente meu aplicativo em aplicativos de back-end e front-end e a organizar a comunicação entre eles usando a API REST (JSON). Esta abordagem é sólida?

Essa separação não é uma solução de design óbvia, porque muitas tecnologias de aplicativos da web possuem camadas de visualização integradas, nas quais o aplicativo do servidor controla mais ou menos a geração da visualização e manipula parcialmente as respostas da visualização (por exemplo, SpringMVC com camada de visualização, PHP Yii com visualização camada, o Java JSF / Facelets salva completamente o estado de seus componentes no servidor). Portanto - existem muitas tecnologias que propõem um acoplamento mais forte e prometem um tempo de desenvolvimento mais rápido e uma jornada mais padrão. Então - devo ser cauteloso ao começar a usar tecnologias de uma maneira que não é amplamente usada.

Pelo que entendi, o front-end do SPA completamente separado geralmente surge da necessidade de usar a API de terceiros. Mas é esse design de som dissociado quando o back-end e o front-end são desenvolvidos por uma empresa?

Atualmente, minha escolha de tecnologias é Java / Spring back-end e Angular2 / Web Components / Polymer para front-end - se eu puder dizer isso. Mas isso é irrelevante para esta questão, porque esta questão é sobre design geral e não sobre a escolha de tecnologias concretas?

É design normal desacoplar completamente aplicativos da web de back-end e front-end e permitir que eles se comuniquem com a API REST (JSON)?

Sim é normal. Mas isso é normal apenas se você precisar fazer esse tipo de separação e não forçar essa configuração em seu aplicativo geral.

Um SPA vem com alguns problemas associados a ele. Aqui estão apenas alguns que me vêm à mente agora:

• é principalmente JavaScript. Um erro em uma seção do seu aplicativo pode impedir que outras seções funcionem devido a esse erro de Javascript. Com as páginas veiculadas no servidor (SpringMVC, PHP, etc), você recarrega uma nova seção;
• CORS . Não necessariamente obrigatório, mas geralmente o back-end está em um nome de domínio diferente do front-end. Então agora você precisa lidar com questões de segurança do navegador;
• SEO . Você precisa disso? O seu site é público? O Google pode entender o Javascript e tentar fazer sentido para o seu site, mas você basicamente dá o controle a um bot e espera o melhor. Recuperar o controle pode significar ter que confiar em outras ferramentas como o PhantomJS .
• aplicação front-end separada significa projetos separados, pipelines de implantação, ferramentas extras, etc;
• a segurança é mais difícil de fazer quando todo o código está no cliente;

Claro, também existem vantagens no SPA:

• interaja completamente no front-end com o usuário e carregue apenas os dados necessários do servidor. Melhor resposta e experiência do usuário;
• dependendo do aplicativo, algum processamento feito no cliente significa que você poupa o servidor desses cálculos.
• ter uma flexibilidade melhor na evolução do back-end e do front-end (você pode fazê-lo separadamente);
• se seu back-end for essencialmente uma API, você poderá ter outros clientes à frente, como aplicativos nativos para Android / iPhone;
• a separação pode facilitar para os desenvolvedores de front-end executar CSS / HTML sem precisar de um aplicativo de servidor em execução em sua máquina.

Portanto, o problema é que existem vantagens e desvantagens em ambas as abordagens (SPA versus páginas do servidor). Gaste algum tempo pesquisando as duas opções e escolha com base na sua situação.

A resposta para sua pergunta é simples. Sim. O que você propõe é uma abordagem sólida . Mas então, o que eu acho que você quer perguntar é se é uma abordagem melhor e, infelizmente, nenhum de nós pode responder isso para você. Os fatores envolvidos abrangem muitas facetas que, sem divulgar tudo sobre a sua organização e os requisitos do produto, nenhuma conclusão real pode ser feita. Eu acho que você já sabe o que fazer de qualquer maneira.

Normal com ressalvas.

as estruturas javascript do front end são limitadas no que podem fazer. Se você criar APIs brutas para uso por vários aplicativos, elas geralmente exigirão algum processamento no servidor das chamadas de API brutas para exibir modelos que funcionam com esse aplicativo específico.

Portanto, uma arquitetura 'normal' pode ser:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Agora, se você tiver apenas um aplicativo da Web, poderá cortar a camada 'API expondo a lógica de negócios' e fazer com que o código da Web do servidor chame a lógica de negócios diretamente.

Como você separou a lógica de negócios em sua própria biblioteca, ela ainda é dissociada da lógica da interface do usuário e você sempre pode adicionar uma camada de serviço posteriormente.

Da mesma forma, como o serviço da API é chamado pelo código do servidor, você não tem comunicação http limitada. (embora isso seja praticamente universal agora)

Além disso, fazer com que o javascript chame o mesmo host do qual é veiculado significa que você não precisa mexer com cors