Skip to content

Instantly share code, notes, and snippets.

@igorlima
Last active August 29, 2015 14:10
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save igorlima/938da720be3513e4556f to your computer and use it in GitHub Desktop.
Save igorlima/938da720be3513e4556f to your computer and use it in GitHub Desktop.

A equipe StrongLoop recebeu uma grande quantidade de feedback da comunidade no ano passado e ultimamente nós (equipe StrongLoop) temos pensado muito sobre esses feedbacks. Nós perguntamos a nós mesmo "como que pode uma empresa, desenvolvedores individuais e membros de uma comunidade ser os contribuidores mais ativos do Node que consequentemente beneficia a todos? Desde desenvolvedores individuais a clientes de um ecossistema de fornecedores que oferece serviços e produtos ao redor do Node?"

O resultado é este post onde nós já colaboramos com colegas de trabalhos, tanto dentro quanto fora da StrongLoop, para tentar articular o que achamos que a StrongLoop pode fazer de mais útil para ajudar a comunidade a levar o Node para um outro nível.

É claro que não estamos falando do responsável do projeto ou da comunidade como um todo. Estamos sim colocando uma discursão em pauta, como membros da comunidade do Node, para que você possa entender melhor onde pretendemos concentrar os nossos esforços de desenvolvimento no futuro.

Um futuro governado por APIs e JavaScript

Como uma série de recursos do Node tem evoluído ao longo dos anos, e a comunidade tem crescido, o Node emergiu como a tecnologia preferida para o front-edge. Os casos de uso de um front-edge incluem:

  • Aplicações web de página única (aplicações single-page)
  • Sensores e dispositivos embarcados
  • Aplicações que exigem recursos em tempo real
  • Servidores de API – que é a "cola" que une os dispositivos com o backends e os serviços

Achamos que os requisitos desses casos de uso irão naturalmente girar em torno dos desenvolvedores para a programação governada por APIs e JavaScript.

  • A capacidade de escrever aplicações isomórficas: com o JavaScript executando no navegador, no dispositivo e no servidor significa uma maior oportunidade não só para a reutilização de código, mas também para o reaproveitamento das habilidades dos desenvolvedores. Com o Node, cada desenvolvedor JavaScript tem o potencial para se tornar um desenvolvedor server-side. O JavaScript como full-stack continua ganhando popularidade como por exemplos as pilhas MEAN e BACN.

  • Suponha que às vezes os dispositivos estarão off-line: o Node pode ajudar a facilitar a sincronização de dados em dispositivos que nem sempre estará conectado a um back-end.

  • Dispositivos conversando com dispositivos: como nós estamos aproximando rapidamente de uma época onde haverá mais dispositivos e sensores trocando dados entre si do que a troca de dados iniciada por seres humano, os recursos de eventos do Node brilham ao ajudar a fazer coisas como conectar carros e possíveis dispositivos inteligente de automação residencial.

  • SDKs com recursos fully-featured: Facilita aos desenvolvedores que estão familiarizados com plataformas nativas como iOS e Android na integração de aplicações Node, sem exigir uma curva de aprendizagem.

O que se segue são as oportunidades e desafios que acreditamos que exista para desenvolvedores e organizações similares, interessadas em levar o Node para um próximo nível.

Módulos que clicam juntos, trabalham juntos

Star Wars

Um kit de Lego, por exemplo, possui um monte de peças de alta qualidade, que pode ser montadas como quiser. Caso você siga as instruções recomendada na embalagem, uma nave legal pode ser construída (ou, caso contrário, você pode ignorar essas instruções e confiar em seus truques de mestre para montar o que é mostrado na tampa da caixa, usando todas as peças do seu Lego). Ou também você pode construir a nave e decidir personalizá-la um pouco à seu gosto.

Ao fazer as coisas na maneira do Node, significa que tudo deve ser decomposto em forma de pequenos pedaços para que possam ser reutilizáveis, como APIs e módulos, para então fazer com que essas pequenas peças trabalhem muito bem em conjunto. Com isto em mente estamos evoluindo a nossa abordagem; Nós originalmente agrupávamos todas as nossas ofertas em um único download combinado com o Node. Hoje, distribuímos tudo como peças combináveis via NPM e, ao mesmo tempo, o conjunto de módulos apoiado pela StrongLoop que juntos formam uma plataforma composta estável que as empresas estão usando para escrever servidores de API e aplicações web completas. Confira os exemplos do framework LoopBack de como construir servidores de API (especialmente para dispositivos móveis) ou o framework Krakenjs, desenvolvido pelo PayPal, como exemplo de como criar um middleware web escalonável.

