What’s New in the LoopBack Node.js Framework – June 2015

Curious what new developments are happening with the LoopBack project? Here’s a curated selection of the most important changes that have been made to LoopBack in the past few weeks.

LoopBack Core

Enable Auth

We changed app.enableAuth to automatically setup all required models not attached to the app nor a datasource. The purpose of this change is to make it easier to set up authentication from code that does not use slc loopback project scaffolding, such as unit tests.

To use this new option, just provide the name of the data source to use for these models.  For example:

Observer API

We made several improvements to the hook API. Including the ability to skip other observers by calling context.end(). Now you can also notify multiple observers by passing an array of operation names (for example, notifyObserversOf(['op1', 'op2'])).

Strong Remoting

We added a couple of new features to strong-remoting and remote methods in LoopBack.

Default Status Codes

Now you can define both a status and errorStatus in the HTTP options of your remote method.

Header and Status Argument Targets

To set a header or the status code for an HTTP response, now you can specify the target of your callback argument to either header or status.

Here is an example of both default status codes and argument targets.


We extracted the implementation of data filtering from the memory connector to a new module called loopback-filters. Using this module, you can now filter arrays of objects using the same filter syntax supported by MyModel.find(filter).  We’ll soon be converting all LoopBack modules to use loopback-filter, so it will become the common “built-in” filtering mechanism.

LoopBack supports a specific filter syntax: it’s a lot like SQL, but designed specifically to serialize safely without injection and to be native to JavaScript.  Previously, only the PersistedModel.find() method (and related methods) supported this syntax.

Here is a basic example using the new module.

For a bit more detail, let’s say you are parsing a comma-separated value (CSV) file, and you need to output all values where the price column is between 10 and 100.  To use the LoopBack filter syntax you would need to either create your own CSV connector or use the memory connector, both of which require some extra work not related to your actual goal.

Once you’ve parsed the CSV (with some module like node-csv) you will have an array of objects like this, for example (but with, say, 10,000 unique items):

To filter the rows you could use generic JavaScript like this:

This is pretty simple for filtering, but sorting, field selection, and more advanced operations become a bit tricky.  On top of that, you are usually accepting the parameters as input; for example:

You can rewrite this easily as a LoopBack filter:

Or if you just adopt the filter object syntax as user input:

But loopback-filters supports more than just excluding and including.  It supports field selection (including / excluding fields), sorting, geo/distance sorting, limiting and skipping.  All in a declarative syntax that is easily created from user input.

As a LoopBack user this is a pretty powerful thing. Typically, you will have learned how to write some complex queries using the find() filter syntax; before you would need to figure out how to do the same thing in JavaScript (perhaps using a library such as underscore). Now with the loopback-filters module, in your client application you can re-use the same exact filter object you were sending to the server to filter the database without having to interact with a LoopBack server at all.

Middleware generator

The new LoopBack middleware generator adds a middleware configuration to an existing application.

The tool will prompt you to:

  • Select the phase to use for the middleware.
  • Add a list of paths.
  • Add parameters.

See more about the new middleware generator in the documentation.


The loopback-workspace module provides the backend functionality for Arc API composer and slc loopback

The default template for generating LoopBack projects now includes default lookup paths for mixins. The defaults are the following:

  • loopback/common/mixins
  • loopback/server/mixins – the first two will include loopback core mixins.
  • ../common/mixins relative to your project.
  • ./mixins relative to your project.

Note that the last two paths are relative to your project (just like modelSources).

We also added support for middleware.json. This lays the groundwork for support for generating middleware.json files with Arc API Composer and with slc loopback.

DataSource Juggler

Persist Hook

We added a new “persist” hook. Observers are notified during operations that persist data to the datasource (for example, create, updateAttributes). Don’t confuse this hook with the existing “before save” hook:

  • before save – Use this hook to observe (and operate on) model instances that are about to be saved (for example, when the country code is set and the country name not, fill in the country name).
  • persist – Use this hook to observe (and operate on) data just before it is going to be persisted into a data source (for example, encrypt the values in the database).

Loaded Hook

We have also just added a new “loaded” hook. Observers are notified right after raw data is loaded or returned from the connector and datasource. This allows you to do things like decrypt database values before they are used to create a model instance.

