Rails numa Casca de Noz

Vitor Ribeiro
Vitor Ribeiro, Engenheiro de Software Ribeiro
4 de Agosto de 2019
  • #design

Por que usar Rails ?

Atualmente no mercado existem diversas alternativas de ferramentas para se desenvolver software. Podemos escolher entre Node.js, Django, Go. Dentre um mar de alternativas que não param de surgir, por que devemos usar Ruby on Rails em 2019?

Rails foi um dos frameworks mais utilizados durante os anos 2000 e 2010. Porém, nos últimos anos vem perdendo forças contra seus concorrentes. Existem alguns motivos para essa decadência nos últimos anos que valem a pena serem listadas. Rails foi construído em cima da linguagem Ruby, que por sua vez tem um tempo de execução mais alto comparado a linguagens como Javascript, Go e Java. Outro ponto interessante que pode ser dito sobre o Rails é a dificuldade na manutenção em projetos de grande porte.

Agora então, por que usar o Rails? Mesmo que Rails tenha uma desvantagem em performance, atualmente vivemos uma era em que os computadores possuem enorme poder de processamento, sendo que para usuário leigo não há um impacto tão perceptível quanto à velocidade de execução das tarefas. Logo, Rails tem uma vantagem pelo enorme poder que disponibiliza para o desenvolvedor. Rails foi construído com a filosofia Convention Over Configuration ( Convenção acima de configuração ), simplificando o desenvolvimento para se ter algum software concreto para o seu negócio.

Rails possui uma série de comandos que geram arquivos, modificações na base de dados e até mesmo testes unitários que agilizam o processo de desenvolvimento de uma aplicação.

Ou seja, a vantagem mais considerável na escolha ou não de se usar Rails, reside no ganho na velocidade de desenvolvimento. Com a estrutura criada pelo framework é possível acelerar o processo de desenvolvimento e com isso ter algum software para validar alguma ideia de negócio.


Histórico e filosofia do Framework

Rails foi criado por David Heinemeir Hansson em 2003 e tem como seu principal foco aumentar a facilidade e a velocidade de um desenvolvimento de software. RoR como também é conhecido é feito em cima da linguagem Ruby, que por sua vez foi criada em 1993 por Yukiro Matsumoto. Além disso Rails é um framework open source, o repositório oficial pode ser achado nesse link. O Rails tem uma filosofia clara, como já comentada anteriormente, ele se utiliza Convention Over Configuration ( Convenção acima de Configuração ) e do conceito DRY ( Don’t Reapt Yourself ), esses conceitos podem ser observados pelo Active Record e pelo Action Pack ( que implementa o MVC ).

Para aqueles que nunca usaram o Ruby, recomendo esse tutorial que ajudará a compreender a linguagem.


Gemfile

Ao iniciar um projeto Rails você se depara com inúmeras pastas e arquivos. Alguns serão utilizados sempre, outros raramente. Mas antes de entrar em detalhes nestes arquivos, primeiramente, vamos falar do arquivo Gemfile.

Gemfile é o arquivo criado para carregar as dependências do Rails. RoR tem uma comunidade extremamente ativa e por isso existem várias gems (pacotes) que podem ser utilizados para acelerar ainda mais o processo de desenvolvimento. Por exemplo, a gem Rolify, uma gem construída para facilitar o gerenciamento dos diferentes tipos de papéis de usuários. Ou seja, quando algum tipo de gem precisa ser utilizada, adicionamos ao arquivo gemfile para que elas sejam carregadas.

RoR já vem com algumas gems como pré-requisito para o seu funcionamento. Por exemplo: a gem Nokogori que é uma gem para realizar um parser de arquivos HTML, XML, SAX.

Gemfile funciona com o mesmo intuito do package.json de projetos em Node.js. Por default o gemfile utiliza o site https://rubygems.org/ onde está hospedado diversas gems para que os desenvolvedores possam utilizar em seus projetos. Além disso, é possível informar algum repositório para que a gem seja baixada.

Outra funcionalidade interessante do gemfile é poder restringir que as gems sejam utilizadas apenas em um ambiente específico, seja ele de produção, de testes ou desenvolvimento.

Além do arquivo Gemfile, existe um Gemfile.lock, que tem a funcionalidade de travar as versões e dependências em uma versão específica, ou seja, ao rodar o bundle install ele irá verificar a existência de alguma gem nova a ser instalada, caso contrário ele usa as que já foram mapeadas pelo gemfile.lock. Com isso, todas as dependências ficam travadas naquela versão, o que ajuda na questão de compatibilidade do projeto e também evita updates indesejados.


Pastas de configurações

Como mencionado anteriormente, o Rails vem com várias pastas já criadas, uma estrutra bem robusta que chega a ser até intimidante para novatos no framework. Nessa parte iremos focar em descrever as funcionalidades dos arquivos da pasta Config. As pastas App e DB, serão introduzidas posteriormente.