Instrumentação

Como cada vez mais os desenvolvedores estão colocando aplicações Node em produção, a capacidade de ganhar visibilidade para suas aplicações tornou-se o refrão mais comum que ouvimos. Não é suficiente (ou agradável) passar a bola e pedir que os desenvolvedores usem um depurador de nível de sistema ou se derramem através dos heap dumps (despejos de pilha). Em vez disso, o Node precisa de uma primeira classe, ainda que seja uma forma nativa para se certificar de que o servidor e o aplicação estejam operando bem de tal forma que seja fácil de descobrir o que está errado e quando não está. Como uma comunidade, isso certamente é uma área onde nós podemos colocar o Node em um novo patamar.

Boa parte de nossos recente trabalhos tem sido direcionado para esse objetivo uma vez que específicos hooks não podem ser realmente colocados em módulos. Alguns frutos podem ser visto e mostrado em nosso console de monitoramento e operações, o StrongOps. Tudo desde CPU e transação de perfil até o modo de debugar através do node-inspector e detecção de erro. (O node-inspector tem sido um verdadeiro esforço da comunidade, foram mais de 28 autores que ajudaram a entregar 15 novas funcionalidades nessa versão mais recente). Qualquer pessoa pode usar esses hooks e módulos, e estamos ansiosos para ver um maior envolvimento da comunidade em questões de instrumentação e de gerenciamento de tempo de execução.

E o que mais? Estamos trabalhando em várias características chave de instrumentação:

  • auditoria
  • segurança
  • memória de criação de perfil
  • inspeção de pilha

Nós adoraríamos ouvir as suas idéias e, também, saber com qual dessas áreas listadas acima você está trabalhando!

Multi-processo e multi-servidor

No último ano, a comunidade tem nos ajudado com vários experimentos de validações em como o Node pode ser melhorado para utilizar uma maior capacidade de processamento, dentro e através de máquinas, embora ainda honrando o modelo de programação que nos trouxe até aqui e ainda mantendo a compatibilidade. Todos nós podemos se beneficiar com atalhos e módulos, de tal forma que nem precisamos criar a nossa própria estrutura de computação distribuída.

Strong-mq foi o nosso primeiro passo nesse sentido, a padronização de uma interface de fila de mensagem. Melhorar a API do Node Cluster foi um passo a mais nesta direção. Estamos trabalhando em alguns conceitos adicionais que deve facilitar o descarregamento de trabalho no loop principal de eventos, com baixos custos e com gerenciamento de cluster. Finalmente, começamos a dobrar os recursos de gerenciamento de cluster em nosso console de monitoramento, o StrongOps.

Multi-processo e multi-servidor

Mas o que mais pode ser feito. Leia mais sobre essas possibilidades na seção de "modelos de programação alternativa" abaixo.

Configuração e ferramentas de ALM

É super simples começar a trabalhar com um único servidor de Node em execução, e o NPM torna isso fácil com a incorporação de módulos de terceiros. Mas há muitas armadilhas ao longo do caminho, quando se trata de uma aplicação Node em um ciclo de vida típico de desenvolvimento, teste e implantação, além de como lidar com os upgrades (atualizações). Sem falar da necessidade de incluir recursos "avançados" como escala automática ou a implantação de alguns apps no mesmo servidor, em namespaces diferentes. Há uma real necessidade para tornar a configuração destes tipos de tarefas mais fácil.

Até agora, muitos projetos tiveram que se desenrolar com suas próprias ferramentas de configuração. Um primeiro passo para ajudar a tornar isto mais simples é o módulo strong-supervisor. Obviamente, há muito mais trabalho a ser feito aqui, mas estamos trabalhando para fazer contribuições significativas neste ponto, trabalhando em conjunto com alguns clientes de grande porte. Esperamos que os membros da comunidade continuem trazendo soluções nesta área, em que todos se beneficia e leva vantagem.

Conectividade com dispositivos

