Prefácio
Ao separar as extremidades da frente e da parte traseira, a primeira edição a que presto é a renderização, ou seja, trabalha no nível da visualização.
No modelo de desenvolvimento tradicional, o navegador e o servidor são desenvolvidos por duas equipes, as extremidades dianteiras e traseiras, mas o modelo está na área vaga entre os dois. Portanto, sempre existem lógicas cada vez mais complexas no modelo, que são difíceis de manter.
E escolhemos o NodeJS como a camada média da frente e das extremidades traseiras. Tente usar o NodeJS para esclarecer o trabalho no nível de visualização.
Isso torna a divisão do trabalho entre as extremidades da frente e de trás mais clara, torna o projeto melhor mantido e alcança uma melhor experiência do usuário.
Este artigo
O trabalho de renderização é uma proporção muito grande do trabalho diário dos desenvolvedores de front-end, e também é a parte mais fácil ser confundida com o desenvolvimento de back-end.
Olhando para trás nos últimos anos de desenvolvimento de tecnologia front-end, o trabalho no nível de visualização passou por muitas mudanças, como:
Formulário Enviar página completa Refresh => Ajax Refresh local
Continuação do lado do servidor + MVC => Renderização do lado do cliente + MVC
Mudança de página tradicional Jump => Aplicativo de página única
Pode -se observar que, nos últimos anos, todos tendem a mover essa coisa do final do servidor para a extremidade do navegador.
O lado do servidor se concentra no serviço e fornece interfaces de dados.
Benefícios da renderização do navegador
Todos sabemos os benefícios da renderização do lado do navegador, como
1. Livre -se do acoplamento e confusão entre a lógica de negócios e a lógica de apresentação no mecanismo de modelo Java.
2. Para aplicações multi-terminais, é mais fácil interface. Coloque modelos diferentes no lado do navegador para apresentar aplicativos diferentes.
3. A renderização da página não é apenas HTML, mas a renderização no front end pode facilmente fornecer funções em forma componente (HTML + JS + CSS), para que os componentes front-end não precisem confiar na estrutura HTML gerada pelo servidor.
4. Livre-se da dependência dos processos de desenvolvimento e distribuição de back-end.
5. Ajuste da junta conveniente.
As desvantagens causadas pela renderização do navegador
Mas enquanto desfrutamos dos benefícios, também enfrentamos as desvantagens da renderização do lado do navegador, como:
1. O modelo é separado em diferentes bibliotecas. Alguns modelos são colocados no lado do servidor (Java), enquanto outros são colocados no lado do navegador (JS). As linguagens do modelo frontal e de back-end não estão conectadas.
2. Você precisa esperar que todos os modelos e componentes sejam carregados no navegador antes que a renderização possa começar, e você não pode lê -lo imediatamente.
3. Haverá uma tela branca esperando a renderização pela primeira vez, o que não é propício à experiência do usuário
4. Ao desenvolver um aplicativo de uma página, a rota front-end não corresponde à rota do lado do servidor, o que é muito problemático de manusear.
5. Todos os conteúdos importantes são montados na extremidade frontal, o que não é propício para o SEO
Refletir sobre a definição de front e traseiro
De fato, quando levamos o trabalho de renderização do lado do servidor (Java) para o lado do navegador (JS), nosso objetivo é apenas dividir claramente as responsabilidades da frente e do final, e não é necessário renderizar o navegador.
É apenas porque no modelo de desenvolvimento tradicional, o servidor é lançado e o navegador é atingido; portanto, o conteúdo do trabalho no front-end só pode ser limitado ao lado do navegador.
Portanto, muitas pessoas determinaram que o lado do back -end = servidor frontend = navegador, assim como a figura abaixo.
No projeto Midway Atualmente, em andamento por Taobao UED, construindo uma camada intermediária Nodejs no meio do navegador Java, tentamos diferenciar a linha de divisão frontal e traseira novamente para responsabilidades de trabalho, em vez de ambientes de hardware (servidor e navegador).
Portanto, temos a oportunidade de compartilhar modelos e rotas, que também é o estado mais ideal da divisão de trabalho do front-end e back-end do trabalho.
Taobao a meio caminho
No projeto Midway, movemos a linha que demarcar as extremidades dianteiras e traseiras do navegador para o lado do servidor.
Com uma camada NodeJS que é facilmente controlada pelo front-end e comum ao navegador, a separação front-end pode ser concluída com mais clareza.
Também é possível permitir o desenvolvimento do front-end para decidir a solução mais apropriada para diferentes situações. Em vez de tudo ser tratado no lado do navegador.
Dividindo responsabilidades
Midway não é um projeto que o front-end tenta pegar o trabalho de back-end. O objetivo é cortar claramente a área vaga do modelo e obter uma divisão mais clara de responsabilidades.
Back -end (java), focando
1. Camada de serviço
2. Formato de dados e estabilidade de dados
3. Lógica de negócios
Front-end, concentre-se
1.ui camada
2. Lógica de controle, lógica de renderização
3. Interação, experiência do usuário
E não mais se apega às diferenças entre o servidor ou o lado do navegador.
Compartilhamento de modelos
No modelo de desenvolvimento tradicional, o navegador e o servidor são desenvolvidos por duas equipes, as extremidades dianteiras e traseiras, mas o modelo está na área vaga entre os dois. Portanto, sempre existem lógicas cada vez mais complexas no modelo, que são difíceis de manter.
Com o NodeJS, os alunos de back -end podem se concentrar no desenvolvimento da lógica de negócios e dados na camada Java. Os alunos do front-end se concentram no desenvolvimento da lógica de controle e da renderização. E você pode escolher esses modelos para renderizar no lado do servidor (NodeJs) ou no lado do navegador.
Usando o mesmo modelo de linguagem de modelo XTemplate e o mesmo mecanismo de renderização JavaScript
Renderizar o mesmo resultado em diferentes ambientes de renderização (servidor, navegador de PC, navegador móvel, visualização da web etc.).
Compartilhamento de roteamento
Também devido à camada NodeJS, você pode controlar o roteamento com mais cuidado.
Se você precisar fazer o roteamento do lado do navegador no front-end, poderá configurar o roteamento do lado do servidor ao mesmo tempo, para que ele possa alterar as páginas no lado do navegador ou páginas no lado do servidor e você pode obter um efeito de renderização consistente.
Ao mesmo tempo, o problema de SEO também foi tratado.
A prática do compartilhamento de modelos
Geralmente quando renderizamos um modelo no navegador, o processo nada mais é do que
Digite o mecanismo de modelo no navegador (XtMpleate, Juicer, Handlerbar, etc.)
Arquivos de modelo de carga no lado do navegador, o método pode ser
Imprima na página usando <script type = "js/tpl"> ... </script>
Use a ferramenta de carregamento do módulo para carregar arquivos de modelos (beijo, requerjs, etc.)
outro
Obtenha dados e use o mecanismo de modelo para gerar html
Insira HTML no local especificado.
O processo acima pode ser visto que, se você deseja obter compartilhamento cruzado de modelos, o foco está realmente na seleção consistente do módulo.
Existem muitos padrões populares de módulos no mercado, como KMD, AMD e CommonJs. Desde que o arquivo de modelo NodeJS possa ser emitido para o NodeJS terminar através de especificações consistentes do módulo, o compartilhamento básico de modelos pode ser feito.
A série subsequente de artigos discutirá ainda mais o proxy e o compartilhamento do modelo.
Discussão do caso
Por causa da camada intermediária de Midway Island, há melhores respostas para algumas perguntas anteriores, como
Caso 1 Aplicativos interativos complexos (como carrinho de compras, página de pedido)
Status: Todo o HTML é renderizado no front end e o servidor fornece apenas interfaces.
Problema: Ao entrar na página, haverá uma breve tela branca.
responder:
Digite a página pela primeira vez, renderize a página inteira no lado do Nodejs e faça o download de modelos relacionados em segundo plano.
Interações subsequentes, atualização parcial completa no lado do navegador
Usar o mesmo modelo produz o mesmo resultado
Caso 2 Aplicativo de página única
Status: use a estrutura do MVC do lado do cliente para alterar as páginas no navegador.
Problema: a renderização e a substituição da página são concluídas no lado do navegador. Quando você entra no URL diretamente ou atualiza o F5, o mesmo conteúdo não pode ser apresentado diretamente.
responder:
Compartilhe as mesmas configurações de rota no lado do navegador e no lado Nodejs
Ao alterar as páginas no lado do navegador, altere a rota e renderize o conteúdo da página no lado do navegador.
Ao inserir diretamente o mesmo URL, use o quadro da página + página de renderização de conteúdo no lado NodeJS
Se você altera as páginas no navegador ou insira diretamente o mesmo URL, o conteúdo que você vê é o mesmo.
Além de aumentar a experiência e reduzir a complexidade lógica. Ele também resolveu o problema de SEO
Caso três página de navegação pura
Status: a página fornece apenas informações, menos ou nenhuma interação
Problema: o HTML é gerado no lado do servidor, CSS e JS são colocados em outro local e eles têm dependências entre si.
responder:
Através de NodeJs, gerenciamento unificado de html + css + js
Se você precisar se expandir para aplicativos complexos ou de uma página única no futuro, também poderá transferi-los facilmente.
Página do terminal de quatro cruzamentos do caso
Status: o mesmo aplicativo precisa apresentar diferentes interfaces e interações em diferentes pontos de extremidade
Problema: o gerenciamento de HTML não é fácil e o HTML diferente geralmente será gerado no lado do servidor, e o processamento diferente será feito no lado do navegador.
responder:
As páginas cruzadas estão renderizando problemas e são tratadas pelo front-end.
Através da camada NodeJS e do serviço de back -end, as melhores soluções podem ser projetadas para esse tipo de aplicativos complexos.
Resumir
O surgimento de tecnologias como Ajax, MVC do lado do cliente, spa e ligação de dados bidirecionais no passado foram todas as tentativas de resolver os gargalos encontrados no desenvolvimento do front-end naquele momento.
O surgimento da camada intermediária NodeJS também é uma tentativa de resolver uma limitação de que o front-end está atualmente limitado ao navegador.
Este artigo se concentra em compartilhar modelos de front-end e back-end e espera atrair atenção. Vamos discutir com você como melhorar nosso fluxo de trabalho e cooperar com o back-end para fazer um trabalho melhor no front-end sob a arquitetura da camada média do Nodejs.