O autor do material, cuja tradução publicamos, coletou 19 idéias que podem ser úteis para os desenvolvedores do Node.js. que desejam melhorar seu nível profissional em 2019. O mundo do JavaScript é enorme, portanto, dominar tudo o que será discutido aqui é simplesmente irreal. É improvável que exista alguém que possua tudo isso perfeitamente. No entanto, algo nesta revisão pode ser útil para você.
1. Pense em digitar. Preste atenção ao TypeScript
Está provado que a programação em JavaScript, usando a abordagem de digitação usada, leva a uma diminuição da produtividade do trabalho e ao aparecimento de erros. Isso não significa que você deve se esforçar para garantir que todo o código seja fortemente digitado. Em vez disso, estamos falando sobre o fato de que, ao desenvolver em JavaScript, seria bom escolher uma certa abordagem para trabalhar com tipos e segui-la. Tais abordagens diferem, entre outras coisas, pelo nível de restrições associadas aos tipos de dados impostos ao código. Por exemplo, pode ser algo muito simples, como organizar as verificações usando o
pacote jsonschema (ou
joi ). Se você sentir que precisa de um controle de tipo mais rigoroso, considere usar anotações de tipo no código JS comum (aqui o
fluxo do Facebook o ajudará). E se você estiver pronto para escrever um código quase completamente digitado, preste atenção ao
TypeScript .
Note-se que em 2018 o TypeScript ganhou séria popularidade; além disso, existe a sensação de que existem todos os pré-requisitos para que ele se estabeleça firmemente no Node.js. Se você está olhando seriamente para o TypeScript, deve se perguntar se está pensando apenas em digitar ou em outros recursos da linguagem. O ponto aqui é que trabalhar com algo como interfaces e classes abstratas significa que você se encontrará em um ambiente em que, pensando principalmente em digitar, dificilmente entraria nele.
2. Preste atenção aos recursos do linter
Linters nos dias de hoje são um dado adquirido. Após uma configuração simples, você tem à sua disposição uma ferramenta para ajudá-lo a encontrar erros no código. Longe vão os dias em que o código de fiapos significava principalmente controlar seu design (algo como a presença ou ausência de ponto e vírgula). Agora, os linters podem identificar problemas sérios - como erros que não são tratados adequadamente, promessas que nunca são resolvidas e outros problemas semelhantes que ninguém incluirá conscientemente em seu código. Portanto, se você ainda não estiver usando o linter, agora é a hora de fazê-lo, sem esquecer sua configuração cuidadosa. Aqui, por exemplo, está um plug-in para
ESLint ,
eslint-plugin-chai-expect , que pode detectar testes compostos erroneamente. Aqui está o
plug-in eslint-plugin-promessa que detecta promessas não resolvidas (o código com essas promessas, sem motivo aparente, simplesmente para). Usando o
plug-in eslint-plugin-security, é possível encontrar expressões regulares não seguras no código que pode ser usado por um invasor para realizar ataques do DOS.
3. Aprofundar seu conhecimento da arquitetura de projetos de software adotando algo do mundo Java e esquecendo muito do mundo Ruby
O ecossistema do Node.js raramente levanta o tópico de arquitetura e design de sistemas de informação. Então, todo mundo está falando sobre microsserviços, mas apenas muito poucos falam sobre sua estrutura interna. Como resultado, a maioria dos aplicativos Node.js. são exemplos de implementação de conceitos MVC e outros padrões duvidosos do mundo Ruby. O que há de tão ruim nisso? O modelo MVC, por exemplo, foi criado para otimizar o trabalho com dados, mas esse modelo não é adequado para projetar partes confiáveis de aplicativos do servidor. Bob Martin, por exemplo,
diz que o MVC é um mecanismo para fornecer dados a um usuário, não uma arquitetura de aplicativo. É possível descrever a lógica comercial de um aplicativo de microsserviço, as regras de sua operação, recursos de acesso a dados, interação com outros microsserviços usando apenas duas classes -
Controller e
Model ?
Deve-se notar que eu absolutamente não quero recomendar o uso de modelos Java / Spring no Node.js. aqui (afinal, não foi por acaso que mudamos para o Node.js. para desenvolver programas de servidor?). Eu recomendaria que você emprestasse apenas algumas idéias que, por um lado, podem ter um efeito benéfico na arquitetura de aplicativos e, por outro lado, não farão com que se tornem muito complicadas.
Aqui estão algumas diretrizes para quem se preocupa com a arquitetura dos projetos Node.js.
- Leia a primeira seção deste artigo sobre arquitetura de aplicativos Node.js.
- Tente não combinar a lógica comercial dos aplicativos com os objetos Express, leia sobre os princípios DDD ( Domain-Driven Design ) e a arquitetura hexagonal .
- O uso do padrão Active Record, que é muito popular entre os desenvolvedores que usam Mongoose e Sequelize, leva facilmente ao aparecimento de objetos sobrecarregados, difíceis de testar. Considere usar o padrão Data Mapper em vez do padrão Active Record.
- Confira o código para este projeto bem elaborado de modelo Node.js., apresentando uma arquitetura de qualidade que implementa os princípios do DDD.
4. Pense em como usar a nova Node.js-API async_hooks ao trabalhar com código assíncrono
O modelo de execução de código de thread único usado no JavaScript tem uma desvantagem séria: operações assíncronas, por exemplo, solicitações, perdem o contexto. Ele não é salvo durante o ciclo de vida da consulta, pois operações assíncronas estão envolvidas em sua execução. Por que isso é ruim? Por exemplo, os desenvolvedores geralmente procuram incluir identificadores de consulta exclusivos nos lançamentos no diário, o que, ao analisar esses registros, permite identificar aqueles relacionados à mesma consulta. Hoje, em 2018, isso não é tão fácil. No próximo ano, algo novo nos espera, a saber, estamos falando de ganchos assíncronos, a API
async_hooks . Isso não quer dizer que essa seja uma oportunidade completamente nova, o ponto é que ela deve sair em breve do regime experimental. Simplificando, ganchos assíncronos permitem que um desenvolvedor execute código nativo em determinados pontos do ciclo de vida de uma operação assíncrona. Com isso em mente, você pode coordenar ações executadas por código assíncrono e manter o contexto. Esse recurso estabelece as bases para o desenvolvimento de pacotes que levarão o Node.js a um novo nível no rastreamento de operações assíncronas e no trabalho com o contexto.
Por exemplo, o pacote
cls-hooked permite organizar o uso de variáveis e contexto ao longo do ciclo de vida de uma operação assíncrona. O pacote
jaeger-client permite visualizar o processo de transmissão de uma solicitação através de sistemas, mesmo através de microsserviços e servidores (o padrão Javascript OpenTracing API 1.0 é implementado aqui).
Aqui está o material para descobrir mais sobre o uso da API async_hooks.
5. Entenda as mais recentes tecnologias “sem servidor” que já estão prontas para projetos sérios e capazes de matar o Kubernetes
Aqui, usamos os conceitos de FaaS (função como serviço, função como serviço) e "tecnologias sem servidor" como sinônimos, embora não signifiquem a mesma coisa. Em particular, a seguir, falaremos sobre serviços FaaS em nuvem.
Inicialmente, a tecnologia FaaS destinava-se a desenvolver micro-tarefas, e não a criar aplicativos de "microsserviço" completos. A crescente popularidade das plataformas FaaS levou a um aumento do interesse dos provedores de serviços em nuvem. As plataformas FaaS ganharam novos recursos. Como resultado, embora isso seja inesperado, existe a sensação de que em 2019 as plataformas FaaS podem se tornar a base para projetos sérios. Essas plataformas podem competir com o Kubernetes e podem ser usadas para hospedar aplicativos grandes? Alguns vêem na computação sem servidor e nas tecnologias FaaS algo completamente novo, mas, na prática, todo criador de um aplicativo em nuvem terá que fazer uma escolha entre as três tecnologias em 2019. Essa opção é, literalmente, apresentada nos sites dos provedores de serviços em nuvem. Ou seja, estamos falando sobre a escolha de uma das três opções:
- Servidor na nuvem normal (por exemplo, VDS da RUVDS)
- Kubernetes
- FaaS
Como resultado, em nosso tempo, é muito importante poder comparar os recursos do Kubernetes com o FaaS e antecipar as conseqüências da escolha de uma tecnologia específica.
6. Confira as inovações em JavaScript que virão padrão em breve.
Não posso me considerar um defensor da descoberta e do uso dos recursos mais recentes do idioma, pois às vezes o uso deles prejudica a simplicidade e a compreensibilidade do código. De tempos em tempos, porém, recursos JavaScript realmente valiosos aparecem (como a construção assíncrona / aguardada há dois anos), por isso é útil consultar
a lista de ofertas
do TC39 e o recurso
node.green para conhecer antecipadamente os novos recursos que podem ser adequados a você. Aqui está o que eu achei interessante:
- Agora, os campos de turma estão no 3 (último) estágio de aprovação; eles podem entrar no padrão em 2019.
- O tipo de dados BigInt também passa pelo estágio final da reconciliação. O uso de números desse tipo pode ajudar a organizar a interação com microsserviços ou qualquer sistema, durante o qual grandes números são usados.
- Os iteradores assíncronos e o método finalmente () da promessa já foram aceitos. Se você ainda não prestou atenção a eles - leia-os.
7. Domine pelo menos uma tecnologia para criar uma API. Preste atenção ao GraphQL
A API REST é uma ótima ferramenta para resolver uma determinada classe de tarefas. Ou seja, estamos falando sobre o gerenciamento de consultas e a modificação de registros nos bancos de dados. Seu sistema está focado em trabalhar com dados financeiros? Provavelmente, para garantir sua operação, é necessário observar as mais estritas restrições e usar um modelo de dados cuidadosamente desenvolvido que não permita ambiguidades. A tecnologia REST é adequada para você nesse caso, mas não se mostra muito bem em outras situações muito comuns, por exemplo, quando a execução da mesma solicitação pode levar ao recebimento de diferentes conjuntos de dados. O mesmo se aplica ao trabalho em condições de baixas velocidades de conexão, quando é necessário que o mínimo de dados possível seja transmitido ao trabalhar com uma determinada API. Tais situações incluem conexões entre computadores, onde a comunicação de alta velocidade vem à tona. Nesses casos, vale a pena mudar para algo novo? Não, não vale a pena. É melhor adicionar algo novo ao que já está em uso. Uma API não é uma arquitetura de aplicativo. Este é apenas um ponto de acesso ao aplicativo, o que significa que as APIs criadas usando diferentes ferramentas podem coexistir. Mesmo que todos eles sejam criados sobre uma única estrutura da Web como o Express.
Que tecnologia estudar? Provavelmente, nas condições atuais, vale a pena apostar na tecnologia GraphQL, que está se tornando cada vez mais popular. O ecossistema dessa tecnologia amadureceu significativamente, pois serve a alguns cenários de dados muito populares - como pesquisa dinâmica e interação com fontes de dados hierárquicas. Por outro lado, a tecnologia gRPC ainda é uma solução altamente especializada que é adequada para a comunicação entre servidores em situações em que, durante a troca de dados, é desejável transferir o mínimo possível de informações de serviço (por exemplo, estamos falando de sistemas de troca de dados com base no " editor-assinante "ou sobre aqueles em que as mensagens e filas de mensagens são usadas). Aqui estão algumas postagens úteis sobre esse assunto:
8. Usando testes de unidade e integração? Dê uma olhada nas novas técnicas de teste.
Você já está familiarizado com a pirâmide de teste, com testes de unidade, integração e de ponta a ponta? Se assim for - ótimo. Tudo isso está subjacente às estratégias de teste bem-sucedidas. No entanto, deve-se notar que, nos últimos 10 anos, o mundo do desenvolvimento de software mudou muito a sério e os modelos de teste permaneceram os mesmos, o que nos leva a perguntas sobre como testar microsserviços, aplicativos avançados da Internet e sistemas sem servidor. Algumas abordagens modernas de teste complementam o conjunto tradicional de tecnologias e outras podem até substituí-lo, melhorando assim a estratégia e os resultados do teste. Aqui está o que você pode ler e ver:
- Os sistemas de teste criados no padrão Contratos Dirigidos ao Consumidor ajudam a impedir que as APIs do servidor usadas por microsserviços ou clientes falhem.
- O teste usando snapshots pode ser usado não apenas no frontend, mas também em projetos de servidor.
- O teste de componentes é uma abordagem equilibrada para testar microsserviços.
- Aqui está um vídeo sobre abordagens modernas para testar projetos Node.js.
9. Alinhe seu sistema de monitoramento de aplicativos com as melhores práticas de SRE / DevOps
Em 2019, mesmo um aplicativo de tamanho médio pode consistir em dezenas de componentes. Para garantir o bom funcionamento dessa infraestrutura, ela deve ser cuidadosamente monitorada. Apesar da obviedade acima, a maioria dos desenvolvedores ainda não considera importante estudar e usar essas recomendações para monitorar aplicativos e criar um sistema de alertas sobre problemas que podem ser dados por especialistas responsáveis pela confiabilidade dos projetos da web. Por exemplo, os desenvolvedores geralmente se concentram em indicadores internos de desempenho do sistema, como velocidade do processador ou RAM, em vez de se preocupar com métricas que afetam diretamente os usuários finais. Em particular, estamos falando sobre a frequência de erros e atrasos. Isso é
chamado de "monitoramento baseado em sintomas". Esses indicadores orientados ao usuário são chamados às vezes de “sinais dourados” e você, possivelmente introduzindo um sistema de monitoramento, decide começar com a introdução dessas métricas. Aqui estão os materiais relacionados:
10. Melhore a segurança dos projetos, analisando-os do ponto de vista de um invasor, além de aprender a conduzir ataques e ferramentas de hackers
Se você não pode pensar como alguém que quer atacar seu sistema, significa que você não pode pensar como o defensor desse sistema pensaria. Em 2019, você não deve transferir tarefas para proteger projetos para terceiros, nem confiar apenas em analisadores de segurança estáticos. Hoje, existe um grande número de tipos de ataques (as últimas tendências nessa área são
ataques à infraestrutura de desenvolvimento e às npm). Ao mesmo tempo, os aplicativos mudam muito, muito rapidamente - ontem o projeto foi reconhecido como bem protegido e amanhã eles podem adicionar vários novos serviços da AWS, vários novos tipos de bancos de dados e uma nova função do IAM. Ao mesmo tempo, não será em breve analisar a segurança do projeto. O resultado é que os desenvolvedores representam o maior risco de segurança para seus próprios projetos. A solução para esse problema é o treinamento deles. Isso significa que todo desenvolvedor de projetos da web precisa levar a implementação de regras de segurança quase ao automatismo, e o que quer que ele faça, lembre-se sempre da segurança.
Depois de decidir seguir nessa direção, levar em consideração a segurança ao executar qualquer trabalho não é tão assustador. Diga, tendo se familiarizado com os métodos e ferramentas comuns de ataque, desenhe um diagrama da arquitetura do seu aplicativo e pense em como você o atacaria. Com o tempo, sem fornecer um relatório, você começará a levar em consideração os problemas de segurança, tomando todas as decisões de arquitetura e inserindo todas as novas linhas de código no editor. Aqui estão algumas idéias para gerenciar problemas de segurança:
- Experimente o OWASP ZAP - uma ferramenta multifuncional para pesquisar sistemas e hackers, que permite até mesmo um iniciante aprender o nível de segurança do aplicativo.
- Confira esta lista de recomendações de segurança do Node.js. para obter mais de duas dezenas de idéias de ataques e exemplos de código JavaScript.
- Agende uma reunião mensal de análise de ameaças em que a equipe do projeto estudará sua arquitetura e oferecerá ataques a ela. Se essa idéia parecer chata para você - você pode gamificar essas reuniões. Digamos que aqueles que encontram vulnerabilidade podem ser recompensados de alguma forma. Você também pode, por exemplo, dividir os participantes dessa reunião em duas equipes e organizar uma competição entre eles para encontrar vulnerabilidades.
11. Projete e implemente uma estratégia de atualização de pacote npm. 2018 mostrou que a pressa em atualizá-los é perigosa
Normalmente, as equipes de desenvolvimento aderem a uma das duas "estratégias" para atualizar os pacotes npm. Eles os atualizam o mais rápido possível após o lançamento de suas novas versões, às vezes até automatizam esse processo ou não possuem uma estratégia de atualização de pacote. Com essa abordagem, os pacotes são atualizados irregularmente e, iniciando esse processo, são guiados por algo como um pensamento repentino: "Devemos ser atualizados hoje?" Embora a primeira dessas abordagens pareça melhor que a segunda, inesperadamente se associou a um risco maior em 2018 do que a segunda. Problemas, como o que aconteceu com o pacote
flat-stream , foram descobertos pela comunidade em algumas dezenas de dias, e aqueles que não tinham pressa de atualizar estavam seguros.
Considere formalizar a estratégia para atualizar os pacotes dos quais seu projeto depende; considere o uso de ferramentas de automação para esse processo. Encontre o meio termo entre recusar atualizações e atualizar pacotes com muita frequência. Aqui, o programa
npq pode ajudá-
lo , que verifica os pacotes durante a instalação e fornece recomendações. Você pode dar uma olhada em projetos comerciais como o
greenkeeper . A desvantagem de tais soluções é que elas não podem adiar a instalação até o momento em que ficará absolutamente claro que um determinado pacote é seguro.
12. Dê uma olhada mais de perto na implantação em fases de projetos
Talvez em 2019 você considere razoável implantar projetos em produção usando um esquema em fases, e não enviando instantaneamente tudo o que estava antes no processo de desenvolvimento para um servidor de combate. Esse processo é chamado de "implantação canária", pois oferece um nível mais alto de proteção ao projeto do que a implantação simultânea de novo código. Geralmente distingue os três estágios a seguir:
- Implantação O novo código é implantado em um novo ambiente de produção isolado (no novo serviço Kubernetes, em um novo servidor virtual). Nesse estágio, o código ainda não serve a ninguém, portanto, falhas nele não podem causar danos.
- Teste. Agora, vários especialistas podem trabalhar com o novo código em condições o mais próximo possível dos reais, pois o código é implantado na produção.
- Lançamento Depois que o teste mostra a operacionalidade do novo código, ele recebe gradualmente acesso a um número crescente de usuários e, após verificar que ele funciona com confiabilidade suficiente, sua versão antiga é gradualmente removida de uso.
Um ponto importante a ser destacado aqui é que fazer implantações de canários em grande escala em 2019 ainda será um prazer muito caro. O fato é que isso requer coordenação do trabalho dos elementos de infraestrutura do projeto - como roteamento e monitoramento. Portanto, se você deseja aplicar uma técnica semelhante, comece com uma implantação simples e parcialmente manual em canário. Em particular, isso consiste no fato de que, após a conclusão bem-sucedida dos primeiros testes, levando em consideração os indicadores de monitoramento, é realizada a adição manual de servidores com uma nova versão do software no sistema. Leia mais sobre lançamentos de canários
aqui . Se você deseja automatizar o processo de execução desses lançamentos, preste atenção na plataforma
Spinnaker .
13. Confira a tecnologia Kubernetes que conquistou o mundo.
Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. —
. K8S — , :
, , Kubernetes, .
14. -,
- — . , .
15. , , ,
, — . , . . , (,
tensorflow.js brain.js , , ).
16.
, . , , . , — .
17. Linux, —
Linux- , , . — , ( — ), Docker, . , , , , , .
, Linux.
18. , Node.js
( Node.js): « . , ». , , ( ). , Node.js, , V8 libuv. , 2019 — , Node.js, , , libuv. , , , Node.js - , .
, .
, npm- C/C++.
Node.js.
Node.js RUVDS.
19. ,
, , . , , , , , . , , , , . JavaScript-, . , JavaScript, . , , TypeScript . flow , , . , - flow, , , , « , ». ? , , «
». , - . , , , — . . , - , , , . , . , 2019 , — .
.
, . — , , , , , , . , , , , , .
Sumário
19 , Node.js-, - , 2019 . , - , .
Caros leitores! Node.js- 2019 ?
