P: Mas isso também significa que eu teria que colocar a lógica de negócios no front-end, no aplicativo da web Angular2, certo ?
Sim. Se não for suportado por um servidor, o negócio deve ser implementado em algum lugar.
Após a aquisição do Google, o Firebase evoluiu para se tornar uma plataforma para desenvolvedores de aplicativos móveis que não podiam pagar (ou não precisam) implantar seu próprio back-end. Embora a maioria dos serviços seja bastante transversal: serviço de armazenamento, login, análise e mensagens, é verdade que ele também fornece funções em nuvem (tipo lambdas) que podem ser usadas para executar algumas regras específicas de negócios. No entanto, para aplicativos corporativos ou aplicativos grandes com um domínio complexo e lógica de negócios, esse tipo de suporte é insuficiente.
Portanto, como você pode imaginar, o Firebase não nos exime de ter um back-end dedicado para hospedar e executar operações específicas de negócios.
P: Então, se algum dia no futuro eu gostaria de criar um front-end de aplicativo para dispositivos móveis, teria que duplicar o código da lógica de negócios?
Não necessariamente. Se o aplicativo da Web for desenvolvido no Angular, plataformas cruzadas como o NativeScript podem permitir que você reutilize os componentes da Web, bibliotecas, utilitários, modelos etc. Eu não me aprofundei no assunto, por isso não posso garantir sua total compatibilidade. A chave está no TypeScript , tanto Angular quanto NativeScript, exige que codifiquemos no TS.
A questão então é onde hospedar o Javascript para sua distribuição e versão . Uma palavra CDN .
P: Acho que a alternativa seria criar um back-end que contenha a lógica de negócios e use o Firebase para armazenamento de dados, mas isso parece um pouco estranho (eu não poderia simplesmente usar um ORM ou algo diretamente no meu back-end para obter o mesmo resultado sem muito mais trabalho?)
Algumas considerações.
Por um lado, hospedar, implantar, gerenciar e manter um banco de dados não é pouca coisa. Sem mencionar o manuseio de segurança, escalabilidade, disponibilidade etc. Portanto, é interessante ter um provedor de banco de dados cuidando dessas coisas. Hoje em dia, não é uma loucura ter nosso banco de dados em algum lugar da nuvem. Obviamente, eu não sugeriria isso se estivéssemos implementando o middleware e os back-ends de um banco. Mas poderia fazer sentido para a sessão do cliente, os perfis do usuário, as preferências e esse tipo de dados que geralmente residem no lado do cliente ou nos quais não nos importamos.
Por outro lado, ter nosso back-end é útil por uma razão simples: dissociar .
Em vez de conectar nossos clientes a todos os tipos de serviços que não gerenciamos e controlamos, implantamos um aplicativo do lado do servidor de onde cuidamos dessas coisas, para que nossos clientes não precisem se preocupar com problemas como interrupção ou interrupção de serviços alterar. Além disso, ganhamos simplicidade porque nosso back-end atua como uma fachada.
P: Como as pessoas geralmente estruturam esses tipos de aplicativos, se desejam usar o Firebase, por exemplo?
Varia amplamente de projeto para projeto. Por exemplo, usamos o back-end do Firebase +.
DB do Firebase para compartilhar dados entre dispositivos, contas e sessões . Também como um log de alterações, quando nosso back-end está temporariamente indisponível, os clientes enviam as operações de gravação para o log, que é sincronizado posteriormente.
O Firebase Cloud Messages nos fornece notificações e tópicos push up / downstream. Utilizamos o serviço para troca de mensagens de pub / sub.
Análise do Firebase Principalmente para métricas.
Back-end para tudo estritamente relacionado ao negócio