Here is a filtered changelog including important changes to the juggler.

  • PR#611 Dedupe ids args of inq for include
  • Released 2.29.1
  • PR#584 add test suite for scope – dynamic function
  • PR#588 Fix pagination on collections with many-to-many relationships
  • PR#604 Fix destroyById not removing instance from cache
  • PR#609 Don’t silently swallow db errors on validation
  • Released 2.29.0
  • PR#602 Enhance the apis and add more tests
    • End observer notification early
    • Allow multiple notifications in a single call: notifyObserversOf([‘event1’, ‘event2’])
  • PR#600 Fix toJSON() for level 3 inclusions
  • PR#598 Mixin observer apis to the connector
  • PR#597 Enhance fieldsToArray to consider strict mode
  • Released 2.28.1
  • @cbb8d7c Remove dep on sinon
  • PR#586 Add new hook persist
  • Released 2.30.1
  • @8302b24 Pin async to version ~1.0.0 to work around context propagation
  • Released 2.30.0
  • PR#618 Allow 0 as the FK for relationships
  • PR#626 Fix for issues #622 & #623
  • PR#630 Promisify ‘automigrate’


We added a new “execute” hook to the connector API. It allows you to observe the low-level connector.execute() method. See the documentation for more information.

Below is a filtered changelog including important changes to connectors.


  • @b40f92b Add before and after “execute” hooks for the underlying soap invocation
  • PR#20 bump(soap) bump node-soap version from 0.8 to 0.9


  • Released 1.9.0
  • PR#33 Add before and after “execute” hooks


  • @84a1ab0 Add before and after “execute” hooks
  • Released 1.9.2
  • @8a55f92 Update to memwatch-next for node 0.12 compatibility
  • Released 1.9.1
  • @5d907cf Update deps
  • Released 1.9.0
  • @331e158 Replaced ensureIndex() with createIndex()
  • Released 1.11.0
  • PR#142 Add a workaround for auth with multiple mongos servers
  • PR#141 Autoupdate and automigrate now respect settings.mongodb.collection


  • @111f8c2 Add better support for the Date type
  • Released 2.2.0
  • PR#88 Make sure UTC is used for date


  • Released 2.2.0
  • @2fc9258 Update deps
  • PR#18 Add before/after hooks for connector native operations
  • Released 2.1.2
  • @a5f11ac Put request with non existent properties no longer results in error
  • Released 2.1.1
  • @a62e06d Improved query support for Date


  • Released 2.8.0
  • PR#130 Port can’t be number checked to support iisnode
  • @44f733f Support iisnode using named pipes as PORT value (Jonathan Sheely)
  • Released 2.8.1
  • PR#133 Better debug output when loading complex configurations

Component OAuth2

  • Released 2.2.0
  • @83635b0 Tidy up the models to work with MySQL
  • Released 2.1.1
  • @a32e213 Allow models to be customized via options
  • Released 2.1.0
  • @32fcab9 Clean up oAuth2 client app attributes
  • Released 2.3.0
  • @807762d Remove auth code after 1st use
  • @f613a20 Allow options.scopes to be a custom function
  • Released 2.2.1
  • @79a7df8 Allow options.userModel/applicationModel to be strings
  • Released 2.0.0
  • @e5da21e Change license to StrongLoop

Other Module Changes

  • loopback-component-storage
    • PR#74 Bugfix: Cannot read property ‘forEach’ of undefined
    • Released 1.5.0
    • PR#70 Add missing finish event when uploading to s3
  • loopback-testing
    • PR#47 Add withUserModel to extend user related helpers
    • PR#51 use findorCreate to create roles
    • PR#45 Update helpers.js
  • loopback-component-passport
    • Released 1.4.0
    • PR#70 feature: Make email optional
  • loopback-gateway
  • loopback-sdk-angular
    • Released 1.4.0
    • PR#138 Add createMany method
  • loopback-component-push
    • PR#88 Pass contentAvailable through to APNS
    • @e9022a0 Forward “contentAvailable” and “urlArgs” to APNS
    • @08e73ee Update deps

You can help too!

LoopBack is an open source project welcoming contributions from its users. If you would like to help but don’t have any own itch to scratch, then please pick one of the issues labelled as “Beginner Friendly”, see this github view for a full list.

The full changelog

As always, you can find the full list of changes at http://strongloop.github.io/changelog/


