Eu acho que a pergunta está errada.
Todas as startups em que participei não tinham uma arquitetura única FE-BE.
A maioria das startups que conheço tem:
- Principal - o produto real que expõe uma interface
- UI - BE e FE. O BE usa a API do núcleo.
As APIs são apátridas e facilmente zombadas - mesmo sem a necessidade de um desenvolvedor principal. Inferno, se eu tivesse que iniciar um projeto do zero, poderia começar com uma interface do usuário inteira que funcionasse apenas com zombarias - o que será ótimo para apresentações. A maior parte do feedback é devido à interface do usuário. Os clientes observam que mais - (depende do seu público-alvo).
Por exemplo - a Pesquisa do Google tem o componente Principal que rastreia a web, indexa-o etc. A interface do usuário do Google é um mundo totalmente diferente. Esse núcleo pode suportar facilmente pesquisas que não são da WWW, enquanto a interface do usuário não.
Dessa forma, sua interface do usuário é "conectável" e você tem uma separação de preocupações.
Você se referiu ao conhecimento de desenvolvimento, mas está negligenciando os aspectos de gerenciamento de projetos. Embora a equipe principal possa precisar de duas semanas de duração do sprint, a equipe da interface do usuário usará o IC - tudo é carregado o tempo todo. A equipe principal precisará de compatibilidade com versões anteriores, enquanto a interface do usuário não.
O idioma é diferente. Você provavelmente desejará desenvolvedores C para o componente Core - e ficará bem se for executado em um único sistema operacional, onde a interface do usuário será gravada em uma linguagem Cross OS.
Os testes diferem. O mundo dos testes de interface do usuário é um dos mais complexos que conheço no desenvolvimento de software. A maioria das startups a negligencia e se arrepende dessa decisão posteriormente. Você não pode separar BE e FE durante o teste. Tem que ser uma única unidade que lide com isso.
Interface do usuário de código aberto - um dos maiores benefícios da separação dos dois é que você pode abrir a interface do usuário de código-fonte aberto. O projeto de interface do usuário precisa de suporte de código aberto.
Não consigo imaginar um desenvolvedor de interface do usuário que não entenda todo o session
recurso. Você sabe - onde você faz login e permanece conectado entre diferentes solicitações. É verdade que eles podem conhecer PHP e não Java .. mas o conceito BE deve ser claro (por exemplo, use um cookie criptografado). A barreira específica do idioma está errada - todo desenvolvedor deve estar disposto a trabalhar em qualquer idioma. Quem pensaria que escreveria BE em JavaScript alguns anos atrás?
Se você continuar com três equipes: Core, BE e FE, será um desperdício de recursos. E o DB? você deveria ter DBAs? Por que um desenvolvedor de BE conhece DB e um desenvolvedor de FE não conhece BE e DB? Não há limite.
Se você precisar de especialistas, e precisará, terceirizá-los funciona muito bem. Eles geralmente entregam código de qualidade e o fazem muito rápido. Você não necessariamente os quer internamente, porque se perderá se eles forem embora. Além disso, você pode obter ótimos conselhos on-line hoje. Material de ponta pode exigir uma abordagem diferente.
Portanto, o resultado é basicamente um BE muito fino na interface do usuário que todo desenvolvedor de EF pode desenvolver. Se você tem um BE espesso na interface do usuário, provavelmente possui algumas funcionalidades de API necessárias no Core.
Sempre há pelo menos um desenvolvedor que se destaca dos demais. Dado um FE tão fino, ele pode gerenciar dando suporte (não desenvolver) outros desenvolvedores no código BE. Minha opinião é que esse desenvolvedor está em uma posição muito boa e deve ser concedido adequadamente (embora não seja o salário, outra coisa). Também confio que eles serão capazes de lidar com o processo de compilação e compilar corretamente.
Este modelo oferece uma grande flexibilidade em relação ao desenvolvimento do BE. O mundo do BE sofreu várias reviravoltas nos últimos dois anos, por isso não recomendo confiar demais na estabilidade do BE. O núcleo é uma história diferente.
Ainda resta a pergunta - FE e BE devem ser o mesmo projeto ? Você deve observar o seguinte
- Os recursos estáticos são mais bem servidos no servidor frontal. Como os servidores Front-End (por exemplo, nginx) são muito poderosos e como você pode usar o Cache para recursos estáticos, é possível gerenciar com uma única implantação dos seus recursos estáticos (que devem ser todo o conteúdo HTML, JS, CSS, Imagens).
- O código de back-end não possui os mesmos luxos; portanto, você deve ter um sistema distribuído - que também é gerenciado por um servidor front-end.
- O código FE deve ser reutilizado com todas as novas tecnologias que suportam JavaScript. Agora você pode escrever aplicativos para desktop e dispositivos móveis com JavaScript.
- O processo de compilação é completamente diferente - e pode até incluir entrega, atualização, instalação de patches etc.
Posso continuar, mas espero que fique claro que BE e FE devem ser a mesma equipe, mas talvez projetos diferentes.
if you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best.