Node é sobre E/S e conectividade. E desde que a interação do usuário está mudando para os dispositivos, incluindo tablets, dispositivos wearables e computadores embarcados “near edge”; os desenvolvedores do Node estão tentando fazer com que o Node leve facilmente os dados entre esses dispositivos. Para tornar isto ainda mais fácil, podemos criar um esquema de dados compartilhados, ou "modelo", entre front e back-end. Hoje temos SDKs que fazem somente isso para dispositivos baseados em Android e iOS e compartilha um modelo front-to-back definido pelo usuário que aparece no cliente como um objeto nativo. Mas há muito ainda para chegar na integração de dispositivo. O que você acha?

Conectividade com backends

Enquanto o Node tem um ótimo entrosamento com o MongoDB, ele ainda não é tão maduro para integrar com outras tecnologias. Acreditamos que isso esteja ficando cada vez mais importante para as organizações que possuem sistema de armazenamentos de dados legados e tecnologias legadas, os quais ainda vão existir durante os próximos anos. O nosso conector de banco de dados Oracle foi um bom primeiro passo na integração entre armazenamentos de dados de empresas tradicionais e novas tecnologias front-ends.

Encapsulamos o módulo jugglingdb e o estendemos para loopback-datasource-juggler para fornecer uma interface consistente entre backends e bancos de dados para serviços de armazenamento em APIs REST. Ele não só tem a conectividade, como também a descoberta de schema e a exposição de uma visão normalizada de seus backends para JSON. Como desenvolvedor você pode tocar em qualquer um desses níveis, usando a conveniência lhe convem.

Estamos muito empolgados para seguir adiante em direção a todos os tipos de modelagem de fontes de dados numa mistura de objetos com relacionamentos. Há muito trabalho a ser feito nesta área, e esperamos que a comunidade e fornecedores desempenhem um papel crítico na evolução dessa "cola" e história de conectividade. Em particular, vemos uma necessidade para uma melhor conexão entre o Node e Java já que muitas bibliotecas robustas já estão disponíveis.

Imagine a possibilidade de conectar através do Node com qualquer outra coisa que tenha um conector JCA, que tenha dados traduzido em JSON, que seja capaz de ser misturado com qualquer módulo Node e que se expõe como uma API REST orientada ao cliente. Este é o tipo de direção que faria o Node mais acessíveis aos desenvolvedores em integrações com backends empresariais.

Deixe-nos sabe quais são seus pensamentos aqui. Como você quer se conectar? O que você quer conectar?

Integração de recursos ES6

ES6 e outras propostas de avanços pro JavaScript tem muitos recursos úteis. Assim que os runtimes do JavaScript implementar isso, abre a possibilidade de integrá-los no núcleo e no ecossistema do módulo. Por exemplos os generators, import, attributes, classes, hashmaps, símbolos e desestruturação de atribuições.

Existem também vários esforços em torno de typing tais como TypeScript e tipo de annotations. Temos feedback de diversos desenvolvedores que querem usar typing em seus projetos para ser capaz de detectar o quanto antes possíveis erros no ciclo de vida da aplicação.

(Re)convergência com o navegador

Com o (re) surgimento de grande clientes, de aplicações de página única, aplicações móveis híbrida (por exemplo, Cordova) que usam um ou vários webviews como interface ao usuário, e a fusão do contêiner do navegador com o sistema operacional (exemplos como o ChromeOS e o FirefoxOS), acreditamos que vamos ver a necessidade de conceitos de programação melhorada. Não apenas no lado do servidor do JavaScript, mas do lado do navegador também. Se estamos usando os mesmos pacotes e runtimes, ambos os lados devem ser capazes de evoluir mais rápido.

Imagine se houvesse conceitos padronizados e APIs. Talvez um sistema de módulo compartilhado, uma forma padrão de tratar erros, e soluções que permitissem que o desenvolvedor aproveitasse vários núcleos não só do lado do Node, mas também do lado do navegador. Não importa de que lado você esteja trabalhando, seja front-end ou “front edge”, os desenvolvedores não deveriam re-aprender como fazer as coisas.

Modelos de programação alternativos

Estamos procuramos maneiras de adicionar de forma incremental ao modelo de programação do Node: relatório de erros, tratamento de erros e opções para controle de fluxo, preservando a compatibilidade com módulos existentes e estendendo as capacidades que melhoram a observabilidade. Ao mesmo tempo, quando os recursos ES6 como generators e o yield ficarem disponíveis, deve ajudar o gerenciamento dos callback hell, evitando os loops de evento bloqueados.