Como criar e executar imagens Docker do Gerenciador de Processo da StrongLoop

Caso você não tenha acompanhado as últimas novidades, anunciamos recentemente uma nova versão do Gerenciador de Processo StrongLoop.

O que é o Gerenciador de Processo da StrongLoop? é um gerenciador corporativo runtime para processo Node.js em produção. O Gerenciador de Processo da StrongLoop foi construído para manipular tanto o escalonamento vertical e horizontal de suas aplicações Node com facilidade.

Um dos recursos mais interessantes da nova versão é o suporte ao Docker.

docker image

Neste blog vou mostrar como instalar e usar a imagem oficial do Docker do Gerenciador de Processo da StrongLoop. Pronto para começar?

curl -s https://strong-pm.io/docker.sh | sudo sh

O serviço criado vai utilizar a porta 8701 para a API do Gerenciador de Processos e a porta 3000 para a sua aplicação. Se o servidor for reinicializado, o gerenciador de processo será reiniciado automaticamente.

Simples assim!

Bom, só isso não iria satisfazer aqueles que queiram saber como as coisas funcionam, não é? Então, eu vou explicar como aquele pedaço de script faz todo o trabalho, mas para isso vamos ter que fazer isso de um jeito mais difícil!


Configurar um servidor pode ser desencorajador, e instalar o Node em um servidor nem sempre é tão lindo como um passeio no parque. Felizmente, estamos falando sobre o Docker aqui, então vamos balançar uma varinha de condão e fazer com que todos os nossos problemas vão embora! Bom, nem todos os problemas, mas pelo menos alguns. Veja o que é preciso ter no servidor:

  • Um host (físico ou virtual) capaz de rodar o Docker. Eu recomendo algo baseado no RHEL/Fedora devido a proteção extra oferecida caso o seu container do Docker estiver quebrada.
  • Só isso! E não é preciso instalar o Node no servidor!

Veja o que é necessário em sua estação de trabalho:

  • Node (então você pode instalá-lo via npm install -g strongloop)

Já que este artigo é sobre deploy, e não sobre desenvolvimento então eu não vou cobrir essa etapa de instalação do Node em seu ambiente de desenvolvimento.


Aqui está a receita de bolo:

  • Instalar o Docker
  • Instalar a imagem do Docker do strong-pm
  • Fazer o deploy de sua aplicação

Instalando o Docker

Há muitos (muitos, muitos) artigos escritos sobre como instalar o Docker. Pessoalmente, eu encontrei a documentação oficial muito melhor. Se você está com pressa e está rodando o Ubuntu, Debian, Linux Mint, Fedora, AWS Linux, CentOS ou RHEL e se você estiver executando a versão que foi lançada no ano passado ou superior, há uma linha de comando que você pode usar para instalar:

curl -sSL https://get.docker.com/ | sudo sh

Se você não estiver com sorte e isso não funcionar para você, você provavelmente vai ter que ler a documentação.

Fica aqui uma dica! Eu recomendo seguir as instruções para o Docker sudo-less.

Instalando a imagem do Docker strongloop/strong-pm

Em suma, o que precisamos fazer agora é baixar a imagem do Docker do strong-pm, inicializá-la e depois configurar um script de inicialização para certificar que será executada toda vez que o servidor for reiniciado.

Convenientemente, se o Docker é instruído a executar uma imagem que não tem sido carregada ainda, ele vai fazer isso automaticamente. Isso significa que você pode cobrir esses dois primeiros passos com o seguinte comando:

Ótimo! Agora você tem a imagem do Docker strongloop/strong-pm, e um novo container inicializado em background (–detach) com o nome my-app-pm. Além disso, já foi dito para publicar o containercom as portas 8701 e 3000 e o host com as portas 8701 e 3000, respectivamente.

Caso você não se importa da sua aplicação voltar logo após uma reinicialização do servidor, e queira terminar essa parte por aqui, então você pode ir direto para a seção “Fazendo o Deploy de sua aplicação”.

Se você quiser configurar algo mais próximo de produção, nós temos um passo a mais a seguir.

