Introdução básica
Vamos começar com um conceito importante "modelo". Em termos gerais, um modelo na web é uma página que pode gerar um arquivo após preencher dados. Estritamente falando, o mecanismo de modelo deve usar arquivos em um formato específico e os dados fornecidos para compilar e gerar páginas. Os modelos são divididos aproximadamente em modelos de front-end (como EJs) e modelos de back-end (como Freemarker) compilados no navegador e no lado do servidor, respectivamente.
Como alguns estudantes no local não sabiam muito sobre o Node.js, aqui estão alguns dos conhecimentos relevantes do Node.JS. Não vou falar sobre as definições de eventos, assíncronos e assim por diante no site oficial. Aqui pego emprestado uma foto de Pu Lingshu para explicar a estrutura do Node.JS. Se você entende o Java, pode entendê -lo como uma versão JS da JVM. Os navegadores geralmente incluem renderizadores e motores de script JS. Tomando o navegador Chrome como exemplo, eles usam o renderizador do kernel do webkit e o mecanismo de script V8, enquanto o Node.js usa o mecanismo V8. Em suma, é um ambiente de corrida JS, assim como a ferramenta de depuração F12 do navegador, mas o Node.js não possui DOM e BOM.
Esta imagem descreve algumas informações sobre o Node.js, como o NPM, o excelente gerente de pacotes, a comunidade CNODE e o Github, que promoveram a prosperidade do Node.js até certo ponto e forneceu garantias técnicas.
As grandes empresas são geralmente o patinho climático da tecnologia. Por exemplo, o React Angular e o Facebook do Google são muito populares agora. Apenas três grandes empresas estão listadas aqui como exemplos. Escusado será dizer que a arquitetura intermediária de Taobao é, Pu Ling, o pioneiro do Node.js doméstico, vem de Taobao. Quunar também desenvolveu uma estrutura técnica que deve ser chamada de "qtx". A equipe 75 liderada por Yueying lançou uma estrutura de servidor da web com base no ES6/ES7 - ThinkJs. Naquela época, nosso diretor técnico era muito otimista, mas como eu não tive tempo de aprender ES6 e os plug-ins não eram ricos o suficiente, ainda escolhi um expresso mais maduro.
De volta ao tópico, esta tabela lista três métodos de desenvolvimento para a separação das extremidades dianteiras e traseiras às quais fui exposto. O primeiro é os modelos de linguagem de back-end mais comuns que usam Java, que são amigáveis para SEO e são melhores na utilização de cache e na redução da carga de renderização do navegador. O maior problema é que o grau de acoplamento de arquivos de modelo é muito alto. Ninguém quer resolver o problema. O pessoal do front-end não pode ver os dados, o pessoal de back-end não entende a página e os arquivos de modelo são como uma batata quente. A segunda é a solução de implementação atual do terminal móvel do nosso projeto, que usa a estrutura de angular (as instruções angulares podem ser consideradas como modelos de front-end) e o servidor de proxy reverso do NGINX para dissociar completamente o front-end e o back-end e apenas interagir com dados através do AJAX. Esta solução é exatamente o oposto das vantagens e desvantagens do primeiro. O desempenho dos modelos de front-end é sempre um problema, especialmente em dispositivos móveis, e mais particularmente em dispositivos móveis de ponta. O último é o novo projeto que usa o Node.js como um servidor front-end, que divide as responsabilidades do front-end do navegador ao nível do modelo, resolvendo todos os problemas acima, mas existem de fato novos problemas, e esse problema será analisado posteriormente.
Obviamente, o desenvolvimento da pilha completa também é muito adequada para pequenos projetos. Para o desenvolvimento tradicional de JSP/PHP, o custo de comunicação do desenvolvimento da pilha completa é menor e os desenvolvedores podem entender facilmente todo o módulo funcional, restaurando melhor o design do produto. Especialmente o desenvolvimento da pilha completa baseada na linguagem JS: meteoros e tecnologia média que agora estão emergentes tornam o desenvolvimento front-end e back-end tratado diretamente em um idioma. Com o MongoDB, os dados do navegador para o banco de dados são usados diretamente sem escapar, e não há necessidade de escrever SQL, o que reduz bastante o custo de desenvolvimento.
Alguns plugins usados para criar o servidor Node.js desta vez. Não há necessidade de introduzir o famoso Express, a estrutura leve do servidor da web. Também é uma coincidência usar o motor do modelo do guidão, porque o Express4 é por padrão. O guidão é digno de ser o mecanismo de modelo de "lógica fraca". Ele defende a redução da lógica do modelo e a tentativa de usar apenas variáveis e paginação. Com base em seu conceito de design, apenas expandi dois ajudantes. Artigo específico: https://yalishizhude.github.io/2016/01/22/handlebars/superaGent ainda é usado por causa do Express4. Como seu código de teste usa o Supertest, o Supertest é baseado em SuperAgent, portanto, SuperAgent é usado para encaminhar e iniciar solicitações. Superagente ainda é muito fraco e não pode ser estabelecido para conexões longas. Eu ainda recomendo o plug -in de solicitação. Não há nada para apresentar a Restleapi. O servidor front-end e o navegador, o servidor front-end e o servidor de back-end usam esse conjunto de especificações. Basicamente, o URL aponta para os recursos, adiciona, exclui, modifica e verificações, e o método de solicitação específico é expresso, os códigos de status representam resultados etc. ~ Ferramenta de embalagem Gulp, o WebPack está estudando há muito tempo e descobriu que cada página adicionada requer modificação do arquivo de configuração. Isso é muito doloroso, então eu desisti.
Processo de desenvolvimento
Se esse compartilhamento falar principalmente sobre como usar o Node.js como um servidor front-end para obter a separação front-end, então não há nada a dizer, basta olhar para o artigo sobre o Taobao UED. O maior problema com a separação das extremidades dianteiras e traseiras é que ele traz custos de comunicação, especificamente a definição e a depuração das interfaces. No processo de desenvolvimento tradicional da figura acima, a definição da interface será colocada no servidor de interface e, em seguida, as extremidades frontal e traseira conduzirão a depuração local com base nos dados de fraude do documento da interface e, em seguida, realizará depuração conjunta. Este link é quando as extremidades da frente e de trás começam a lutar. Este parâmetro está errado e o valor de retorno está errado. Em suma, é uma perda de tempo. Em seguida, vamos ver como esse problema é resolvido em nosso projeto ~
O problema da interface desgasta nas extremidades da frente e de trás sempre existiu. Como conservador, acredito no desenvolvimento iterativo; portanto, o primeiro passo é adicionar um servidor simulado. A mágica desse servidor é que ele gera automaticamente dados falsos com base no documento da interface, implementando a interface, a saber, a API e os alunos do front-end não precisam mais escrever os dados até a morte para testes. Não há como quem disse que eu sou um desenvolvedor de front-end? Primeiro de tudo, penso no meu próprio povo. Hehe, é claro, isso é benéfico apenas para o desenvolvimento do front-end até certo ponto. Também haverá problemas quando as interfaces e os documentos do back-end forem inconsistentes e estiverem conectados. O que fazer?
Eu acidentalmente vi um artigo de Lao Ma no blog do Blade Master, que fala especificamente sobre a separação das extremidades da frente e de trás. Um dos conceitos importantes é o teste de contrato, também chamado de teste bilateral. O conceito central é resolver o problema da depuração conjunta remota. Verifique os parâmetros das extremidades dianteiras e traseiras e exija que todos se desenvolvam de acordo com o documento da interface. Inspirado por ele, a regra JSON-Schema foi adicionada para realizar a verificação de parâmetros das solicitações HTTP e quem não seguir as regras a alterará.
Esta Redmine é o nosso primeiro gerenciador de documentos de interface e não tem outra função, exceto as funções de gravação e visualização.
Swagger é conhecido como o servidor de documentos de interface mais popular do mundo. Possui uma interface bonita e muitos plug-ins. Ele pode gerar diretamente o código de teste para linguagens de back-end. No entanto, eu nunca o entendi ao implantá -lo, e o formato YAML não é tão bom quanto o JSON, então desisti.
Este é o servidor de documentos e o servidor simulado usado em nosso projeto, o servidor implementado com base na tecnologia média e nas funções básicas:
Usando o plug-in do MockJS, os dados aleatórios podem ser gerados dinamicamente para executar testes de interface de soma de verificação nos parâmetros da interface com base no JSON-Schema, e o status do teste e o tempo de resposta da interface podem ser salvos. O editor JSON simples possui função de verificação de login e a depuração da interface pode ser executada após o login. O servidor simulado responde à solicitação de acordo com o servidor API e será atualizado automaticamente quando a interface for atualizada.
Algumas perguntas
Node.js são as asas dos engenheiros de front-end e devo me tornar um anjo ou um demônio com asas? Isso depende se os problemas causados pelo uso podem ser resolvidos.
Primeiro de tudo, a carga de trabalho no front end, sem dúvida, aumentará, mas o custo da comunicação será reduzido. A estabilidade do servidor do thread Node.js não é realmente bom o suficiente, mas a robustez do código e o log perfeito podem ser efetivamente evitados. Ligar de volta. Existem muitas soluções para esse problema, incluindo o módulo q/assíncrono do Node.js e ES6/ES7. Node.js Depuração. Embora eu sempre tenha rejeitado o IDE, tenho que admitir que o WebStorm é realmente muito conveniente para a depuração. O inspetor de nós que eu uso também é bastante bom, a interface é semelhante à ferramenta de desenvolvedor do Chrome e parece bastante familiar.
Se você é um programador de back -end, deve ter mais chances de acomodar node.js. O trabalho da integração da interface é entregue ao servidor front-end para processamento, e o grau de acoplamento com o front-end é bastante reduzido, e a carga de trabalho e a eficiência do trabalho são reduzidas.
Há dois pontos para experimentar
Embora o uso do Node.js tenha um certo custo de aprendizado, ainda é muito amigável para os desenvolvedores de front-end. Além disso, se o Node.js for usado no front end, o conteúdo técnico e a carga de trabalho serão aprimorados, aumentando assim a importância do trabalho. Somente quando os desenvolvedores atuais podem criar mais valor, são elegíveis para exigir salários mais altos. Recomenda-se fazer menos sugestões e fornecer mais planos de viabilidade no trabalho e realizar pré-pesquisa técnica em vez de escrever um helloworld simples.
Resumir
Algumas pessoas podem dizer que o conjunto de coisas que você introduziu é tão complicado e é muito problemático de usar, por isso é melhor se comunicar cara a cara. Para tais dúvidas, só posso usar um exemplo mencionado pelo engenheiro sênior da TENCENT YU Guo em "Autocultivação de engenheiros de pilha completa da Web". Uma vez, quando a pessoa do front-end encarregada de uma pequena empresa no telefone perguntou a ele como gerenciar o código, a outra parte disse que usaria o FTP para enviá-lo diretamente e reclamou que seus subordinados sempre atualizaram o código errado. Ele também perguntou por que ele não usava SVN ou Git. Ele disse que seria mais fácil atualizar manualmente. A verdade desta história é minha resposta para a pergunta ~
Endereço de download ppt