Aqui está um resumo para alguns desses pensamentos. Alguns exemplos de pseudo código para cada tipo de abordagens, e que talvez funcionem.

Zones and Co-Routines

new Zone(function* () {
let google = get('google.com');
let yahoo = get('yahoo.com');
 
console.log(‘google.com’s length: %s yahoo.com’s length: %s, yield google, yield yahoo);
})
.catch(function(err) {
console.log('Error: ' + err.message);
})

Este exemplo usa uma idéia chamada de Zone que agrupa operações assíncronas em uma unidade lógica. Combinando isso com as co-rotinas ES6 baseadas em generator, temos uma forma de estruturação de código de boa legibilidade, uma inspeção em tempo de execução e a facilidade no tratamento de erro muito mais fácil.

Micro Processes

// Runs in a separate "process", a light-weight thread. Doesn't share
// anything with the parent process unless explicitly shared.
function fetch(url) {
Message.send(Process.ppid, Http.get(url).body);
}
 
let err = Process.wait(function() {
let google = Process.go(fetch, 'http://google.com');
let yahoo = Process.go(fetch, 'http://yahoo.com');
// A run-time error in one of the inferior processes will tear down
// this process when we call receive() and return an exception object
// to the caller of Process.wait().
if (google.receive().length > yahoo.receive().length) {
console.log('google > yahoo');
}
});
 
if (err) {
console.log('Error: ' + err.message);
}

Este exemplo também atinge uma boa legibilidade e fornece um padrão de agente de passagem de mensagens para a distribuição de trabalho durante a limpeza de erro para o framework.

Classes and Attributes

@Replicate
@Inject(Database)
@BelongsTo(Category, {as: 'category'})
class Product extends Model {
canModify* (ctx) {
return (yield ctx.user()).id === yield this.owner;
}
}

Este exemplo usa atributos combinados com um generator para manter uma boa legibilidade e compactar o código para as operações paralelas e oferecer a possibilidade de melhorar a inspeção do tempo de execução.

Estamos empolgados que outros projetos estejam trabalhando para o avanço do modelo de programação, desde o tracuer compiler até o Koa.js. Deixe fluir os bons debates sobre modelo de programação! Se este assunto é de seu interesse, por favor nos avise.

O que está acontecendo para que essa visão pro futuro se torne uma realidade?

Para obter muitas dessas ideias plenamente realizadas, é preciso um esforço concentrado da comunidade Node como um todo. A maior parte do trabalho árduo obviamente vai acontecer fora da StrongLoop, por desenvolvedores que já lançaram mais de 61.000 módulos npm até agora. Na StrongLoop, estamos empenhados em fazer nossa parte ajudando que essas idéias se tornem uma realidade. Será que estamos em condições de contribuir e ajudar a moldar o futuro Node?

A primeira compilação da versão v0.11 saiu em março de 2013, na mesma época que lançamos o StrongLoop. Você pode ver todas as contribuições, no Github, para o lançamento da versão v0.12 feitas por Ben Noordhuis, Miroslav Bajtos, Sam Roberts, Ryan Graham e eu:

Além de muitas melhorias de estabilidade, do ponto de vista de funcionalidade, veja a lista de algumas das coisas mais legais para o lançamento da versão v0.12, as quais os desenvolvedores da StrongLoop foram os principais autores:

Acreditamos que o grande esforço e engajamento da comunidade Node vai fazer com que um número crescente de empresas utilize o Node em produção, e aumente o nosso compromisso em continuar com os avanços do Node. Juntos podemos levar o Node para um outro nível!

E o que mais?

  • Interessado em aprender mais sobre a nossa visão para o futuro do Node e como isso pode beneficiar a sua organização? Mande-nos um comentário e deixe a conversa fluir.
  • Quer saber mais sobre o que está por vim no lançamento da versão v0.12? Confira meu vídeo do início deste ano e veja o que você pode esperar dessa nova versão.
  • Sempre há um novo conteúdo técnico sendo postado aqui, siga-nos no Twitter ou se cadastre em nossa newsletter para não perder nenhuma nova publicação.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment