Backend e frontend junto ou separado?!

[Cleysonlb]

Pensando em arquitetura, o que faz mais sentido:

• Backend junto com o front, mesmo que o backend só sirva API para o front consumir
• Backend separado do frontend

Quais as vantagens e desvantagens?! 🤔

[ghost]

• Backend junto com o front, mesmo que o backend só sirva API para o front consumir

Tu tem que entender se teu backend vai ter só um dóminio no caso dessa aplicação. Se você splitar para microserviços fica difícil. Já que são vários endpoints as vezes até em dóminios diferente.

O principal problema desse modelo é escalar para outros domínios e também vários serviços. Porque querendo ou não fica um modelo monolitico.

Deploy também é uma dor porque se tu mexer só no backend, o frontend vai ter que subir.

• Backend separado do frontend

Aqui é flexibilidade, você pode tratar de diversos domínios. Você pode entrar numa arquitetura de microserviços. Ter uma app desacoplada traz vários beneficios, mas é verdade também que esse modelo te traz uma complexidade que vale a pena discutir em outra issue. Nesse modelo você pode trabalhar no modelo SPA enquanto teu backend funciona no modelo Funcional por exemplo. Ou seja tu traz uma arquitetura para o frontend, tu desacopla a arquitetura do backend pra usar o modelo que eles quiserem e etc.

Problema desse modelo, agora você traz pra tua vida uma complexidade que não era comum (microserviços, middlewares, arquiteturas de banco de dados e etc). Aqui uma virtude é te traz muito mais escalabilidade, mas com isso vem a complexidade.

Bom pra decisão de um ou de outro, imagine o seguinte: Tu tem que decidir se esse sistema vai crescer e tem que ver se tu tem maturidade pra trabalhar com diferentes arquiteturas. Porque na real definir a melhor arquitetura tu vai comprar o primeiro débito ai, afinal muitas coisas podem acontecer no meio do caminho.

Aqui onde trabalho trouxemos microserviço, trouxemos pequenas apps frontend ao invés de ser uma spa gigante, trouxemos docker, kubernets, diferentes data base, middlewares node, apis .net de diferentes domínios. Porque acreditamos que precisamos escalar muito e isso é uma característica. Não é por isso que diria a ti escolha esse modelo se tu precisa de um sistema de crud simples pra gerênciar vendas da tua loja virtual.

[sophiecalixto]

Muito bem explicado!

[CaetanoAlgaraque]

Ok, eu estáva a fazer tudo errado já backend ceparado é mas facil de gerir a propria app...

[ericvvf]

Posso estar enganado, mas não vejo muitas vantagens em misturar as camadas. Recentemente, iniciei um projeto MEAN, e uma das primeiras decisões que tomamos foi desacoplar o máximo possível front e back, coisa que não havia sido feita em projetos anteriores.

No nosso caso, uma das maiores motivações (além da organização, claro), foi a liberdade de pensar o lado Rest da forma mais genérica possível, independente de qual tipo de aplicação e dispositivos venham a consumi-la.

[lBrunol]

Eu tive essa dúvida recentemente. Estou desenvolvendo um sistema na empresa que trabalho e escolhi fazer o back-end como API e o front sendo uma SPA. Ou seja, estão desacoplados.

Antes de tudo, veja a necessidade do seu projeto. Faça perguntas como: qual é o tamanho? Precisa escalar? Será apenas para web ou também terá aplicativo? Qual é o tempo para desenvolver? Tenho prazo para usar uma arquitetura mais complexa?

Dito isso, aqui vão algumas considerações:

Back-end separado
Penso que é mais complexo, pois serão duas arquiteturas, a do seu Front, provavelmente uma SPA e a sua API. É bem provável que você leve mais tempo para desenvolver e consequentemente, custará mais dinheiro. Em contrapartida, você terá mais flexibilidade, pois poderá aproveitar sua API num APP ou até em outro site se for o caso. Os deploys também serão desacoplados, pode ser uma vantagem. Acho que é vantajoso usar isso numa aplicação complexa e com potencial para escalar.

Back-end acoplado
Aqui você vai levar menos tempo para desenvolver. Geralmente demanda menos conhecimento, já que você provavelmente não vai ter nenhum framework ou biblioteca de SPA. Esse cenário é interessante em um projeto com um grau de complexidade baixo e para projetos com um prazo e orçamento apertado.

[renzorodrigues]

Pessoal, tenho o frontend e backend separados. Como faço pra criar um repositório com os dois projetos?

[tcelestino]

@renzorodrigues, vc precisa criar uma "Organização" dentro do Github e na hora de criar um repositório, você "seta" qual organização ele faz parte.

[mahenrique94]

Com certeza separado é bem melhor, assim você ganha muito com escalabilidade, manutenção, organização, etc...

[diegopmendes]

Existe alguma regra de nomenclatura para os projetos? ex:

o front: projetoFront
o back: projetoBack
para deixar mais organizado?

[gabebarbosa]

Existe alguma regra de nomenclatura para os projetos? ex:

o front: projetoFront
o back: projetoBack
para deixar mais organizado?

Acredito que não exista uma regra, da forma que você colocou(projetoFront e projetoBack) já deixa bem clara a responsabilidade de cada um.
Hoje onde eu trabalho costumamos usar da seguinte forma:
meuProjeto.presentation - FrontEnd
meuProjeto.webservices - BackEnd

