Consegui sim Thiago, agora sou eu que vou tentar me expressar bem :)
Angular2 é um framework para criação de SPA que nada mais é que uma página que não recarrega durante o uso e se assemelha muito a uma app. No caso do Angular, ou melhor, no caso das SPA's, as empresas tem interesse nesse tipo de aplicação porque ele favorece a separação da camada de apresentação (o que roda no navegador) dos dados, ou melhor, da API de um sistema.
Sendo assim, se eu uso Angular, eu posso usar no backend Java, C#, Php ou qualquer outra tecnologia, porque não estou amarrado a uma tecnologia de View no servidor. No caso do Zend, a view é gerada no servidor e enviada para o cliente, sendo assim, no servidor você esta amarrado a usar PHP. E se quiser trocar para Java? Terá que usar outra tecnologia para criar a view (o front) específica do Java.
Veja que com uma separação total entre o front e o backend, a empresa pode ter um backend em Java, inclusive em Php que devolvam JSON usando o padrão REST. Como o REST é um padrão que roda encima do HTTP, podemos acessar API's rest de qualquer lugar, seja de uma SPA ou de uma aplicação em Google Android.
Então, eu posso ter uma equipe que cuida da parte de view, do frontend, no caso, uma equipe que toma conta da APP feita em Angular e outra tomando conta da API. Quem cria a API não quer saber quem vai acessa-la, pois qualquer aplicação com acesso permitido pode consumi-la.
Veja que isso é bem diferente do Zend. Lá, seu servidor pega os dados do banco e monta a página que é enviada para o cliente. Mas se fosse uma aplicação Android que estivesse interessados nos dados para exibir para o usuário? Devolver uma página HTML não ajuda porque sua API esta amarrada com uma apresentação. Se ela devolve apenas dados, quem receber escolhe o que vai fazer com ela.
Outro ponto legal do Angular2 é a facilidade em criar componentes. O reuso de código é interessante e com o tempo você vai criando seu próprio conjunto de componentes para auxiliá-lo no dia a dia ou baixar módulos de terceiros com essa ou aquela funcionalidade que você busca.
Sendo assim, o deploy (colocar a app no ar) de uma aplicação Angular é em separado do deploy da API. Ambos tem que ser autônomos e um não deve depender do outro. Se o deploy do Angular é feito com a API, se precisar mudar a app Angular terá que parar sua API e se ela for consumida por outros dispositivos móveis como um Android vai comprometer seu acesso.
Mas nada impede de você fazer o deploy dos dois juntos, aliás, é algo comum em aplicações de pequeno porte, inclusive médio. Mas se você for criar aquela app que pode crescer muito o ideal é fazer o deploy em separado.
Sobre o Node.js. O Angular 2 só precisa do Node.js em tempo de desenvolvimento. Entenda o Node como a ferramenta para desenvolver em Angular. Depois que sua aplicação estiver pronta, você não precisa mais do Node.js.
No segundo módulo do curso, no final, eu ensino a usar o ANGULAR CLI. Uma ferramenta BETA ainda, mas que será o padrão de se lidar com aplicações Angular. Uma das funcionalidades é empacotar sua aplicação para colocá-la no ar (concatenar, minificar...fazer todo aquele lance de otimização). O Angular CLI também vem com um servidor com livereload embutido. Sendo assim, com o Angular CLI vc desenvolve localmente através do server que ele disponibiliza. Mas se você vai acessar uma API, e vai querer né, precisa de outro server em Php, Java ou seja lá o que for que forneça os dados para a aplicação Angular.
Conseguir lançar uma luz nessa questão?
