Being MEVN + Restful — Parte 3
Parte 3/3 de como construir uma aplicação MEVN + Restful API com deploy na Heroku e GitHub Pages!
Continuando com nosso tutorial, iremos agora fazer o deploy dos códigos feitos na parte 1 e parte 2. Iremos utilizar a Heroku para hospedar o nosso back-end e o GitHub Pages para hospedar o front-end.
Vou falar um pouco sobre essas ferramentas antes de iniciarmos todo o nosso processo de deploy!
Heroku
A Heroku é um SaaS para hospedagem e monitoramento de aplicações. Como eles mesmos afirmam, é o jeito mais rápido de colocar a sua ideia em uma URL. Dentro do ambiente das suas aplicações, você também pode adicionar add-ons, por exemplo para banco de dados ou outros serviços.
A Heroku oferece planos gratuitos e pagos para seu uso. O mesmo também ocorre com os seus add-ons, que geralmente são precificados através de métricas de uso e/ou armazenamento.
Para maiores informações, faça uma visita na página oficinal: https://heroku.com/
GitHub Pages
O GitHub Pages é um serviço gratuito oferecido pelo GitHub para que você possa hospedar sites estáticos. A ideia surgiu com o propósito de proporcionar aos desenvolvedores uma maneira rápida de promover seus projetos — você cria um repositório no GitHub para hospedar e distribuir seu código, e cria um site para esse projeto através do GitHub Pages.
É importante ressaltar aqui que, o GitHub Pages apenas faz o render de HTML + CSS + JS client-side — ele não irá, por exemplo, interpretar nosso código do back-end. O serviço é válido apenas para sites estáticos, ou para a camada de view das aplicações (como é o nosso caso).
Os sites hospedados através do GitHub pages podem ser criados normalmente (você desenvolvendo) ou então você pode utilizar alguns temas que são oferecidos, para poupar tempo; você também pode utilizar o Jekyll.
Para maiores informações, faça uma visita na página oficinal: https://pages.github.com/
Dito tudo isso, vamos voltar ao código!
1 —Heroku
Para esse projeto, iremos utilizar o free tier da Heroku, ou seja, não vamos precisar pagar nada. Nesse plano, nossa aplicação irá dormir após 30min de inatividade.
Após ter criado sua conta no Heroku, você deverá cria uma nova aplicação. Você pode primeiro criar a aplicação e depois fazer o deploy dos códigos, a Heroku irá identificar automaticamente a linguagem que você utilizou e irá otimizar o ambiente para sua aplicação.
Para facilitar o deploy dos códigos, podemos vincular o repositório do GitHub para a nossa instância da Heroku — assim, todo o código que estiver na branch master do nosso repositório subirá para produção. Nesse ponto, você também pode criar integrações com CI (integração contínua, como o Travis CI).
Pronto, agora temos a nossa instância na Heroku. O próximo passo será configurar o banco de dados para depois subirmos o nosso código.
1.1 — Add-on Mongo Labs
Para adicionar o add-on na sua instância você deve ir até resources, e procurar por mLab MongoDB e selecionar o plano free. Mesmo para o plano grátis, você deverá inserir um cartão de crédito válido no seu cadastro da Heroku para poder utilizar esse add-on.
Depois de adicionar o add-on, você deverá configurar a collection. Para isso, clique no item do addo-on; uma nova aba será carregada e você terá acesso as configurações. Nessa tela, você pode criar uma collection e também pegar as informações de conexão, que iremos utilizar para ligar a nossa API com o banco.
Na tela acima temos o acesso para conectarmos nossa API ao Mongo em produção. No código do nosso back-end, precisamos trocar agora nossa conexão, pois estamos sempre conectando ao nosso banco local.
Para isso, vá até o arquivo config/default.json e adicione as informações do banco de produção. Seu código deverá ficar mais ou menos assim:
Onde as informações do objeto prod deverão ser substituídas pelas informações fornecidas no dashboard do mLab.
Agora que já temos os parâmetros da conexão, precisamos conectar ao banco certo, pois ainda estamos nos conectando com o banco local. No arquivo db/mongo.js vemos mudar a linha
const {username, password, server, port, database} = config.get('mongo.local')para
const {username, password, server, port, database} = config.get('mongo.prod')Dessa maneira estaremos sempre nos conectando com o banco de produção. De certa forma é o que queremos, mas isso pode ficar ainda melhor: podemos fazer isso de forma dinâmica.
No package.json vamos alterar os scripts para que possamos nos conectar de forma dinâmica aos bancos certos:
"scripts": { "test": "node_modules/mocha/bin/mocha tests/unit/* --recursive --exit",
"start": "export DEBUG=node_api:* && export NODE_ENV=prod && nodemon ./bin/www",
"local": "export DEBUG=node_api:* && export NODE_ENV=local && nodemon ./bin/www"}
Aqui, criamos um novo script, local e alteramos o start — estamos exportando uma variáviel, a NODE_ENV. Será através dela que iremos saber se estamos no ambiente local ou prod, para pegar o banco de forma dinâmica.
Agora, voltando ao arquivo db/mongo.js, vamos fazer o seguinte:
const {username, password, server, port, database} = config.get(`mongo.${process.env.NODE_ENV}`)Assim, o valor da nossa variávei NODE_ENV irá definir em qual banco iremos nos conectar. Quando estivermos com o código em produção, por padrão, o projeto será iniciado com npm start e quando estivermos no ambiente de desenvolvimento, iremos inciar ele com npm run local .
1.2 — Heroku CLI
A Heroku oferece uma ferramenta CLI para que você possa acessar suas instâncias através de um bash/terminal: a Heroku CLI. Ela está disponível para Windows, Linux e Mac.
Através dessa CLI, você pode fazer o acompanhamento das suas aplicações, realizar commits e deploys de maneira mais rápida e prática.
2 — GitHub Pages
Para entender um pouco melhor como o GitHub Pages vai funcionar para o nosso projeto, imagine que o nosso repositório é equivalente ao diretório root de um site — precisamos ter então uma index.html para que, quando o usuário acesse a URL do site, seja mostrada uma página bonita.
Para quem já tem mais experiência, quando utilizamos o GitHub Pages em um repositório, esse repositório tem que estar organizado da mesma forma quando utilizamos um FTP, por exemplo.
Mas, para deixarmos isso automatizado e não nos preocuparmos com ter que ficar trocando nome de pasta ou lugar de arquivo, vamos utilizar um package chamado gh-pages. Através dele, iremos publicar apenas os arquivos de distribuição da nossa aplicação.
Para instalá-lo no projeto, insira o comando:
npm install --save-dev gh-pagesE, no package.json devemos inserir os seguintes scripts:
"scripts": { "predeploy": "npm run build",
"deploy": "node node_modules/gh-pages/bin/gh-pages-clean.js && gh-pages -d dist"}
Com esses 2 scripts, iremos fazer o build do nosso projeto e utilizar o gh-pages para criar uma nova branch no nosso repositório e subir nela os arquivos de distribuição do nosso projeto. Automaticamente, esse package também faz a ligação da branch criada com o GitHub Pages.
Esse post do William Oliveira explica exatamente como utilizar o package. No exemplo dele, ele utiliza um app feito com React, mas o princípio vai ser o mesmo.
Outro ponto importante — antes de fazermos o build do projeto, precisamos alterar a URL da API!
No arquivo src/services/keys.js eu adicionei a seguinte linha:
export const PROD_BASE_URL = 'https://node-api-server.herokuapp.com/publications/'E no arquivo src/services/api.js eu fiz a seguinte alteração:
const baseURL = process.env.NODE_ENV === ‘local’ ? keys.LOCAL_BASE_URL : keys.PROD_BASE_URLexport default () => {
return axios.create({
baseURL: baseURL,
headers: {
'X-Access-Token': `${keys.BASIC_TOKEN}`
}
})
}
Dessa forma, estaremos apontando para o back-end certo, e agora podemos fazer o build do projeto.
2.1 — Hospedagem
A hospedagem do GitHub Pages é feita de forma gratuita, porém ela se limita a apenas o client-side; ou seja, nós não poderíamos utilizar esse serviço para hospedar e renderizar nosso server-side — o código do server-side precisa ser interpretado por um servidor. Por isso utilizamos a Heroku, onde nós temos uma instância que estará rodando o nosso código feito com Node.
2.2 — Custom domains
Quando você adiciona o GitHub Pages em um repositório, ele é hospedado pelos servidores do GitHub e a URL é montada da seguinte forma:
username.github.io/repo_name/index.htmlEu particularmente gosto desse esquema, mas tem gente que não acha tão maneiro. Por isso, você também pode utilizar custom domains para os seus projetos.
Para isso, você precisa ter um domínio registrado e associar o DNS do seu domínio nas configurações do repositório. Dessa forma, quando o usuário acessar o seu domínio customizado, ele estará visualizando o site do GitHub Pages.
3 — Indo além
Nós criamos aqui um MVP, o famoso mínimo produto viável. Você já pode colocar no seu portfólio que agora sabe criar RESTful APIs em Node e também criar aplicações com Vue!
Claro, o principal objetivo desse tutorial é mostrar como funciona uma API utilizando a arquitetura MVC, com um exemplo mais real world — ao invés de utilizarmos server-side rendering, utilizamos uma aplicação externa para consultar e consumir os dados da API.
Acredito que, em todas as partes desse MVP, podem ser realizadas melhorias. Desde a própria arquitetura, onde você pode encontrar lindos boilerplates ou então utilizar outras metodologias, a parte do banco de dados, onde você pode utilizar o mongoose para criar os schemas das entidades que serão salvas; até a parte de testes, utilizando um TDD ou coisas do tipo.
Outras features poderiam ser adicionadas, como um login ou autenticação com GitHub, Gravatar; utilização de JWT e por aí vai… Mas, isso eu vou deixar com você!
Vou também deixar aqui uma dica de um package bem bacana, relacionado a produtividade: o tlapse. Com ele, você tira screenshots do seu projeto durante o desenvolvimento, e vai vendo o seu progresso de acordo com o tempo.
4 — Conclusão
Nessa série de tutoriais vimos o quão simples é criar um webapp — desde a ideia até o banco de dados. O Node também nos proporcionou essa maneira com mais flexibilidade e rapidez, porém ele não é a solução de todos os problemas do mundo.
Da mesma maneira podemos avaliar o Mongo — ele é incrível, porém nem tudo pode ser feito com ele; muitas vezes você irá precisar de um banco SQL.
Se somarmos os tempos de leitura das 4 partes desse turorial, demoramos cerca de 45 minutos desde o início até essa conclusão.
Como dito ali em cima, várias melhorias e features podem ser aplicadas; mas chegar até aqui já é uma grande conquista, portanto, meus parabéns!
Se você tiver alguma dica, sugestão, dúvida, crítica, enfim, sinta-se livre para comentar aqui nas publicações, abrir issues ou PRs nos repositórios, entrar em contato comigo pelas redes sociais...
E se você também quiser compartilhar o seu progresso com o tutorial, ou então compartilhar o link dos seus projetos, manda bala! Ficarei muito feliz em receber feedbacks — afinal, escrevi esse tutorial para vocês!
