Dois anos e meio é o tempo que separa o último release, de uma major version do Rails, da atual (que foi lançada ontem). Durante esse período MUITA coisa mudou no dia-a-dia do Desenvolver Web, o que faz com que a ansiedade pela nova versão do Rails seja carregada também com dúvidas sobre o seu futuro.

Pra aproveitar que estamos usando o Rails 5 em um novo projeto na Vizir, vamos compartilhar nossas impressões do que vimos de novo.

De cara há duas mudanças e uma adição que foram os motivos principais para a escolha do Rails 5, usando ainda a versão beta, como parte do stack do projeto.

Action Cable — a grande novidade

Uma das grandes mudanças que ocorreu nos últimos dois anos foi o surgimento de interfaces mais interativas. O que antes era visto como um nível difícil de se alcançar (só lembrar do Gmail em 2007), hoje virou de certa forma uma commodity.

Parte dessa facilidade se deve ao uso de WebSockets, que veio junto com o caminhão de mudanças do HTML 5 (engraçado como muitas novidades dele, ainda hoje não são tão conhecidas, parece aqueles itens de mudança que são esquecidos ainda embalados), e foi bem adotado com o uso do Socket.io.

Trello, Slack, Pusher e tantos outros, são exemplos de serviços que fazem grande uso de WebSockets, e agora com o Action Cable, o Rails também oferece uma forma simples de usar-lo. Facilitando a criação de funcionalidades real time, na sua aplicação Rails.

Para isso ele faz um mix de tecnologias e libs:

  • Redis: utilizado para armazenar as mensagens (a primeira versão está bem acoplada ao Redis, mas parece que há intenção de no futuro possibilitar o uso de outras tecnologias que permitem pub/sub);
  • websocket-driver-ruby: para ajudar na comunicação com WebSockets. Ele usa bastante da lib criada pelo James Coglan, do Faye;
  • concurrent-ruby: Para trabalhar com Thread Pools.

Além disso para trazer toda a abstração, também conhecida como magia do Rails, o Action Cable nos apresenta dois frameworks: um JavaScript para você utilizar nas suas views e outro server-side. Com isso, você não precisa ir afundo nas tecnologias citadas acima para começar a usar WebSockets em suas aplicações Rails.

Impressões sobre o Action Cable

Olhando para dentro do próprio Action Cable, podemos notar que o grande esforço que foi feito, foi realmente trazer a possibilidade de usar WebSockets diretamente na sua aplicação Rails, já que boa parte dos componentes são “velhos” conhecidos da comunidade (inclusive o EventMachine foi usado por um tempo, que “perdeu” o lugar para o websocket-driver-ruby).

Ele é claramente uma resposta para o Rails continuar relevante ao desenvolvimento Web atual. O que é louvável, e muito bem-vindo, e um sinal que o core-team está atento as novas necessidades.

O que vimos no beta nos mostrou que ainda há muito espaço para melhoria, o que é natural para uma primeira versão. Sendo o grande “barato”, poder disparar eventos WebSockets direto da sua aplicação Rails. Diminuindo assim um pouco a complexidade da aplicação e trazendo novos conceitos (os channels, que iremos aprofundar num post futuro), para simplificar o uso de WebSockets para os desenvolvedores que estão começando a criar funcionalidades real-time.

Rails API

Antes mesmo do “boom” das Single Page Applications, a necessidade de criar APIs era comum e usar o Rails era usar poder demais. O que levaria o projeto a nascer com uma complexidade desnecessária. Neste momento, a escolha geralmente era usar uma framework leve (ex.: Sinatra), onde você teria que configurar todo um stack (de gems), para ter as funcionalidades que por padrão você já teria com o Rails (ex.: auto-carregamento em desenvolvimento e suporte a autenticação por token).

Com o Rails 5, o projeto rails-api, foi incorporado e, assim, você consegue ter o melhor de dois mundo. As comodidades do Rails em uma versão mais leve, sem carregar tantos módulos desnecessários para uma API.

Para criar uma API com Rails 5 é simples, basta:

rails new my_api — api

Desta forma a sua aplicação será configurada com um pequeno número de dependências (por exemplo, não carregará o ActionDispatch::Cookies), os seus controllers irão herdar de ActionController::API, ao invés do ActionController::Base (veja no links do Github, como a quantidade de módulos carregados pelo API é bem menor que pelo Base), e, por fim, os generators não irão gerar viewshelpers e assets.

Só por essa explicação, se torna obvio o benefício da incorporação do rails-api ao Rails. Finalmente podemos criar APIs de forma nativa no Rails, utilizando de todas as conveniências que o Rails traz, e junto com o ActionCable, torna-se novamente uma das ferramentas fortes para back-end.

Performance

Todos sabem que o Rails não é conhecido por ser o framework com a melhor performance. Porém, a versão 5 traz duas boas notícias:

  • O suporte apenas do Ruby 2.2.2 para cima: o que por si só já traz ganhos de performance. Pois na 2.2.0, por exemplo, foi introduzido no garbage collector a coleta de símbolos, que são bem comuns em aplicações Rails;
  • Contém o patch do Schneems, que melhorou em mais de 10% o tempo de resposta.

Embora essas mudanças não façam o Rails se tornar o framework mais rápido do ecossistema Ruby, elas são muito bem-vindas e passa a ser mais um motivo forte para adoção do Rails 5, mesmo em beta.

Conclusão

Na sua versão 5, o Rails fica mais versátil com o Rails API e traz novas possibilidades com o suporte a WebSocket e, junto com as melhorias, ele está mais maduro. Maturidade que é percebida, por exemplo, na integração de todos os comandos, agora dentro do bin/rails (agora rake db:migrate é rails db:migrate), e na adição de uma nova api para trabalhar com objetos que não herdam do ActiveRecord, deixando mais fácil a vida de criar aplicações não tão acopladas a infra-estrutura padrão do Rails.

Se ficou interessado em saber mais, dê uma conferida na versão edge da documentação e no post do DHH do lançamento do primeiro beta.