Já estamos acostumados a este padrão, é o padrão estabelecido pela empresa. Você(ou sua empresa) pode criar o seu.

[luanmarques1789]

Alguém teria algum projeto com frontend e backend desacoplados para exemplificar melhor a discussão?

[igorlvicente]

Digamos que você é uma costureira e vai começar a trabalhar por conta própria. Você, de início, financiaria um galpão de 1000 m2 com 3 máquinas de costura profissionais? Ou você começaria numa garagem com uma plaquinha improvisada?

Esse exemplo é só pra mostrar que o argumento de que "um dia vamos escalar" pode ser ilusório. Claro, todas empresas esperam ter milhões de acessos simultâneos, já que isso está atrelado ao sucesso do negócio. Mas na realidade, quantas realmente precisam?
Você acha que em quanto tempo você terá a quantidade de desenvolvedores que justifica o desacoplamento? 1 ano? 2 anos? 3 anos? Nunca?

Depende do que você quer. As vezes vale mais a pena começar com tudo acoplado e desacoplar depois, quando o negócio está dando dinheiro e você pode pagar um desenvolvedor mais habilitado pra lidar com as complexidades que virão com o desacoplamento.

[felquis]

Pessoal, criei uma discussão sobre um tema que acho que é relacionado a este mas um pouco mais "evoluído" talvez.

Compareçam aqui #2302 e deixem sua experiência!

cc @igorlvicente @luanmarques1789

[ghost]

Olá, pessoal.

Vantagens e desvantagens de um backend separado do frontend:

1. Em todo caso sempre divido backend/frontend. O motivo é simples: organização de código, maior segurança. Além disso, permite uma melhor arquitetura de microservices.
2. Disse organização de código, maior segurança. Gostaria de esclarecer como isso está relacionado, ao meu ver ao dividir o código em duas partes, você pode deixar somente uma equipe de ti responsável por somente aquele trecho de código: backed/frontend.
3. Acredito que isso também permite com essa divisão, uma melhor organização de código, haja vista que se há problema no backend será melhor analisado apenas com o código parcial ou completo para backend. Bem como, o mesmo para frontend - se há problema no frontend será melhor analisado apenas com o código parcial ou completo para frontend.
4. Isso não é bala de prata, isso dá maior complexidade ao código. Mas vale apena em 3 situações: 1) projetos de médio e grande porte. 2) melhor organização/segurança de código. 3) e se seu projeto não é monolítico, e sim somente sim microservices ou qualquer arquitetura que demande isso.
5. Sempre quando temos "organização/segurança de código", acaba que o código sempre fica complexo em qualquer projeto. E a divisão cada vez mais presente. Há quem divida: frontend em subcamadas (layout, components, design etc), há quem divida o backend em subcamadas(services, api etc) - Essa divisão acredito ser importante e relevante a 1) projetos de médio e grande porte. 2) melhor organização/segurança de código. 3) e se seu projeto não é monolítico, e sim somente sim microservices ou qualquer arquitetura que demande isso. Portanto, a menos que considere as coisas que disse acima, a divisão backend/frontend será boa. Em caso contrário, será ruim. Ressaltamos que, além disso pode leva maior complexidade, tempo de desenvolvimento e custo.

Vantagens e desvantagens de um backend junto com o front, mesmo que o backend só sirva API para o front consumir:

1. É fácil de manter inicialmente, o que é bom. Porém, quando novas funções/recursos etc são criados e mantidos, o código fica tão complexo que não dá para gerenciar de forma eficiente. Aí nesse caso, representa uma desvantagem.
2. Leva menos tempo para desenvolver.
3. Geralmente é mais utilizada em projetos monolíticos.

Notas gerais

1. Existem vários tipos de arquitetura de softwares. Cada arquitetura tem um ponto positivo e negativo. Isso sempre depende da equipe de ti, modelo de negócio e também na sua liberdade como desenvolvedor.
2. Sabendo disso, ao meu ver parece que quando a empresa de qualquer área não tem muito especialista, exemplo: "arquiteto de soluções", "arquiteto frontend" etc - geralmente nessas empresas trabalha-se muito com projetos monolíticos.
3. Empresas geralmente que tem área de especialização, quase sempre trabalham com coisas que não são monolíticos.
4. Por isso, disse que há liberdade como desenvolvedor. Geralmente, quando você trabalha em algum tipo de empresa, você as vezes é demandado para um frontend/backend acoplado ou separado. As coisas que disse, falei de modo geral e se eu estiver errado - corrijam-me. Sabendo desse ponto de partida, se onde você trabalha não há "arquiteto de solução", "arquiteto frontend" etc... você terá que fazer a arquitetura que será melhor gerenciada ou eficiente para sua equipe ou para você com divisão ou não. Se há, "arquiteto de solução", "arquiteto frontend" etc... - geralmente, você segue os padrões e arquiteturas existentes: divisão e/ou acoplada etc.
5. Agora se trabalha por conta própria, o melhor sempre é o backend junto com o front, mesmo que o backend só sirva API para o front consumir. Porém, a medida que seu projeto evoluí, outra arquitetura é necessária ou organização/segurança de código é pensada.
6. Espero ter esclarecido alguma coisa aqui.