A pasta de configurações do Rails é responsável por gerenciar o início do projeto. Rails oferece liberdade para modificar os três tipos de ambientes de um projeto, ou seja, logo na pasta enviroments você irá achar arquivos que serão carregados quando o ambiente selecionado for produção, desenvolvimento ou testes. Nesses arquivos será possível encontrar variáveis de configuração, como por exemplo a variável de suporte a emails, que por default vem desativada, mas caso seja necessário utilizar apenas em produção, alterando o valor dela, o suporte de Rails para emails será ativado para qual ambiente ele esteja rodando. Também é possível criar outros ambientes dentro da pasta, uma ação mais rara e que quebra a regra de Convention Over Configuration do Rails, mas é importante saber que essa ação pode ser realizada.

A pasta initializers. É onde se encontram arquivos que são carregados ao iniciar o projeto. Um exemplo é o arquivo cookies_serializer.rb que tem como função Serealizar os cookies em requisições. Todas as modificações feitas aqui requerem que o servidor seja reiniciado para que sejam aplicadas.

O próximo arquivo é o application.rb. Este arquivo tem a função de carregar as gems que serão utilizadas no projeto e as gems referentes ao ambiente em que o projeto será carregado.

O arquivo boot.rb, é responsável por inicializar o Bundler e montar os caminhos de arquivos para que sejam encontradas as gems que serão utilizadas.

O arquivo database.yml é o arquivo de configurações que será utilizado pelo Active Record para criar a conexão com o banco de dados.

Enviroment.rb é o arquivo responsável por inicializar o application.rb e rodar os scripts para iniciar o projeto.

O arquivo rotas também será discutido posteriormente.

Para finalizar essa introdução às pastas de configuração do Rails, temos o arquivo secrets.yml, que é responsável por guardar dados sensíveis que podem ser utilizados no projeto, como por exemplo alguma chave de conexão com alguma API externa. O funcionamento é semelhante ao .env que é utilizado em projetos Node.js.


Padrão MVC

MVC ou Model-View-Controller é um padrão de arquitetura que foi desenvolvida para separar a representação do dado de sua interação. O Rails foi desenvolvido para seguir o padrão MVC, novamente voltando para Convention Over Configuration.

O padrão MVC coloca as responsabilidades definidas por cada um de seus agentes. A view é responsável por mostrar os dados ou por enviar novos dados que foram inseridos pelo usuário. O controller é responsável por administrar os dados que são transitados entre a view e o banco de dados, ou seja, funcionando como uma ponte de informações entre a view e o model, para que ambos possam tratar destes dados a sua maneira. Por último temos a model, que é a representação do banco de dados de uma forma mais abstrata, no nosso caso, em linguagem Ruby. O model é responsável por criar associações de tabelas e pela validação dos dados que são retornados da view.


Mãos à obra ( Pode mudar )

Agora vamos desenvolver um mini blog para continuar explorando as potencialidades que o Rails pode nos oferecer.

Caso você não tenha o Rails instalado no seu computador, esses links podem lhe ser úteis: instalação mac, instalação linux.

Uma vez instalado vamos rodar o seguinte comando no terminal:

rails new blog

Esse comando cria uma pasta com o projeto Rails, o último argumento se refere ao nome que será dado ao projeto.

Uma vez dentro da pasta do projeto vamos criar os Posts que serão salvos pelos usuários. Para isso, precisamos ter os seguintes atributos, numa tabela no banco de dados, um título e um corpo para o texto. Além disso, precisamos criar uma view para interagir com o usuário, uma model para inserir as validações e/ou associações com outras tabelas e um controller para a ponte entre ambos. Não podemos esquecer também de declarar as rotas que podemos acessar pelo navegador. Ou seja, temos muitos passos até ter algo concreto que possamos usar. Porém, o Rails consegue criar grande parte desses passos utilizando-se de um comando:

rails generate scaffold post title:string body:text

Isso irá gerar os seguintes arquivos:

Com apenas um comando criamos uma controller funcionando, uma model, uma view, definimos as rotas, os helpers e outras funcionalidades. Ou seja, já temos algo que podemos testar. Lembrando que o nome do argumento post que escrevemos no comando, deve ser escrito no singular e preferencialmente em inglês, o Rails tem um helper que tem a função de pluralizar as palavras, porém, funciona quase perfeitamente apenas para o inglês.

Geramos também alterações no banco de dados que por default está sendo usado o sqlite3, mas caso queira utlizar outro banco, basta adicionar o arguemento -database=postgresql após o nome do projeto ao inicializa-lo.

Para que as alterações no banco sejam de fato concretas e gravadas no schema.rb, precisamos rodar o seguinte comando:

rails db:migrate

Antes de prosseguir, é extremamente importante falar como funciona essa comunicação do Rails com o banco de dados. Existe uma abstração no framework chamado ORM ( Object Relational Mapper ) é uma camada extra de abstração que possibilita que o desenvolvedor faça ações no banco de dados utilizando-se da linguagem Ruby.

Agora sim vamos poder testar o que fizemos com apenas um comando, basta rodar o seguinte no terminal:

rails server ou rails s ( abreviação )

Espera o servidor subir, digite http://localhost:3000 em seu navegador e você verá a seguinte página:

Está é a página inicial de qualquer projeto iniciado em rails, como não alteramos a rota principal não conseguimos ver na página inicial o que criamos. Para isso vamos para a seguinte url: http://localhost:3000/posts.

Pronto, temos agora a página que deverá mostrar todos os posts criados, obviamente sem estilização robusta, mas quem sabe não exista uma gem para isso ( risos ). Podemos clicar em new Post , preencher o formulário e assim finalmente conseguimos salvar algum dado concreto no nosso banco de dados. Tudo isso utilizando apenas um comando.

Alguns pontos importantes antes de prosseguimos:

  1. Caso você queira verificar todas as rotas que estão disponíveis no projeto, basta rodar o comando rails routes no terminal ou digitar http://localhost:3000/rails/info/routes no navegador.
  2. Rails respeita o padrão REST, então, suas ações são feitas para seguir o CRUD básico estipulado pelo padrão REST. Claro que também é possível quebrar esse padrão por escolha do desenvolvedor, porém, quebra a filosofia Convention Over Configuration.
  3. Cada view segue a ação de seu respectivo nome no controller.
  4. O comando usado para gerar esses arquivos também concede a opção dos dados serem retornados na forma de JSON, bastando digitar .json ao término da url.

Vamos agora realizar uma validação na model e posts, vamos tornar obrigatória a presença do título, algo que não está sendo feito atualmete. Na pasta model/post.rb vamos adicionar a seguinte linha:

https://gist.github.com/VitorRibeiroCustodio/1bd14a5b28caf1d9a7c5d54e8db44a20

Agora não será mais possível criar um post sem um título, retornando um erro para o usuário que tentar.

Vamos agora implementar os comentários dos posts. Em nossa simples modelagem, uma relação 1:N, ou seja, um post possui vários comentários. Para isso vamos aprender um novo comando, gerando os mesmos arquivos da última vez, porém, dessa vez, eles estarão vazio.

rails generate resource comment post:references body:text

Não se esqueça de rodar novamente rails db:migrate

Pronto, com isso temos uma relação criada no banco graças ao comando references, que cria uma relação entre comment e post. Porém devemos ir novamente, no model de post e adicionar a seguinte linha:

https://gist.github.com/VitorRibeiroCustodio/65281f54392cfddfe043a8da51e8ab82

No Rails existem vários tipos de atalhos para indicar uma associação entre modelos, para relacionar Post e Comment podemos usar duas delas: belongs_to e has_many. O helper belongs_to cria uma associação em que essa modelo pertence a outra, ou seja, existe uma chave primaria de outra tabela ( FK ) estabelecendo uma relação. Nesse caso a model comment pertence a post. O caminho contrário é o has_many, onde o helper irá procurar os registros que possuem a Primary Key da model em questão cadastrada, retornando assim todos os registros que pertencem a ela. Um fato a se atentar é que o Rails subentende o nome da relação através do nome que você dá a ela, ou seja, quando fazemos has_many :comments, estamos procurando todos os registros da model comment. O mesmo vale para o belong_to.

Como queremos utilizar os comentários pela view de posts, vamos criar um nested_attribute, ou seja, permitir que atributos de diferentes tabelas sejam inseridos pelo fluxo que já temos. Para respeitar o padrão REST, devemos alterar o routes.rb:

https://gist.github.com/VitorRibeiroCustodio/65b26de1d4bc126d81cbbaa54189dae5

Pronto, olhando as rotas podemos ver que temos nested_attributes.
Vamos adicionar o seguinte código no final do arquivo views/posts/show.html.erb:

https://gist.github.com/VitorRibeiroCustodio/5df82fab8510a9dc77433923ad41a5e8

Caso você queira entrar na rota de show agora, verá um erro para você, isso acontece pq ainda não implementamos as partials dos comentários. Partials são pedaços de códigos que podem ser reutilizados em diferentes partes do projeto, ou seja, eles funcionam na mesma ideia de componentes que já é bem conhecido no mundo de frontend.

Em views/comments vamos criar dois arquivos _comment.html.erb e _new.html.erb e iremos adicionar os seguintes códigos:

https://gist.github.com/VitorRibeiroCustodio/b3d32543fbcaccf5f7f991ca7367c1e2https://gist.github.com/VitorRibeiroCustodio/b876917102b6a4222af4b5bd705e1f1d

E no controller do comments vamos adicionar o seguinte código:

https://gist.github.com/VitorRibeiroCustodio/6180752d6ec3f5feec05f502d9082167

Nesse pedaço de código adicionamos o before_action, que é um helper do Rails que será executado antes de qualquer função ser executada. Ou seja, antes de se realizar a função create, o before_action irá chamar a função set_post para achar qual o post que está relacionado aquele comentário.

Pronto, conseguimos abranger o básico do que é o Rails por meio desse mini blog. Ainda há muito o que falar sobre esse framework, mas pelo menos agora você poderá ter uma noção maior de como ele funciona e poderá começar a entrar no mundo do desenvolvimento em Rails.

  • #design
Vitor Ribeiro
Vitor Ribeiro, Engenheiro de Software Ribeiro

qual é o seu desafio para a gente?

hello@novatics.com.br
Voltar ao topo