Se você se preocupa com o tempo de atividade de sua aplicação, então o mínimo que pode ser feito é certificar-se de que a aplicação irá reiniciar caso ela trave. A boa notícia é que você já está executando sua aplicação em um gerenciador de processos que vai reiniciar a sua aplicação para você. Mas que tal uma reinicialização do servidor? Nenhuma quantidade de JavaScript pode te salvar de uma queda de energia, então você tem que buscar ajuda no sistema operacional.

Aí que entra o Upstart e o systemd. Se você teve sorte suficiente ao digitar a linha de comando da seção “Instalando o Docker”, então há uma boa chance de você está executando um sistema que já vem com o Upstart.

Se você já usou o ‘systemd’ Kool-Aid, então você pode seguir essas instruções.


Se você estiver com pressa, você pode simplesmente copiar e colar o exemplo a seguir em/etc/init/strong-pm-container.conf`:


Você vai precisar criar um destino como este:

Parecido com o que foi feito na seção Upstart, aqui será tão simples quanto, você provavelmente só precisa copiar o exemplo acima do systemd e colar em /etc/systemd/system/strong-pm-container.service.

Fazendo o Deploy da aplicação

Tudo bem, agora que instalamos o Docker e uma instância do Gerenciador do Processo StrongLoop, estamos prontos para o deploy da aplicação. Esta etapa é fácil:

slc deploy http://docker-host:8701/

Agora que você já sabe o jeito mais difícil, vai poder sempre usar o script que apresentamos no início do blog. Tenha um feliz deploy!

E o que mais?

Assista uma demonstração! Confira este curto vídeo que vai lhe dar uma visão geral do Gerenciador de Processo da StrongLoop.

Cadastre-se no webinar! “Melhores práticas para fazer deploy de aplicações Node.js em produção” em 16 de abril com a StrongLoop e o desenvolvedor do núcleo Node, Sam Roberts.

Nas próximas semanas, procure aprimorar ainda mais sobre o Gerenciador de Processo da StrongLoop e seus recursos runtime. Por enquanto, aqui está uma lista de alguns artigos técnicos adicionais para você aprofundar com mais detalhes sobre como aproveitar ao máximo este lançamento:

Como fazer deploy de aplicações Express com o Gerenciador Processos StrongLoop

  • Neste blog vou mostrar como fazer deploy de aplicações Express.js em um cluster da Digital Ocean e como gerenciar os processos usando o Gerenciador de Processos da StrongLoop.

    O que é o Gerenciador de Processo da StrongLoop? é um gerenciador corporativo runtime para processo Node.js em produção. O Gerenciador de Processo da StrongLoop foi construído para manipular tanto o escalonamento vertical e horizontal de suas aplicações Node com facilidade.

    Configurando o seu droplet na Digital Ocean

    • Cadastre-se ou faça o login na sua conta da Digital Ocean caso já tenha uma
    • Crie um droplet e acesse via ssh sua instância
    • Instale a versão mais recente do Node.js usando o gerenciador de pacotes de sua preferência
    • Instale a versão mais recente das ferramentas CLI do Gerenciador de Processos StrongLoopcom o comando abaixo:

    npm install -g strong-pm

    • Tire um snapshot de seu droplet, assim você não vai ter que reinstalar essas ferramentas da próxima vez

    Inicie o servidor remoto strong-pm

    sudo sl-pm-install [options]

    Este comando irá:

    • iniciar sua aplicação na inicialização
    • reiniciar a sua aplicação caso trave por inatividade
    • fazer o log das saídas da aplicação stdout e stderr
    • certificar que o daemon do strong-pm está sendo executado como o usuário sem privilégios dostrong-pm
    • ajustar os limites do descritor de arquivo
    • ativar o core dumps do daemon, caso seu sistema esteja configurado para isso

    Depois de instalar o Gerenciador de Processo como um serviço, inicie o servidor pm:

    image 1

    Agora, configure um ambiente de desenvolvimento local

    Instale as ferramentas CLI da StrongLoop em sua máquina de desenvolvimento local.

    npm install -g strongloop

    No diretório de sua aplicação execute slc arc, abrindo-o por padrão em uma janela de um navegador web.

    image 2

    Build & Deploy

    Logo na página inicial do StrongLoop Arc, clique na guia Build & Deploy.

    Agora, você pode fazer o deploy de sua aplicação Express, construindo um arquivo tar ou usando ogit caso sua aplicação esteja em um repositório git. Toda vez que a aplicação for compilada com êxito, faça o deploy para seu servidor pm digitando o nome do host, o número da porta e o número de processos.

    image 3

    Gerencie seus Processos

    Quando você fizer o deploy com êxito, alterne para a guia “Process Manager”. Adicione o nome dohost e a porta do seu servidor pm e clique em “Activate”. Os IDs de seus processos, agora, devem estar listado na coluna PID.

    image 4

    Aplicação com múltiplos clusteres

    Se você deseja executar sua aplicação em vários servidores, você pode criar droplets copiando a imagem criada na Digital Ocean anteriormente. Inicie o servidor pm e faça o deploy de suas aplicações em cada um dos seus servidores pm. Depois de fazer o deploy de suas aplicações, adicione-as na GUI do Gerenciador de Processos. Agora você pode verificar o status de sua aplicação, redimensionar, iniciar, parar e reiniciar cada cluster utilizando a página do Gerenciador de Processos.

    image 5

    E o que mais?

    Assista uma demonstração! Confira este curto vídeo que vai lhe dar uma visão geral do Gerenciador de Processo da StrongLoop.

    Cadastre-se no webinar! “Melhores práticas para fazer deploy de aplicações Node.js em produção” em 16 de abril com a StrongLoop e o desenvolvedor do núcleo Node, Sam Roberts.

    Nas próximas semanas, procure aprimorar ainda mais sobre o Gerenciador de Processo da StrongLoop e seus recursos runtime. Por enquanto, aqui está uma lista de alguns artigos técnicos adicionais para você aprofundar com mais detalhes sobre como aproveitar ao máximo este lançamento:

Announcing Transaction Tracing for Node.js Beta

At StrongLoop, we develop tools to support development and operations throughout the entire lifecycle of API development. Initially, we released Arc Profiler to help you understand performance characteristics of your Node application. Next, we added Arc Metrics to provide real-time visibility into your staging and production environments. Today we’re announcing the latest Arc module, Tracing, (currently in public Beta) that enables you to perform root cause analysis and triage incidents in production. (You can watch a short overview and demo of the Tracing module here.)

Those who have cut their teeth on the seemingly endless iterations in the dev lifecycle  will understand this satirical spin on Dorothy’s line from the Wizard of Oz:

“Toto, I don’t think we’re in staging anymore…  There’s no place like production… There’s no place like production…”

Simulated load, automated testing, and all the CI magic in the world won’t prepare you for the “gotchas” that can happen in production.  If you’re lucky, you’ll have a canary that keels over as soon as you enter the production mine.  But what then?

The answer is Tracing.  The Arc Tracing module provides the ability to call in the artillery when you need it.  If you see something of interest in Metrics, open up Tracing and you’ll be shown a timeline of memory and CPU usage.

Understanding the Timeline


Locate the point of interest—more often than not a CPU or memory spike in the form of a peak in the line—and start to drill down. When you’ve located the incident, you’ll want to freeze the time slice by clicking on the chart drawing your black line denoting a time slice and starting your drill down.

Read more

StrongLoop Node.js Tracing Quickstart

We recently added the Tracing module (currently in Beta) to StrongLoop Arc’s monitoring and performance analysis tools. Tracing helps you identify performance and execution patterns of Node applications, discover bottlenecks, and trace code execution paths. This enables you to monitor Node.js applications and provides tracing data at the system and function level, giving you insights into how your application performs over time. Tracing works with applications deployed to StrongLoop Process Manager (PM).

This blog post describes how to quickly get up and running with Tracing, assuming you have  some familiarity with StrongLoop tools. It demonstrates the quickest path to try out the new Tracing module, using an example that simulates some load, and how to view and understand the data visualizations based on your application traffic.

Step 1. Setup

Start by installing the latest version of StrongLoop and creating a basic Loopback application. If you have never done this previously, please refer to: http://loopback.io/getting-started/

Clone the example app from https://github.com/strongloop/tracing-example-app and go through the set up:

This example demonstrates the tracing in of StrongLoop Arc. The example includes a simple HTTP server with one route that starts an internal busy loop when triggered.  This generates fluctuations (and thus more data) for the StrongLoop Arc tracing graphs.

Please review the README to get your example app up and running and create some variation in the graphs by running the ./send-request script to make repeated curl requests to the server.

Read more