Utilização de Containers

[mathleite]

Olá, gostei bastante do projeto e gostaria de contribuir o máximo que conseguir :)

Notei que, hoje, não temos a garantia de um mesmo ambiente (desenvolvimento/produção/etc) para todos. Dito isto, por que não deixar todos no mesmo "nível" utilizando o nosso querido Docker?

O que acham desta proposta?

[paulogdm]

Acho que poderia ser um problema pelos seguintes motivos:

• Seu servidor vai precisar ser monitorado. Health-checks e outros fatores entram em discussão aqui.
• Será que para servir um front-end eu realmente preciso de Docker, k8s, load-balancers, etc? Não seria aumentar a complexidade demais?

É uma discussão que tivemos muito na transição entre Now 1.0 (Docker/servers) e Now 2.0 (focado em frontend e serverless functions). No final é uma diferença de filosofia mas acreditamos piamente que Now 2.0 bate qualquer setup mais complexo e criado do zero para frontends. Em resumo você vai chegar nos mesmos problemas que a plataforma já te entrega como resolvidos e não há necessidade de gastar 4+ dígitos de horas de desenvolvimento em uma solução "in-house". Isso é representado também no pivotamente de SSR pra SSG e derivados com Next.js. Mais infos em:

• 2019 in review
• Next.js 9.3.

Um dos principais drivers para o ZEIT Now hoje é "better than localhost". Isso significa que deployar em dev/staging é tão fácil que é mais fácil fazer isso do que criar containers localmente.

[paulogdm]

Se a intenção de Docker é para desenvolvimento local, usar "engines" no package.json pra garantir uma versão do Node já é suficiente. Vai ser mais rápido e melhor para os usuários do repositório.

[filipedeschamps]

@paulogdm sensacional trazer a sua visão aqui nessa issue 👍e muito legal saber das discussões que aconteceram entre o Now 1.0 e 2.0... eu acabei assistindo muitas palestras do Guillermo Rauch e você conseguiu resumir muito bem a sensação que eu tive, de inclusive reverter o caminho natural que era começar pela tecnologia e terminar no UX para começar no UX e terminar na tecnologia (e como isso se reflete em vários micro detalhes do framework ou módulos adicionais como o SWR).

Sobre levar o container para staging ou produção, concordo que isso não é uma boa ideia, exclusivamente por usar o Now e que inclusive eu passo mal de lembrar o que é na realidade configurar um ambiente de staging e production.

Agora, o que me chamou atenção foi o "better than localhost", extremamente "bold" e eu adoro isso, é esse tipo de postura que move as coisas para frente. Apesar que eu não vejo hoje o Next.js + Now substituindo o localhost, é notável que se ficou muito mais rápido e sem fricção tornar "realidade" as coisas que você desenvolveu no localhost... parece até diferente de um ambiente de produção, não sei porque dessa sensação.

Em paralelo, eu sei que algumas pessoas tem aversão a instalar dependências em sua máquina e ter uma alternativa com Docker mas que fique transparente para quem quiser usar ou não, por mim tudo bem. Eu não uso Docker na máquina local, peguei um pouco de trauma da época que eu tinha uma máquina muito fraquinha e o Docker não era nativo para macOS 😂

E por fim, qualquer implementação vai bater no CI que vai usar a Preview URL, então não tem como escapar. Na verdade hoje tem, por conta do Github Actions que não está acionando quando o PR vem de um fork, como está sendo discutido nesse PR https://github.com/filipedeschamps/BrasilAPI/pull/38

Fora isso, na minha visão a Zeit vai repaginar o que as pessoas entendem por testes automatizados 👍

[filipedeschamps]

Pessoal, por hora estou fechando essa issue, mas qualquer dúvida podemos reabrir para continuar com as conversas 👍