Todos os arquivos de front-end e back-end residem no mesmo local, com o cliente Vue criado para produção em uma pasta localizada em / client / dist.
No server.js, junto com um monte de código de banco de dados e roteamento, há uma pequena linha que diz:
server.use(serveStatic(__dirname + "/client/dist"));No Express, isso instrui o aplicativo a servir meus arquivos estáticos de clientes de uma pasta específica e me permite executar os front-ends e back-ends no mesmo ambiente. Se você estiver implantando um aplicativo igualmente simples, esse tipo de solução também funcionará para você.
Por outro lado, e dependendo da complexidade do seu projeto, talvez seja necessário separar os front-ends e back-ends e tratá-los como aplicativos separados, o que não é grande coisa. No aplicativo acima, meu cliente está fazendo chamadas para terminais de API estáticos que são tratados pelo servidor, assim:
getQuests: function () { axios .get('https://mevn-rpg-app.herokuapp.com/quests') .then(response => (this.questData = response.data)) }Tecnicamente, meu cliente pode fazer essas solicitações de qualquer lugar – até mesmo um site estático do GitHub Pages. Esse tipo de solução pode ajudar a separar seu aplicativo em duas entidades distintas, o que às vezes é melhor do que tentar agrupar todo o projeto em um único local.
Uma observação: se você estiver fazendo solicitações HTTP de origem cruzada – ou seja, solicitações de um cliente que mora em um domínio separado da API ou do servidor – precisará se familiarizar com CORS. Você pode ler mais sobre isso em Este artigo.
Seu código precisará ser alterado para oferecer suporte a um ambiente de produção.
Quando você está no meio do processo de desenvolvimento, pode ser fácil perder a noção de quanto do seu código depende de arquivos locais ou outros dados.
Considere o seguinte em um server.js em execução local:
server.listen(3000, () => console.log("Server started!"));Em uma máquina local, o código pede ao servidor para escutar na porta 3000 e registrar no console que estamos prontos para a decolagem.
Em um ambiente de produção, o servidor não tem conceito de onde o “host local” deve estar ou para cuja porta 3000 deve estar atendendo. Com este exemplo, você precisaria alterar seu código para algo como:
const port = process.env.PORT || 3000;server.listen(port, () => console.log("Server started!"));A instrução acima instrui o servidor a escutar na porta 3000 do processo atualmente em execução, onde quer que esteja (confira Este artigo para ler mais sobre este tópico).
Da mesma forma, no meu aplicativo, tenho vários módulos que precisam ser importados um pelo outro para funcionar:
Em /routes/Quests.js, por exemplo, eu tenho um roteador que informa ao servidor o que fazer ao receber solicitações de API para interagir com itens relacionados a missões no banco de dados. O roteador precisa importar um Esquema de mangusto do /models/quest.js para funcionar corretamente. Se o aplicativo estivesse sendo executado localmente, poderíamos apenas dizer:
const Quest = require('../models/quest');Bem simples! Infelizmente, nosso servidor não saberá onde encontrar o diretório raiz do nosso projeto, uma vez implantado. No Express, alteramos nosso código para algo como:
const path = require('path');const Quest = require(path.join(__dirname, '../models/quest'));Seu caso específico pode ser diferente, dependendo do seu idioma e da (s) estrutura (s), mas você precisará ser específico sobre a aparência do seu código em um ambiente de produção e não no ambiente de desenvolvimento local.
Ademais, você provavelmente já está familiarizado com o empacotador que está usando para seu front end (por exemplo, webpack) e desejará criar seu cliente para produção para otimizá-lo para implantação.
Você tem várias plataformas de implantação para escolher.
Se você implantou um site front-end ou algum outro tipo de aplicativo estático, pode estar familiarizado com apenas enviar seus arquivos para algum repositório remoto e chamá-lo por dia.
A implantação de um aplicativo de pilha cheia (ou mesmo apenas um back-end) é eminentemente mais complexa. Você precisará de um servidor dedicado, ou algo que emule um, para responder às solicitações HTTP que ele receberá e trabalhar com um banco de dados online.
Existem vários serviços que farão exatamente isso por você, e o espectro varia com base no preço, escalabilidade, complexidade e outros fatores.
Há um monte de artigos por aí que comparam PaaS opções para implantação, mas aqui estão algumas considerações ao considerar plataformas para seu primeiro projeto:
- Heroku: Se você tem um projeto pequeno como o meu ou apenas deseja aprender sobre a implantação, um bom primeiro passo pode ser Heroku.
- AWS, Docker e Kubernetes: Se você está procurando uma carreira em desenvolvimento da Web com pilha completa ou DevOps, agora é um bom momento para se familiarizar com Amazon Web Services e / ou plataformas de contêineres como Docker e Kubernetes.
- Azure: Se você é um desenvolvedor de C # ou .NET, Azure parece ser uma maneira perfeita de implantar seus aplicativos sem precisar sair da segurança do ecossistema da Microsoft.
Obviamente, existem várias outras opções disponíveis, e seu cenário de caso de uso específico pode depender dos preços ou dos conjuntos de recursos específicos oferecidos.
Ademais, convém considerar todos os complementos necessários para replicar a funcionalidade do seu aplicativo em um ambiente de produção. Meu rastreador de jogos de RPG, por exemplo, usa o MongoDB, mas a versão de produção certamente não pode usar o pequeno banco de dados na minha máquina local! Em vez disso, usei o mLab Addon Heroku para colocar o site ativo em funcionamento com a mesma funcionalidade do meu ambiente de desenvolvimento.
O sucesso do seu aplicativo, assim como o seu próprio progresso como desenvolvedor da Web de pilha completa, dependem da sua capacidade de considerar opções de implantação e criar um pipeline de produção bem-sucedido. Com um pouco de pesquisa, tenho certeza de que você pode encontrar a melhor solução que atenda a todas as necessidades do seu aplicativo.
Feliz codificação!
Se você gostou deste artigo, considere verificando meus jogos e livros ou se inscrevendo no meu canal do YouTube.
M. S. Farzan, Ph.D. escreveu e trabalhou para empresas de videogame de alto nível e sites editoriais como Electronic Arts, Perfect World Entertainment, Modus Games e MMORPG.com e atuou como gerente de comunidade em jogos como Dungeons & Dragons Neverwinter e Efeito de massa: Andrômeda. Ele é o diretor criativo e designer de jogos líder da Entromancy: Um RPG de Fantasia Cyberpunk e autor de A Trilogia Caminho Noturno. Encontre M. S. Farzan no Twitter @sominator.