Forem: Daniel

RAG desde cero con Ruby

Daniel — Tue, 27 Jan 2026 03:19:33 +0000

La idea

¿Alguna vez deseaste preguntarle algo a un LLM sobre tus propios documentos?, pues bien Esto es exactamente lo que hace esta app.

Subes un PDF o TXT, la aplicacion lo "digiere" y despus puedes hacerle preguntas como si fuera un experto en ese documento.

Ubicacion del proyecto

https://github.com/Daniel-Penaloza/sinatra_rag

Ejemplo real:

Subes la documentacion de uso de endpoints.
Preguntas: ¿Que necesito para poder hacer una peticion a X endpoint?
La IA te responde basandose SOLO en esa documentacion.

🧠 Componentes Rag

Documentos: En este caso utilizaremos PDF o archivos TXT.
Document Loaders: Como aqui no utilizaremos langchain como wrapper, usaremos la gema pdf-reader para leer el texto de un pdf y posteriormente almacenar ese texto.
Chunkers: Tambien llamados dividores de texto, para tener la informacion dividida y que de esta manera sea mas manejable.
Embeddings: Con esto codificamos el texto en representaciones numericas (creacion de vectores).
Base de datos vectoriales: Utilizada para guardar nuestros vectores.

Tech Stack

Qué hace	Tecnología
Backend	Ruby + Sinatra
Base de datos	PostgreSQL + pgvector
Procesamiento async	Sidekiq + Redis
LLM	OpenAI (embeddings + chat)

¿Por que este Tech Stack?

Ruby es la tecnologia que mas utilizo para programar y en este caso solo busco entender como funciona RAG sin utilizar frameworks como LangChain que son un tipo de wrapper para la mayoria de los LLM's disponibles en el mercado.

Construirlo de esta manera me ayudo a entender cada pieza del rompecabezas y creo que de esta manera tu que lo estas leyendo tambien puedes entenderlo.

Como funciona

1. Subes un documento

Tu PDF ──> La app lo guarda ──> Entra a la cola de procesamiento

2. La app lo procesa (en segundo plano)

Documento
    │
    ▼
Extrae el texto
    │
    ▼
Lo parte en pedazos pequeños (chunks)
    │
    ▼
Cada pedazo se convierte en vectores (embeddings)
    │
    ▼
Se guarda en la base de datos

¿Por qué en pedazos? Porque es más fácil buscar en fragmentos pequeños que en un documento de 100 páginas.

¿Por qué números? Porque las computadoras comparan números más rápido que texto. Y lo cool es que estos números capturan el significado, no solo las palabras.

3. Haces una pregunta

Tu pregunta
    │
    ▼
Se convierte en vectores (igual que los documentos)
    │
    ▼
Busca los pedazos más parecidos en la base de datos
    │
    ▼
Le pasa esos pedazos a la IA como contexto
    │
    ▼
La IA te responde basándose en TU información

Estructura del proyecto

RAG/
├── app.rb                 # El cerebro de la app (rutas)
├── config/
│   └── sidekiq.rb         # Config de jobs en background
├── db/
│   └── migrations/        # Estructura de la base de datos
├── lib/
│   ├── jobs/
│   │   └── document_processor_job.rb  # Procesa docs en segundo plano
│   ├── models/            # Tablas de la BD
│   ├── services/
│   │   ├── chat_agent.rb      # El que arma las respuestas
│   │   ├── chunker.rb         # Parte el texto en pedazos
│   │   ├── embeddings.rb      # Convierte texto a números
│   │   └── rag_retriever.rb   # Busca los pedazos relevantes
│   └── text_extractors/   # Saca texto de PDFs y TXTs
├── views/                 # Las pantallas de la app
└── docker-compose.yml     # PostgreSQL + Redis

Basado en lo anterior podemos dividir lo que hace nuestra aplicacion en dos partes:

Carga de documentos.
Respuesta a nuestras preguntas (Chat Agent).

‼️ Warning.

Durante esta explicacion voy a evitar hablar de boiler plate code, como es el caso de las sesiones del chat o el docker file, es decir codigo que no vea tan relevante de como funciona a RAG, por lo tanto deberas de tener un poco de conocimientos en Ruby, Docker, etcetera, sin embargo creo que esta muy straightforward de seguir este documento.

📄 Carga de documentos.

Para poder hacer la carga de documentos ocupamos dos rutas en nuestro app.rb las cuales son:

get "/upload"
post "/documents"

Upload (GET):
Contiene el siguiente codigo:

get "/upload" do
  @documents = db[:documents].reverse_order(:id).all
  erb :upload
end

Practicamente lo que nos indica es que deberemos de tener una view (vista) con el nombre de upload.erb, la cual tendra variable de instancia @documents para poder iterar sobre los archivos en esta vista.

Esta vista en codigo practicamente lo que hace es poner a nuestra disposicion un formulario que al ser llenado y dar click en el boton de procesar e indexar mandara a llamar a nuestro ruta post "/documents", como se puede apreciar enseguida:

<h2>Subir documento</h2>

<form class="card" action="/documents" method="post" enctype="multipart/form-data">
  <label>Título</label>
  <input type="text" name="title" placeholder="Ej. Políticas de seguridad" />
.....

Documents (POST):

Aqui es en donde sucede la magia de nuestra aplicacion, por lo que empezaremos a explicar paso a paso que sucede:

1. Carga y registro de documento.

file = params[:file]
halt 400, "Falta archivo" if file.nil?

filename = file[:filename]
tempfile = file[:tempfile]
mime = file[:type]
size = (tempfile.size.to_f / 1024 / 1024).round(2)

halt 400, "Solo PDF o TXT" unless allowed_file?(filename, mime, size)

storage_name = "#{SecureRandom.uuid}#{File.extname(filename).downcase}"
storage_path = File.join(UPLOAD_DIR, storage_name)
FileUtils.cp(tempfile.path, storage_path)

title = params[:title].to_s.strip
title = filename if title.empty?

doc_id = db[:documents].insert(
  title: title,
  filename: filename,
  content_type: mime.to_s,
  storage_path: storage_path
)

Durante esta etapa lo que estamos haciendo se divide en dos partes:

Extraer informacion relevante del archivo que hemos subido en donde hemos agregado algunas validaciones para comprobar si en efecto un archivo fue cargado y si cumple con la validacion de que sea unicamente un PDF o un TXT.
Guardar en nuestra tabla documents el archivo que acabamos de cargar desde nuestro formulario.

2. Chunking y embedding de forma asincrona del documento.

Jobs::DocumentProcessorJob.perform_async(doc_id, storage_path, filename)

redirect "/upload"

Practicamente lo que estaremos haciendo aqui es pedirle a nuestra aplicacion que procese por medio de sidekiq nuestro archivo en segundo plano y sus responsabilidades seran:

Extraer el texto.
Partir el documento en partes (chunks).
Crear embeddings (vectores) para cada parte del documento.

Todo esto lo podemos ver dentro de DocumentProcessorJob el cual explicare a continuacion:

module Jobs
  class DocumentProcessorJob
    include Sidekiq::Worker
    sidekiq_options queue: :default, retry: 3

    def perform(doc_id, storage_path, filename)

      # Extraer texto del documento
      text = 
        if File.extname(filename).downcase == ".pdf"
          TextExtractors::PdfExtractor.extract(storage_path)
        else
          TextExtractors::TxtExtractor.extract(storage_path)
        end

        return if text.strip.empty?

        # Chunking - Embeddings
        chunks = Services::Chunker.split(text, size: 1100, overlap: 200)
        embedder = Services::Embeddings.new

        chunks.each_with_index do |chunk, idx|
          emb = embedder.embed(chunk)
          next if emb.nil?

          DocumentChunk.create(
            document_id: doc_id,
            chunk_index: idx,
            content: chunk,
            embedding: emb,
            char_count: chunk.length
          )
        end

        DB.run("ANALYZE document_chunks")
    end
  end
end

Extraccion de texto

text = 
  if File.extname(filename).downcase == ".pdf"
    TextExtractors::PdfExtractor.extract(storage_path)
  else
    TextExtractors::TxtExtractor.extract(storage_path)
  end

Contamos con dos Extractores de texto uno llamado PdfExtractor y otro TxtExtractor (ya se que pudimos utilizar herencia para evitar usar esos IF's, pero a mi me interesa aprender a hacer un RAG), en donde el codigo de cada una de estas dos clases la verdad es muy sencillo, como se muestra enseguida:

module TextExtractors
  class PdfExtractor
    def self.extract(path)
      reader = PDF::Reader.new(path)
      text = reader.pages.map(&:text).join("\n")
      text.strip
    end
  end
end

module TextExtractors
  class TxtExtractor
    def self.extract(path)
      File.read(path).to_s.strip
    end
  end
end

Chunking

chunks = Services::Chunker.split(text, size: 1100, overlap: 200)

Para esto contamos con un servicio llamado Chunker, el cual posiblemente no sea el mas refinado pero hace su trabajo por el momento.

module Services
  class Chunker
    def self.split(text, size: 1000, overlap: 150)
      # limpiamos texto
      t = text.gsub("\u0000", "").strip

      # Si esta vacio retornarmo un arreglo vacio
      return [] if t.empty?

      chunks = []
      i = 0

      # Agregamos los pedazos de texto a el arreglo chunks
      while i < t.length
        chunk = t[i, size]
        chunks << chunk.strip if chunk&.strip&.length&.positive?
        i += (size - overlap)
        break if size <= overlap
      end
      chunks
    end
  end
end

Ojo aqui con overlap, lo unico que significa overlap: 150 es que cada chunk repite los ultimos 150 caracteres del anterior chunk para no perder contexto.

Embedding

Enseguida debemos de hacer nuestros embeddings (convertir nuestro texto en vectores) sobre cada pedazo de texto que posteriormente "chunkeamos" por medio del servicio Embeddings como se muestra enseguida:

require "openai"
require_relative "../config"

module Services
  class Embeddings
    def initialize
      @client = OpenAI::Client.new(api_key: ENV.fetch("OPENAI_API_KEY"))
    end

    def embed(input_text)
      response = @client.embeddings.create(
        model: Config::OPENAI_EMBEDDING_MODEL,
        input: input_text,
        encoding_format: 'float'
      )

      response.to_h[:data][0][:embedding]
    end
  end
end

Como vemos aqui inicializamos el servicio de OpenAI con nuestras llaves y posteriormente creamos un metodo llamado embed el cual se encargara unicamente de hacer lo que comentamos anteriormente.

Una vez que hayamos logrado esto unicamente veremos en nuestro index como es que somos redireccionados a el root de nuestra pequeña app y apreciaremos como es que se subio el archivo.

💬 Nuestro Chat.

Ya hicimos lo mas importante que es cargar nuestra base de conocimiento a nuestra base de datos, posteriormente lo que necesitaremos es obtener informacion basado en un input (el chat) y para poder hacerlo deberemos de hacer lo siguiente.

👀 Nuestra vista

get "/chat" do
  session = find_or_create_chat_session
  @messages = db[:chat_messages].where(chat_session_id: session[:id]).order(:id).all
  erb :chat
end

Nuestra vista para el chat es llamada asi chat el cual tiene un formulario para hacer la pregunta como se muestra enseguida:

<h2>Chat RAG</h2>

<form class="card" action="/chat" method="post">
  <label>Pregunta</label>
  <textarea name="message" placeholder="Pregunta algo sobre los documentos..."></textarea>
  <br/>
  <button type="submit">Enviar</button>
</form>

Y tambien cuenta con la variable de instancia @messages para iterar sobre los mensajes o preguntas que le he hecho a la aplicacion para obtener resultados.

🤖 Obtener informacion

Para esto contamos con nuestro metodo POST '/chat' con la finalidad de poder procesar nuestra respuesta con el siguiente codigo:

post "/chat" do
  session = find_or_create_chat_session
  question = params[:message].to_s.strip
  halt 400, "Mensaje vacío" if question.empty?

  db[:chat_messages].insert(chat_session_id: session[:id], role: "user", content: question, sources: Sequel.pg_jsonb([]))

  agent = Services::ChatAgent.new
  result = agent.answer(question)

  db[:chat_messages].insert(
    chat_session_id: session[:id],
    role: "assistant",
    content: result[:answer],
    sources: Sequel.pg_jsonb(result[:sources])
  )

  redirect "/chat"
end

Lo que hace esto es insertar la pregunta que estamos haciendo en la tabla chat_messages para posteriormente pasar esta pregunta a el servicio de ChatAgent el cual tiene lo siguiente:

Este es el contrato del agente, practicamente le estamos indicando como se debe de comportar, de esta manera matamos las alucinaciones.

SYSTEM = <<~SYS
  Eres un asistente que responde usando SOLO el CONTEXTO proporcionado.
  - Si el contexto no contiene la respuesta, di claramente: "No tengo suficiente información en los documentos."
  - Devuelve una sección "Fuentes" listando doc_id y chunk_id usados.
  - Sé conciso y directo.
SYS

Inicializamos el agente

def initialize(retriever: Services::RagRetriever.new)
  @retriever = retriever
  @client = OpenAI::Client.new(api_key: ENV.fetch("OPENAI_API_KEY"))
end

Esto lo hacemos inicializando el RagRetriever el cual su funcion principal es obtener una respuesta en base a la pregunta que le hicimos mediante la comparacion de vectores.

class RagRetriever
  def initialize(embedder: Services::Embeddings.new)
    @embedder = embedder
  end

  def retrieve(question, top_k: 6)
    q_emb = @embedder.embed(question)
    raise "No se pudo generar embedding" if q_emb.nil?

    DocumentChunk
      .nearest_neighbors(:embedding, q_emb, distance: "cosine")
      .select(
        Sequel[:document_chunks][:id].as(:chunk_id),
        Sequel[:document_chunks][:document_id],
        Sequel[:document_chunks][:chunk_index],
        Sequel[:document_chunks][:content]
      )
      .limit(top_k)
      .all
  end
end

top_k es practicamente decirle a la IA dame los resultados mas relevantes y olvida el resto, en donde K es un numero que nosotros eligimos; en este caso le estamos indicando que busque los 6 chunks mas parecidos a nuestra pregunta.

Posteriormente buscamos los chunks por medio del metodo retrieve que es parte de nuestra instancia inicializada de RagRetriever.

  hits = @retriever.retrieve(question, top_k: 6)

Despues creamos el texto de la siguiente manera:

context = hits.map.with_index(1) do |h, idx|
  "[S#{idx}] doc_id=#{h[:document_id]} chunk_id=#{h[:chunk_id]} chunk_index=#{h[:chunk_index]}\n#{h[:content]}"
end.join("\n\n")

Que es practicamente lo siguiente:

[S1] doc_id=10 chunk_id=44
Texto real del documento...

[S2] doc_id=12 chunk_id=03
Otro texto real...

Enseguida creamos nuestro user prompt:

user_prompt = <<~USR
  CONTEXTO:
  #{context}

  PREGUNTA:
  #{question}
USR

Por ultimo para no entrar en mas detalles lo que hacemos es mandar a llamar al modelo de OpenAI y su metodo de crear un chat de la siguiente manera:

resp = @client.chat.completions.create(
  model: Config::OPENAI_CHAT_MODEL,
  messages: [
    { 
      role: "system",
      content: SYSTEM
    },
    { 
      role: "user", 
      content: user_prompt 
    }
  ]
)

Todo esto lo podemos ver en el siguiente link https://platform.openai.com/docs/api-reference/chat.

¿Dudas o comentarios?

Me pueden buscar en mi linkedin https://www.linkedin.com/in/daniel-pe%C3%B1aloza-82aa9a100/ o bien mandarme un mensaje por aqui y sin tema intercambiamos ideas.

Rails API + Cache + Design Patterns (English Version)

Daniel — Sun, 24 Nov 2024 19:40:43 +0000

Hey whats up today it’s my pleassure to present a new tutorial for the creation of an API with Ruby On Rails. However this tutorial will be made it out of the box and i just want to cover more stuff than a simple CRUD so here it’s what we are going to build:

Setup of the application

Make a connection with an external API to retrieve elements we will use:

Faraday: With this geam we could create the connection with the cliente and make future requests.
VCR: We will record the HTTP call to the cliente and we will use the cassttes (generate files in YAML format with this geam) for the creation of tests in our requests.

Tests

RSpec: Not much to say.

The API that we will connect to.

https://pokeapi.co/docs/v2#pokemon

The use of the proxy design pattern with the goal of store in cache the first client call for a period of 24 hours.
-https://refactoring.guru/design-patterns/proxy

The Factory Method Pattern for the creation of the responses thata we are going to provide
- https://refactoring.guru/design-patterns/factory-method

The repository of this project is here:

https://github.com/Daniel-Penaloza/pokemon_client_api

We are going to start the creation of our application without the default test suite and also the project need to be an API. We can achive this with the following command:

rails new api_project —api -T

Now it’s time of the configuration process so we need to open our Gemfile and add the following gems as the following code:

group :test do
  gem 'vcr', '~> 6.3', '>= 6.3.1'
end

group :development, :test do
  # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem
  gem "debug", platforms: %i[ mri windows ]
  gem 'rspec-rails', '~> 7.1'
end

# HTTP CLIENT
gem 'faraday', '~> 2.12', '>= 2.12.1'

# Redis - quitar el comentario de esta linea
gem "redis", ">= 4.0.1"

We need to run bundle install and then we need to make the setup of RSpec and VCR.

RSpec setup:
We can run the command rails generate rspec:install and this will create the boilerplate code that we need to run our specs.
VCR setup:
Once installed and configured Rspec we need to open our file rails_helper.rb y just above the configuration block of RSpec we will proceed to add the following code:

require 'vcr'

VCR.configure do |c|
  c.cassette_library_dir = 'spec/vcr_cassettes'
  c.hook_into :faraday

  c.configure_rspec_metadata!
  c.default_cassette_options = {
    record: :new_episodes
  }
end

Lastly we need to active the cache on our development environment due that there is only activated in production by default so we need to execute the following command in terminal.

rails dev:cache

Now is time to coding and we are goint to make this not in a regular TDD wat that means the creation of tests, then make that the test pass and then the refactorization (red - green - refactor) and this is because personally i feel more comfortable with the creation of the code base and then with the tests (this can be for my lack of experience).

Whatever we allways need to add test to our code i love to add tests to all my code to reduce the error gap that can be presente once that the app is ready for use.

With that on mind we need to add a new route to or applicacion inside of routes.rb as follows:

  namespace :api do
    namespace :v1 do
      get '/pokemon', to: 'pokemons#pokemon'
    end
  end

As we see we are creating a namaspace both for the api and the version and this is a due a good practice because maybe in a future we can have a new version of our API with new features.

Now is moment of the creation of our pokemons controller inside of app/controlles/api/v1/pokemons_controller with the following content:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response, status: :ok
        else
          render json:  { 'error' => 'please provide a valid parameter' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

In this chunk of code we are creating a pokemon method that check that the name of the provided parameters is pokemon_name at the moment of make a request; otherwire we will return an error indicating that the parameter is invalid.

So the only valid URI is:

http://localhost:3000/api/v1/pokemon?pokemon_name=nombre_de_pokemon

Following the flow of our api we are calling the private method get_pokemon which accepts the pokemon_name parameter.

This is passed to a new instance of the service GetPokemonService which is a service invoked via call.

This class should be inside of our directory services/v1/get_pokemon_service.rb and need to follow the next structure:

module V1
  class GetPokemonService
    attr_reader :pokemon_name

    def initialize(pokemon_name:)
      @pokemon_name = pokemon_name
    end

    def call
      get_pokemon
    end

    private

    def get_pokemon
      client = WebServices::PokemonConnection.new
      proxy = PokemonProxy.new(client)
      proxy.get_pokemon(pokemon_name:)
    end
  end
end

At this point we have something very interesting and is the use of a proxy pattern which allow us to have a substitute of an object to controll his access.

But first thing firs, we hace a variable client which is an instance of the Fadaday class to be connected to our external client with a specific configuracion that we have inside of our block. This class should be inside of web_services/pokemon_connection.rb

module WebServices
  class PokemonConnection
    def client(read_timeout = 30)
      Faraday.new(url: 'https://pokeapi.co/api/v2/') do |conn|
        conn.options.open_timeout = 30
        conn.options.read_timeout = read_timeout
        conn.request :json
        conn.response :logger, nil, { headers: false, bodies: false, errors: false }
        conn.response :json
        conn.adapter :net_http
      end
    end

    def get_pokemon(pokemon_name:)
      response = client.get("pokemon/#{pokemon_name}")
    rescue Faraday::Error => e
      { 'error' => e }
    end
  end
end

The client method make a direct connection with the API via the instantiation of Faraday passing along the url parameter that we are going to use to make the connection. We need to have in mind that this method only will be execute until we decide and in this case will be via the method call of get_pokemon when we use the get method of the client this means client.get.

If you wan to now more details about Faraday you can check the official documentation:

https://lostisland.github.io/faraday/#/

The get_pokemon takes the pokemon name and then send this name of the pokemon trough client.get(”/pokemon/pikachu”). Where the value of the client just before of the use of this method as https://pokeapi.co/api/v2.

client.get("pokemon/pikachu")

When we are executing the previous code in our get_pokemon method in reality we are making a get request to the following URI:

GET https://pokeapi.co/api/v2/pokemon/pikachu

If everything is correct we will have a response with all the information of pikachu and we can test this in a new browser window inserting the following uri https://pokeapi.co/api/v2/pokemon/pikachu just to know the result of the external API call.

Next we have a proxy which need to have the same interface of the class PokemonConnection this means that we need to have the method get_pokemon inside of that class. The locaiton of this proxy class should be in app/proxies/pokemon_proxy.rb and will have the following content:

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def stats(stats)
    stats.each_with_object([]) do |stat, array|
      array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
    end
  end

  def type(types)
    types.map { |type| type.dig('type', 'name') }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end
end

learning purposes will leave this class in that way in this moment and we will comeback later to make an improvement with refactorization.

Now it’s time to explain the lines of codes, first we have in the initializer a client as parameter that was passed in the last call and also we have a instance variable called cache that initializes Rails.cache.

# Call from the previous class
client = WebServices::PokemonConnection.new
proxy = PokemonProxy.new(client)    

def initialize(client)
  @client = client
  @cache = Rails.cache
end

Then we have the method get_pokemon that as we say previously this class need to have the same interface of the client and here is a brief explanation of what we are doing.

  def get_pokemon(pokemon_name:)
    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

In the first line we just return a pokemon_response (we will explain this method next) if the cache key (”pokemon_cached/pikacu”) exits with the arguments on_cache and the previous key mentioned.

If not exist on cache then we make use of the client that we pass in the previous call at the moment of the initialization of our new instance y we call the method get_pokemon where is the status of the response is 200 then to the response body we just add a new field called consulted_at that will be the hour and date of the client call.

Next we store the response of the client call in cache with the key pokemon_cached/pokemon_name and also we add an extra argument to store this response only for 24 hours. In that way if we make future calls to our endpoint we will retrieve the response from the cache instead of make a client call.

In case that the status of the response of the cliente can’t be success (differente to 200) we will return a pokemon_error_resopnse with the response of the client as an argument.

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end

Now it’s time to explain the private methods that we need on this class first we have our method consulted_at that only give us the date and hour when is invoked.

pokemon_response have the parameteres origin and response and with that ones we construct a Hast object. So in the first call of this method we will have the following result:

{
  :origin => "client_call",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

And then on future calls we will have:

{
  :origin => "on_cache",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

If we call to our method error_response we will have the following result:

{
    "error": "Not Found",
    "status": 404
}

At this point our API can be available to work as we expected and if we want to test our api we can make it as follows:

We need to start our rails server with rails s.
In other terminal we need to open the rails console with rails c and add the following code.

require 'net/http'
require 'uri'

url = 'http://localhost:3000/api/v1/pokemon?pokemon_name=pikachu'
uri = URI(url)

response = Net::HTTP.get_response(uri)
response.body

# Resultado
"{\"origin\":\"client_call\",\"name\":\"pikachu\",\"weight\":60,\"types\":[\"electric\"],\"stats\":[\"hp: 35\",\"attack: 55\",\"defense: 40\",\"special-attack: 50\",\"special-defense: 50\",\"speed: 90\"],\"consulted_at\":\"2024-11-21T02:13:03\"}"

Test Stage

For the generation of our test suite we need to think about the funcionality that we have by now and what we get as result. Therefore if we analyze our code we have the following scenarios:

1.- We wil have a success case when the name of the pokemon is valid:

The first requet to our endpoint will bring us the origin as client_call.
The second request to our endpoint will bring us the origin as on_cache.

2.- We will have a failed case when:

The name of the pokemon is invalid.
The pokemon_name parameter it’s not presen as query params.

With that on mind we will proceed to crear the following test inside of spec/requests/pokemons_spec.rb with the following content:

require 'rails_helper'

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :new_episodes } do
  let(:memory_store) { ActiveSupport::Cache.lookup_store(:memory_store) }
  let(:pokemon_name) { 'pikachu' }

  before do
    allow(Rails).to receive(:cache).and_return(memory_store)
  end

  describe 'GET /api/v1/pokemon' do
    context 'with a valid pokemon' do
      it 'returns data from the client on the first request and caches it for subsequent requests' do
        # first call - fetch data from the client
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        expect(response.status).to eq(200)
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('client_call')
        pokemon_information(pokemon)
        expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

        # second call - fetch data from cache
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('on_cache')
        pokemon_information(pokemon)
      end
    end

    context 'with an invalid pokemon' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Not Found')
        expect(error['status']).to eq(404)
      end
    end

    context 'with invalid parameters' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Invalid Parameters')
      end
    end
  end

  # Helper methods
  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

  def parse_response(response)
    JSON.parse(response)
  end
end

In the first line we hace the use of VCR that will be used for record the requests that we make to the pokemon client.

Then we are going to create two lets:

memory_store: Create a cache instance.
pokemon_name: We just define the name of the pokemon that will use to keep our code DRY.

Next we have our before clock where we only make a stube of Rails.cache with the goald of return an instance of cache.

Now is time to create our specs to test our endpoint with the following code block:

it 'returns data from the client on the first request and caches it for subsequent requests' do
  # first call - fetch data from the client
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  expect(response.status).to eq(200)
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('client_call')
  pokemon_information(pokemon)
  expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

  # second call - fetch data from cache
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('on_cache')
  pokemon_information(pokemon)
end

What we do in this test is very easy:

We call our endpoint pokemon where we pass along the query param pokemon_name with the name of the pokemon (pikcachu in this case).
We expect that the status of the response be 200.
Parse the body of the obtainer response.
We expect that the value of our origin field in the json be equals as client_call.
Then we just validate that the returned json be as we expect, this means:

  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

Then we expect that the response is store in our cache with the key pokemon_cached/pikachu.
We make againg our endpoint pokemont just with the same previous characteristics that the first request.
Following we expect that the field of our json origin has the value of on_cache.
Lastly we validate again the returned json to accomplish with the necessary characteristics.

Now we can go with our failed cases and the firs one will retorn a 404 due that we don’t find a pokemon that we pass as query param, there is no much to say this is a very easy test and this is what we expect:

context 'with an invalid pokemon' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Not Found')
    expect(error['status']).to eq(404)
  end
end

Subsequently we hace the last failed case where if the parameter is invalid we will have a specific error.

context 'with invalid parameters' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Invalid Parameters')
  end
end

Finally in our test the last thing that we have are a couple of helper methods with the purpose of have our specs as DRY as we can.

Now we can execute our tests with the command bundle exec rspec and this will bring us as result that all our tests are ok.

In addition to this the fisrt time that we run our specs this will generate some YAML files undder spec/vcr_cassettes of the requests that we make in our test and the pokemon client. In that way if we cant to make a change later in our custom response we don’t need to hit the client again and we can use the response that we have in that cassettes.

Once that we already run our specs is time to change the first line of our spec in the RSpec block updating the sympolo record: :new_episodes to record: :none.

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :none }

Refactorization.

There are two places where i want to make some changes one of them first is the controller as follows:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response.pokemon_body, status: response.status
        else
          render json: { 'error': 'Invalid Parameters' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

If we check the code inside of our response we are accessing to two methods pokemon_body and status in that way we are avoiding hardcoding this values and retrieve the status of the response.

Well if we want that this works we need to apply a second refactorization using the in our proxy as follows:

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return WebServices::FactoryResponse.create_response(origin: 'on_cache', response: cache.read("pokemon_cached/#{pokemon_name}"), type: 'success') if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)

    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'success')
    else
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'failed')
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end
end

Previously we have methods that return a succesfull or failed responde depending on how the client responds. However not we are making use ot the design pattern Factory Method which allow us to create objects (in this cases responses) based in the type of object that we pass as an argument.

So first we need to create our FactoryResponse class with the class method create_response as follows:

module WebServices
  class FactoryResponse
    def self.create_response(origin:, response:, type:)
      case type
      when 'success'
        PokemonResponse.new(origin:, response:)
      when 'failed'
        PokemonFailedResponse.new(response:)
      end
    end
  end
end

So if the type is success then we will create a new instance of PokemonResponse:

module WebServices
  class PokemonResponse
    attr_reader :origin, :response

    def initialize(origin:, response:)
      @origin = origin
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'origin': origin,
        'name': response.body['name'],
        'weight': response.body['weight'],
        'types': type(response.body['types']),
        'stats': stats(response.body['stats']),
        'consulted_at': response.body['consulted_at']
      }
    end

    def status
      response.status
    end

    private

    def stats(stats)
      stats.each_with_object([]) do |stat, array|
        array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
      end
    end

    def type(types)
      types = types.map { |type| type.dig('type', 'name') }
    end
  end
end

Otherwise if the response is failed we will return a new instance of PokemonFailedResponse

module WebServices
  class PokemonFailedResponse
    attr_reader :response

    def initialize(response:)
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'error': response.body,
        'status': response.status
      }
    end

    def status
      response.status
    end
  end
end

With this we achieve to follow the principle of Single Responsability and in that way we can change in the future the success or failed response when the times arrives in just one file at a time.

Now if we execute bunlde exec rspec our test should be passing without any problem y we will finish the creation of the project.

I really hope you liked this tiny project and iy you jhave any questions or comments please let me know and i’ll be happy to answer them. Good day to yoou who are reading and learning, Happy coding.

Rails API + Cache + Design Patterns + RSpec

Daniel — Sat, 23 Nov 2024 20:13:29 +0000

Hey que tal el dia hoy vengo a presentarles un tutorial de como crear un API en Ruby On Rails, sin embargo en este tutorial quiero salirme un poco fuera de la caja de la simple creacion de un CRUD y por lo tanto lo que crearemos lo describo enseguida:

Configuracion de la aplicacion.

Conectarnos a un API externa para obtener elementos por medio de:

Faraday: Con esta gema crearemos la conexion y llamadas posteriores a el cliente.
VCR: Aqui gracias a este registraremos las llamadas HTTP a el cliente y utilizaremos cassettes (archivos generados por esta gema en formato yml) para poder crear pruebas de nuestras peticiones.

Pruebas en la aplicacion:

RSpec: Una de mis gemas favoritas.

El api al que nos conectaremos sera al de pokemon:

https://pokeapi.co/docs/v2#pokemon

Agregaremos el patron de diseño proxy con la finalidad de guardar en cache la consulta al cliente por un periodo de 24 horas.

https://refactoring.guru/design-patterns/proxy

De igual forma vamos utilizar el Factory Method Pattern para poder crear las respuestas que retornaremos sean exitosas o fallidas. - https://refactoring.guru/design-patterns/factory-method

El repositorio de la aplicacion puede ser encontrado enseguida:

Pokemon Client API

Comentado lo anterior empezaremos por crear nuestra aplicacion, indicando que desamos crear la aplicacion sin el suite de pruebas por defecto y ademas que sera una API con el siguiente comando:

rails new api_project —api -T

Una vez creada la aplicacion procederemos a configurar nuestra aplicacion para poder crear pruebas y empezar a escribir codigo.
Empezaremos por abrir nuestro Gemfile y agregar las siguientes gemas en su ambiente respectivo como se mira enseguida:

group :test do
  gem 'vcr', '~> 6.3', '>= 6.3.1'
end

group :development, :test do
  # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem
  gem "debug", platforms: %i[ mri windows ]
  gem 'rspec-rails', '~> 7.1'
end

# HTTP CLIENT
gem 'faraday', '~> 2.12', '>= 2.12.1'

# Redis - quitar el comentario de esta linea
gem "redis", ">= 4.0.1"

Procederemos a instalar nuestras gemas con un bundle install y posteriormente a configurar RSpec y VCR.

Configuracion de RSpec.

Utilizaremos el comando rails generate rspec:install lo cual nos creara una serie de archivos para configurar nuestra suite de pruebas y asi poder empezar a generar pruebas para nuestra aplicacion.
Configuracion VCR.

Una vez instalada RSpec procederemos a abrir nuestro archivo rails_helper.rb y justo arriba del bloque de configuracion de RSpec procederemos a agregar el siguiente codigo:

require 'vcr'

VCR.configure do |c|
  c.cassette_library_dir = 'spec/vcr_cassettes'
  c.hook_into :faraday

  c.configure_rspec_metadata!
  c.default_cassette_options = {
    record: :new_episodes
  }
end

Por ultimo debemos de activar el cache en nuestro ambiente de desarrollo ya que solo esta habilitado en produccion por defecto y esto lo haremos en la terminal ejecutando el siguiente comando: rails dev:cache

Una vez que terminamos esta configuracion basica es momento de empezar a tirar codigo y esto lo haremos no de la manera convencional de TDD es decir crear pruebas, que pase el codigo y despues refactorizar (red - green -refactor), debido a que en lo personal yo me siento mas comodo creando primero el codigo y despues generando las pruebas (por mi falta de experiencia posiblemente).

Sea como sea siempre debemos crear pruebas para nuestro codigo, en lo personal a mi siempre me gusta tener pruebas para reducir el gap de errores que pueden presentarse una vez que tengamos nuestra aplicacion lista para ser utilizada.

Dicho lo anterior empezaremos por agregar una nueva ruta en nuestra aplicacion dentro del archivo routes.rb como se muestra enseguida:

  namespace :api do
    namespace :v1 do
      get '/pokemon', to: 'pokemons#pokemon'
    end
  end

Como vemos aqui estamos creando un namespace tanto para api como para la version de esta y esto lo hacemos como buena practica en caso de que en un futuro quisieramos tener una version 2 de la api con nuevas caracteristicas.

Despues procederemos a crear el controlador pokemons dentro de app/controllers/api/v1/pokemons_controller.rb con la siguiente estructura:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response, status: :ok
        else
          render json:  { 'error' => 'please provide a valid parameter' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

Aqui estamos creando nuestro metodo pokemon el cual revisa que desde donde hagamos la peticion este presente el parametro pokemon_name al momento de hacer una busqueda y en caso omiso retornaremos un error indicando que el parametro no es valido.

Es decir la unica URI valida sera la siguiente:
http://localhost:3000/api/v1/pokemon?pokemon_name=nombre_de_pokemon

Siguiendo con el flujo de nuestra api estamos mandando a llamar a un metodo privado con el nombre de get_pokemon el cual acepta el parametro pokemon_name.

Este es pasado a una nueva instancia del servicio GePokemonService el cual como es un servicio es llamado directamente con el metodo call.

Esta clase debera de estar dentro del directorio services/v1/get_pokemon_service.rb y tendra la siguiente estructura:

module V1
  class GetPokemonService
    attr_reader :pokemon_name

    def initialize(pokemon_name:)
      @pokemon_name = pokemon_name
    end

    def call
      get_pokemon
    end

    private

    def get_pokemon
      client = WebServices::PokemonConnection.new
      proxy = PokemonProxy.new(client)
      proxy.get_pokemon(pokemon_name:)
    end
  end
end

En este punto llegamos a algo interesante y esto es el uso del patron proxy el cual nos permite tener un sustituto de un objeto para controlar su acceso.

Pero primero lo primero, tenemos una variable llamada client la cual es una instancia de la clase Faraday para conectarnos a el cliente externo con una configuracion especifica que pasamos dentro del un bloque. Esta clase debera de estar dentro del directorio web_services/pokemon_connection.rb

module WebServices
  class PokemonConnection
    def client(read_timeout = 30)
      Faraday.new(url: 'https://pokeapi.co/api/v2/') do |conn|
        conn.options.open_timeout = 30
        conn.options.read_timeout = read_timeout
        conn.request :json
        conn.response :logger, nil, { headers: false, bodies: false, errors: false }
        conn.response :json
        conn.adapter :net_http
      end
    end

    def get_pokemon(pokemon_name:)
      response = client.get("pokemon/#{pokemon_name}")
    rescue Faraday::Error => e
      { 'error' => e }
    end
  end
end

Si analizamos un poco el codigo en este metodo hacemos una conexion directa al api mediante la instanciacion de Faraday pasandole como parametro la url a la que nos queremos conectar. Es necesario aclarar que este metodo no se ejecutara hasta que nosotros lo decidamos y en este caso sera mediante la llamada a el metodo get_pokemon cuando hacemos uso del metodo client.get.

Si les interesa conocer mas detalles de Faraday pueden revisar su documentacion en el siguiente vinculo:

https://lostisland.github.io/faraday

El metodo get_pokemon toma el nombre del pokemon y lo que hacemos enseguida es mandar a llamar a client.get(”/pokemon/pikachu”). Por ejemplo en donde el valor de client antes de hacer uso del metodo get sera https://pokeapi.co/api/v2/.
client.get("pokemon/pikachu")

Cuando estamos ejecutando el codigo anterior dentro de nuestro metodo get_pokemon en realidad estamos haciendo un get hacia la siguiente URI:
GET https://pokeapi.co/api/v2/pokemon/pikachu

Si todo es correcto obtendremos una respuesta con toda la informacion del pokemon pikachu y lo podemos probar justo en una ventana de nuestro navegador agregando la direccion https://pokeapi.co/api/v2/pokemon/pikachu con la finalidad de revisar el resultado de lo que nos respondera el API externo.

Acto seguido contamos con nuestro proxy el cual debe de tener la misma interfaz que la clase PokemonConnection esto quiere decir que deberemos de tener el metodo get_pokemon dentro de ella. Su ubicacion sera dentro de app/proxies/pokemon_proxy.rb y tendra el siguiente contenido:

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def stats(stats)
    stats.each_with_object([]) do |stat, array|
      array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
    end
  end

  def type(types)
    types.map { |type| type.dig('type', 'name') }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end
end

Desde mi punto de vista esta clase esta haciendo demasiado y tiene mas de una responsabilidad; sin embargo para terminos de enseñanza considero que esta bien ya que al programar tambien debemos de refactorizar y esto lo haremos mas adelante ya que terminemos de crear las pruebas para nuestra API.

Empezaremos por explicar el metodo inicializador este cuenta con un cliente que le pasamos desde su llamada en la clase anterior y ademas agregamos a la variable de instancia @cache inicializando Rails.cache.

# Llamada de clase anterior
client = WebServices::PokemonConnection.new
proxy = PokemonProxy.new(client)    

def initialize(client)
  @client = client
  @cache = Rails.cache
end

Despues tenemos el metodo get_pokemon que como comentamos anteriormente esta clase Proxy debe de tener la misma interfaz que el cliente y la explicaremos enseguida.

    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

En la primera linea lo que hacemos es retornar un pokemon_response (veremos a continuacion el metodo) siempre y cuando la llave para cache (en este caso “pokemon_cached/pikachu”) exista con los argumentos on_cache y la llave anteriormente mencionada en cache.

En caso de que no exista esa llave para cache lo que hacemos es hacer uso el client que pasamos por parametro al momento de inicializar nuestra instancia y mandamos a llamar al metodo get_pokemon, en donde si el estatus de la respuesta es un 200 entonces a la respuesta que es un hash le agregaremos un nuevo elemento llamado consulted_at que sera la fecha y hora en la que se esta haciendo la consulta al cliente.

Posteriormente procedemos a guardar la respuesta de la llamada al cliente con la llave pokemon_cached/nombre_del_pokemon y ademas pasamos una tiempo de expiracion para esta respuesta con el fin de que durante 24 horas este disponible en cache y asi en futuras llamadas no vayamos a el cliente a preguntarle sobre el pokemon en cuestion.

Enseguida mandamos a llamar a el metodo pokemon_response con los argumentos client_call y la respuesta obtenida por parte del cliente.

En caso de que el estatus de la respuesta del cliente no haya sido favorable (diferente a 200) retornaremos un pokemon_error_response con la respuesta del cliente como argumento.

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end

Haciendo referencia a los metodos anteriormente explicados tenemos en primer lugar a consulted_at el cual su unica funcion es brindarnos la fecha y hora cuando es llamado.

pokemon_response cuenta con los parametros origin y response con los cuales construye un objeto del tipo Hash. La primera invocacion a este metodo nos debera de arrojar lo siguiente:

{
  :origin => "client_call",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

En una segunda y futuras invocaciones a este metodo tendremos como resultado lo siguiente:

{
  :origin => "on_cache",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

Mientras que nuestro metodo error_response nos dara el siguiente resultado:

{
    "error": "Not Found",
    "status": 404
}

Hasta este punto nuestro API ya estara funcional y si lo queremos probar lo podemos hacer de la siguiente manera:

Iniciamos nuestro servidor de Rails con el comando rails s.
En otra terminal abriremos una consola de Rails y agregaremos lo siguiente:

require 'net/http'
require 'uri'

url = 'http://localhost:3000/api/v1/pokemon?pokemon_name=pikachu'
uri = URI(url)

response = Net::HTTP.get_response(uri)
response.body

# Resultado
"{\"origin\":\"client_call\",\"name\":\"pikachu\",\"weight\":60,\"types\":[\"electric\"],\"stats\":[\"hp: 35\",\"attack: 55\",\"defense: 40\",\"special-attack: 50\",\"special-defense: 50\",\"speed: 90\"],\"consulted_at\":\"2024-11-21T02:13:03\"}"

Etapa De Pruebas

Para poder generar las pruebas debemos de pensar en la funcionalidad que actualmente tenemos y que nos da como resultado. Por lo tanto si analizamos nuestro codigo contamos con los siguientes escenarios:

1.- Tendremos un caso exitoso cuando el nombre del pokemon sea valido:

La primera peticion a este endpoint debe de traernos el origin como client_call.
La segunda peticion a este endpoint debe de traernos el origin como on_cache.

2.- Tendremos un caso fallido cuando:

El nombre del pokemon sea invalido.
El parametro pokemon_name no este presente como query params.

Basado en esto que conocemos de nuestra aplicacion procederemos a crear la siguiente prueba dentro de spec/requests/pokemons_spec.rb:

require 'rails_helper'

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :new_episodes } do
  let(:memory_store) { ActiveSupport::Cache.lookup_store(:memory_store) }
  let(:pokemon_name) { 'pikachu' }

  before do
    allow(Rails).to receive(:cache).and_return(memory_store)
  end

  describe 'GET /api/v1/pokemon' do
    context 'with a valid pokemon' do
      it 'returns data from the client on the first request and caches it for subsequent requests' do
        # first call - fetch data from the client
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        expect(response.status).to eq(200)
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('client_call')
        pokemon_information(pokemon)
        expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

        # second call - fetch data from cache
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('on_cache')
        pokemon_information(pokemon)
      end
    end

    context 'with an invalid pokemon' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Not Found')
        expect(error['status']).to eq(404)
      end
    end

    context 'with invalid parameters' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Invalid Parameters')
      end
    end
  end

  # Helper methods
  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

  def parse_response(response)
    JSON.parse(response)
  end
end

En la primera linea nos encontraremos con el uso de VCR en donde solo se utilizara para las peticiones que hagamos a el cliente de pokemon en donde esperamos una respuesta exitosa o fallida segun como nos responda este.

Despues empezamos por crear dos lets los cuales se explican enseguida:

memory_store: Esta creara una instancia de cache.
pokemon_name: Definimos el nombre del pokemon que utilizaremos para mantener nuestro codigo DRY.

Enseguida contamos con un bloque before en donde unicamente stubeamos Rails.cache con la finalidad de que nos retorne una instancia de cache.

Y ahora si empezamos a probar nuestro endpoint que creamos con el siguiente bloque de codigo:

it 'returns data from the client on the first request and caches it for subsequent requests' do
  # first call - fetch data from the client
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  expect(response.status).to eq(200)
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('client_call')
  pokemon_information(pokemon)
  expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

  # second call - fetch data from cache
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('on_cache')
  pokemon_information(pokemon)
end

Lo que hacemos en esta prueba es bien sencillo:

Mandamos a llamar a nuestro endpoint pokemon en donde le pasamos el query param pokemon_name con el nombre del pokemon (pikachu).
Esperamos que la respuesta obtenida sea un 200.
Parseamos el body de la respuesta obtenida.
El campo de nuestro json con el valor de origin debera de ser igual a client_call.
Posterior a esto validamos que el json retornado sea justo como nosotros lo deseamos, es decir:

  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

Enseguida esperamos que se haya almacenado la respuesta obtenida con la llave pokemon_cached/pikachu.
Volvemos a llamar a nuestro endpoint pokemon justo con las mismas caracteristicas de la primera peticion.
Ahora esperamos que el campo de nuestro json con el valor de origin sea igual a on_cache.
Por ultimo validamos de nuevo que el json retornado cumpla con las caracteristicas necesarias.

Ahora vamos con los casos fallidos y el primero de estos nos retornara un 404 debido a que no se encontro el pokemon que le pasamos por parametro, no hay mucho que hablar esta es una prueba muy sencilla y esto es lo que esperamos.

context 'with an invalid pokemon' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Not Found')
    expect(error['status']).to eq(404)
  end
end

Posteriomente contamos con el ultimo caso que valida que si el parametro es invalido nos retorne un error en especifico.

context 'with invalid parameters' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Invalid Parameters')
  end
end

Lo ultimo que tenemos es un par de helper method para evitar estar repitiendo codigo en nuestra spec.

Ahora procederemos a ejecutar nuestras pruebas con bundle exec rspec y esto nos dara como resultado que nuestras pruebas pasaran sin problema.

Ademas de esto se crearan unos archivos en formato YAML los cuales son los registros guardados dentro de spec/vcr_cassettes de las peticiones que hagamos al cliente de pokemon y estos nos permitiran si asi lo deseamos usar estos mismos para mas pruebas que deseemos hacer en un futuro con la respuesta obtenida de parte del cliente.

Una vez que hayamos terminado de ejecutar nuestraas pruebas sera necesario cambiar el hash del simbolo vcr de new_episodes a none como se muestra enseguida.

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :none }

Refactorizando
Hay especificamente dos partes que considero debemos de refactorizar la primera de ellas es el controlador de la siguiente manera:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response.pokemon_body, status: response.status
        else
          render json: { 'error': 'Invalid Parameters' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

Si nos damos cuenta dentro de nuestra respuesta al servicio GetPokemon estamos accediendo a pokemon_body y status de esta manera nos olvidamos de hardcodear en especifido el status de la peticion que le hagamos al cliente.

Pues bien para que esto funcione deberemos de aplicar una segunda refactorizacion en el proxy que hemos creado anteriormente de la siguiente manera:

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return WebServices::FactoryResponse.create_response(origin: 'on_cache', response: cache.read("pokemon_cached/#{pokemon_name}"), type: 'success') if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)

    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'success')
    else
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'failed')
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end
end

Anteriormente contabamos con metodos para retornar una respuesta exitosa o fallida dependiente de como nos respondia el cliente, sin embargo ahora estamos haciendo uso del patron de diseño Factory Method el cual practicamente lo utilizaremos para crear objetos (respuesta) basados en el tipo que le pasamos como argumentos.

Dicho lo anterior primero crearemos nuestro FactoryResponse con el siguiente contenido:

module WebServices
  class FactoryResponse
    def self.create_response(origin:, response:, type:)
      case type
      when 'success'
        PokemonResponse.new(origin:, response:)
      when 'failed'
        PokemonFailedResponse.new(response:)
      end
    end
  end
end

Basado en el tipo que recibe esta clase mediante el metodo de clase create_response determinaremos el tipo de respuesta que debemos de retornar, en donde si es un caso exitoso retornaremos un PokemonResponse con el siguiente contenido:

module WebServices
  class PokemonResponse
    attr_reader :origin, :response

    def initialize(origin:, response:)
      @origin = origin
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'origin': origin,
        'name': response.body['name'],
        'weight': response.body['weight'],
        'types': type(response.body['types']),
        'stats': stats(response.body['stats']),
        'consulted_at': response.body['consulted_at']
      }
    end

    def status
      response.status
    end

    private

    def stats(stats)
      stats.each_with_object([]) do |stat, array|
        array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
      end
    end

    def type(types)
      types = types.map { |type| type.dig('type', 'name') }
    end
  end
end

En caso contrario lo que retornaremos un PokemonFailedResponse con el siguiente contenido:

module WebServices
  class PokemonFailedResponse
    attr_reader :response

    def initialize(response:)
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'error': response.body,
        'status': response.status
      }
    end

    def status
      response.status
    end
  end
end

Con esto logramos que seguir el principio S de SOLID (Single Responability) y de esta manera podemos modificar en un futuro la respuesta exitosa o fallida en su clase correspondiente.

Ahora bien si ejecutamos bundle exec rspec nuestras pruebas deberan de pasar sin ningun problema y abremos terminado con la creacion del proyecto.

Por ultimo espero que este pequeño proyecto les haya gustado y si tienen alguna duda o comentario por favor haganmelo saber y con todo gusto estare ahi para responderles, buen dia a ti que estas leyendo y happy coding.

Rails API + Cache + Design Patterns + RSpec (Version En Español)

Daniel — Sat, 23 Nov 2024 20:13:28 +0000

Configuracion de la aplicacion.

Conectarnos a un API externa para obtener elementos por medio de:

Faraday: Con esta gema crearemos la conexion y llamadas posteriores a el cliente.
VCR: Aqui gracias a este registraremos las llamadas HTTP a el cliente y utilizaremos cassettes (archivos generados por esta gema en formato yml) para poder crear pruebas de nuestras peticiones.

Pruebas en la aplicacion:

RSpec: Una de mis gemas favoritas.

El api al que nos conectaremos sera al de pokemon:

https://pokeapi.co/docs/v2#pokemon

Agregaremos el patron de diseño proxy con la finalidad de guardar en cache la consulta al cliente por un periodo de 24 horas.

https://refactoring.guru/design-patterns/proxy

De igual forma vamos utilizar el Factory Method Pattern para poder crear las respuestas que retornaremos sean exitosas o fallidas. - https://refactoring.guru/design-patterns/factory-method

El repositorio de la aplicacion puede ser encontrado enseguida:

Pokemon Client API

Comentado lo anterior empezaremos por crear nuestra aplicacion, indicando que desamos crear la aplicacion sin el suite de pruebas por defecto y ademas que sera una API con el siguiente comando:

rails new api_project —api -T

group :test do
  gem 'vcr', '~> 6.3', '>= 6.3.1'
end

group :development, :test do
  # See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem
  gem "debug", platforms: %i[ mri windows ]
  gem 'rspec-rails', '~> 7.1'
end

# HTTP CLIENT
gem 'faraday', '~> 2.12', '>= 2.12.1'

# Redis - quitar el comentario de esta linea
gem "redis", ">= 4.0.1"

Procederemos a instalar nuestras gemas con un bundle install y posteriormente a configurar RSpec y VCR.

Configuracion de RSpec.

Utilizaremos el comando rails generate rspec:install lo cual nos creara una serie de archivos para configurar nuestra suite de pruebas y asi poder empezar a generar pruebas para nuestra aplicacion.
Configuracion VCR.

Una vez instalada RSpec procederemos a abrir nuestro archivo rails_helper.rb y justo arriba del bloque de configuracion de RSpec procederemos a agregar el siguiente codigo:

require 'vcr'

VCR.configure do |c|
  c.cassette_library_dir = 'spec/vcr_cassettes'
  c.hook_into :faraday

  c.configure_rspec_metadata!
  c.default_cassette_options = {
    record: :new_episodes
  }
end

Por ultimo debemos de activar el cache en nuestro ambiente de desarrollo ya que solo esta habilitado en produccion por defecto y esto lo haremos en la terminal ejecutando el siguiente comando: rails dev:cache

Dicho lo anterior empezaremos por agregar una nueva ruta en nuestra aplicacion dentro del archivo routes.rb como se muestra enseguida:

  namespace :api do
    namespace :v1 do
      get '/pokemon', to: 'pokemons#pokemon'
    end
  end

Despues procederemos a crear el controlador pokemons dentro de app/controllers/api/v1/pokemons_controller.rb con la siguiente estructura:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response, status: :ok
        else
          render json:  { 'error' => 'please provide a valid parameter' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

Es decir la unica URI valida sera la siguiente:
http://localhost:3000/api/v1/pokemon?pokemon_name=nombre_de_pokemon

Siguiendo con el flujo de nuestra api estamos mandando a llamar a un metodo privado con el nombre de get_pokemon el cual acepta el parametro pokemon_name.

Este es pasado a una nueva instancia del servicio GePokemonService el cual como es un servicio es llamado directamente con el metodo call.

Esta clase debera de estar dentro del directorio services/v1/get_pokemon_service.rb y tendra la siguiente estructura:

module V1
  class GetPokemonService
    attr_reader :pokemon_name

    def initialize(pokemon_name:)
      @pokemon_name = pokemon_name
    end

    def call
      get_pokemon
    end

    private

    def get_pokemon
      client = WebServices::PokemonConnection.new
      proxy = PokemonProxy.new(client)
      proxy.get_pokemon(pokemon_name:)
    end
  end
end

En este punto llegamos a algo interesante y esto es el uso del patron proxy el cual nos permite tener un sustituto de un objeto para controlar su acceso.

module WebServices
  class PokemonConnection
    def client(read_timeout = 30)
      Faraday.new(url: 'https://pokeapi.co/api/v2/') do |conn|
        conn.options.open_timeout = 30
        conn.options.read_timeout = read_timeout
        conn.request :json
        conn.response :logger, nil, { headers: false, bodies: false, errors: false }
        conn.response :json
        conn.adapter :net_http
      end
    end

    def get_pokemon(pokemon_name:)
      response = client.get("pokemon/#{pokemon_name}")
    rescue Faraday::Error => e
      { 'error' => e }
    end
  end
end

Si les interesa conocer mas detalles de Faraday pueden revisar su documentacion en el siguiente vinculo:

https://lostisland.github.io/faraday

Cuando estamos ejecutando el codigo anterior dentro de nuestro metodo get_pokemon en realidad estamos haciendo un get hacia la siguiente URI:
GET https://pokeapi.co/api/v2/pokemon/pikachu

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def stats(stats)
    stats.each_with_object([]) do |stat, array|
      array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
    end
  end

  def type(types)
    types.map { |type| type.dig('type', 'name') }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end
end

# Llamada de clase anterior
client = WebServices::PokemonConnection.new
proxy = PokemonProxy.new(client)    

def initialize(client)
  @client = client
  @cache = Rails.cache
end

Despues tenemos el metodo get_pokemon que como comentamos anteriormente esta clase Proxy debe de tener la misma interfaz que el cliente y la explicaremos enseguida.

    return pokemon_response('on_cache', cache.read("pokemon_cached/#{pokemon_name}")) if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)
    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      pokemon_response('client_call', response)
    else
      pokemon_error_response(response)
    end
  end

Enseguida mandamos a llamar a el metodo pokemon_response con los argumentos client_call y la respuesta obtenida por parte del cliente.

En caso de que el estatus de la respuesta del cliente no haya sido favorable (diferente a 200) retornaremos un pokemon_error_response con la respuesta del cliente como argumento.

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end

  def pokemon_response(origin, response)
    {
      'origin': origin,
      'name': response.body['name'],
      'weight': response.body['weight'],
      'types': type(response.body['types']),
      'stats': stats(response.body['stats']),
      'consulted_at': response.body['consulted_at']
    }
  end

  def pokemon_error_response(response)
    {
      'error': response.body,
      'status': response.status
    }
  end

Haciendo referencia a los metodos anteriormente explicados tenemos en primer lugar a consulted_at el cual su unica funcion es brindarnos la fecha y hora cuando es llamado.

pokemon_response cuenta con los parametros origin y response con los cuales construye un objeto del tipo Hash. La primera invocacion a este metodo nos debera de arrojar lo siguiente:

{
  :origin => "client_call",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

En una segunda y futuras invocaciones a este metodo tendremos como resultado lo siguiente:

{
  :origin => "on_cache",
  :name => "pikachu",
  :weight => 60,
  :types => ["electric"],
  :stats => [
    "hp: 35",
    "attack: 55",
    "defense: 40",
    "special-attack: 50",
    "special-defense: 50",
    "speed: 90"
   ],
   :consulted_at=>"2024-11-21T02:00:20"
}

Mientras que nuestro metodo error_response nos dara el siguiente resultado:

{
    "error": "Not Found",
    "status": 404
}

Hasta este punto nuestro API ya estara funcional y si lo queremos probar lo podemos hacer de la siguiente manera:

Iniciamos nuestro servidor de Rails con el comando rails s.
En otra terminal abriremos una consola de Rails y agregaremos lo siguiente:

require 'net/http'
require 'uri'

url = 'http://localhost:3000/api/v1/pokemon?pokemon_name=pikachu'
uri = URI(url)

response = Net::HTTP.get_response(uri)
response.body

# Resultado
"{\"origin\":\"client_call\",\"name\":\"pikachu\",\"weight\":60,\"types\":[\"electric\"],\"stats\":[\"hp: 35\",\"attack: 55\",\"defense: 40\",\"special-attack: 50\",\"special-defense: 50\",\"speed: 90\"],\"consulted_at\":\"2024-11-21T02:13:03\"}"

Etapa De Pruebas

1.- Tendremos un caso exitoso cuando el nombre del pokemon sea valido:

La primera peticion a este endpoint debe de traernos el origin como client_call.
La segunda peticion a este endpoint debe de traernos el origin como on_cache.

2.- Tendremos un caso fallido cuando:

El nombre del pokemon sea invalido.
El parametro pokemon_name no este presente como query params.

Basado en esto que conocemos de nuestra aplicacion procederemos a crear la siguiente prueba dentro de spec/requests/pokemons_spec.rb:

require 'rails_helper'

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :new_episodes } do
  let(:memory_store) { ActiveSupport::Cache.lookup_store(:memory_store) }
  let(:pokemon_name) { 'pikachu' }

  before do
    allow(Rails).to receive(:cache).and_return(memory_store)
  end

  describe 'GET /api/v1/pokemon' do
    context 'with a valid pokemon' do
      it 'returns data from the client on the first request and caches it for subsequent requests' do
        # first call - fetch data from the client
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        expect(response.status).to eq(200)
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('client_call')
        pokemon_information(pokemon)
        expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

        # second call - fetch data from cache
        get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
        pokemon = parse_response(response.body)
        expect(pokemon['origin']).to eq('on_cache')
        pokemon_information(pokemon)
      end
    end

    context 'with an invalid pokemon' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Not Found')
        expect(error['status']).to eq(404)
      end
    end

    context 'with invalid parameters' do
      it 'returns an error' do
        get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
        error = parse_response(response.body)
        expect(error['error']).to eq('Invalid Parameters')
      end
    end
  end

  # Helper methods
  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

  def parse_response(response)
    JSON.parse(response)
  end
end

Despues empezamos por crear dos lets los cuales se explican enseguida:

memory_store: Esta creara una instancia de cache.
pokemon_name: Definimos el nombre del pokemon que utilizaremos para mantener nuestro codigo DRY.

Enseguida contamos con un bloque before en donde unicamente stubeamos Rails.cache con la finalidad de que nos retorne una instancia de cache.

Y ahora si empezamos a probar nuestro endpoint que creamos con el siguiente bloque de codigo:

it 'returns data from the client on the first request and caches it for subsequent requests' do
  # first call - fetch data from the client
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  expect(response.status).to eq(200)
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('client_call')
  pokemon_information(pokemon)
  expect(Rails.cache.exist?("pokemon_cached/#{pokemon_name}")).to eq(true)

  # second call - fetch data from cache
  get "/api/v1/pokemon?pokemon_name=#{pokemon_name}"
  pokemon = parse_response(response.body)
  expect(pokemon['origin']).to eq('on_cache')
  pokemon_information(pokemon)
end

Lo que hacemos en esta prueba es bien sencillo:

Mandamos a llamar a nuestro endpoint pokemon en donde le pasamos el query param pokemon_name con el nombre del pokemon (pikachu).
Esperamos que la respuesta obtenida sea un 200.
Parseamos el body de la respuesta obtenida.
El campo de nuestro json con el valor de origin debera de ser igual a client_call.
Posterior a esto validamos que el json retornado sea justo como nosotros lo deseamos, es decir:

  def pokemon_information(pokemon)
    expect(pokemon['name']).to eq('pikachu')
    expect(pokemon['weight']).to eq(60)
    expect(pokemon['types']).to eq(['electric'])
    expect(pokemon['stats']).to eq([
      'hp: 35',
      'attack: 55',
      'defense: 40',
      'special-attack: 50',
      'special-defense: 50',
      'speed: 90'
    ])
    expect(pokemon['consulted_at']).to be_present
  end

Enseguida esperamos que se haya almacenado la respuesta obtenida con la llave pokemon_cached/pikachu.
Volvemos a llamar a nuestro endpoint pokemon justo con las mismas caracteristicas de la primera peticion.
Ahora esperamos que el campo de nuestro json con el valor de origin sea igual a on_cache.
Por ultimo validamos de nuevo que el json retornado cumpla con las caracteristicas necesarias.

context 'with an invalid pokemon' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_name=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Not Found')
    expect(error['status']).to eq(404)
  end
end

Posteriomente contamos con el ultimo caso que valida que si el parametro es invalido nos retorne un error en especifico.

context 'with invalid parameters' do
  it 'returns an error' do
    get '/api/v1/pokemon?pokemon_namess=unknown_pokemon'
    error = parse_response(response.body)
    expect(error['error']).to eq('Invalid Parameters')
  end
end

Lo ultimo que tenemos es un par de helper method para evitar estar repitiendo codigo en nuestra spec.

Ahora procederemos a ejecutar nuestras pruebas con bundle exec rspec y esto nos dara como resultado que nuestras pruebas pasaran sin problema.

Una vez que hayamos terminado de ejecutar nuestraas pruebas sera necesario cambiar el hash del simbolo vcr de new_episodes a none como se muestra enseguida.

RSpec.describe Api::V1::PokemonsController, type: :request, vcr: { record: :none }

Refactorizando
Hay especificamente dos partes que considero debemos de refactorizar la primera de ellas es el controlador de la siguiente manera:

module Api
  module V1
    class PokemonsController < ApplicationController
      def pokemon
        if params[:pokemon_name].present?
          response = get_pokemon(pokemon_name: params[:pokemon_name])
          render json: response.pokemon_body, status: response.status
        else
          render json: { 'error': 'Invalid Parameters' }, status: :unprocessable_entity
        end
      end

      private

      def get_pokemon(pokemon_name:)
        ::V1::GetPokemonService.new(pokemon_name:).call
      end
    end
  end
end

Pues bien para que esto funcione deberemos de aplicar una segunda refactorizacion en el proxy que hemos creado anteriormente de la siguiente manera:

class PokemonProxy
  EXPIRATION = 24.hours.freeze

  attr_reader :client, :cache

  def initialize(client)
    @client = client
    @cache = Rails.cache
  end

  def get_pokemon(pokemon_name:)
    return WebServices::FactoryResponse.create_response(origin: 'on_cache', response: cache.read("pokemon_cached/#{pokemon_name}"), type: 'success') if cache.exist?("pokemon_cached/#{pokemon_name}")

    response = client.get_pokemon(pokemon_name:)

    if response.status == 200
      response.body['consulted_at'] = consulted_at
      cache.write("pokemon_cached/#{pokemon_name}", response, expires_in: EXPIRATION)
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'success')
    else
      WebServices::FactoryResponse.create_response(origin: 'client_call', response:, type: 'failed')
    end
  end

  private

  def consulted_at
    Time.now.utc.strftime('%FT%T')
  end
end

Dicho lo anterior primero crearemos nuestro FactoryResponse con el siguiente contenido:

module WebServices
  class FactoryResponse
    def self.create_response(origin:, response:, type:)
      case type
      when 'success'
        PokemonResponse.new(origin:, response:)
      when 'failed'
        PokemonFailedResponse.new(response:)
      end
    end
  end
end

module WebServices
  class PokemonResponse
    attr_reader :origin, :response

    def initialize(origin:, response:)
      @origin = origin
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'origin': origin,
        'name': response.body['name'],
        'weight': response.body['weight'],
        'types': type(response.body['types']),
        'stats': stats(response.body['stats']),
        'consulted_at': response.body['consulted_at']
      }
    end

    def status
      response.status
    end

    private

    def stats(stats)
      stats.each_with_object([]) do |stat, array|
        array << "#{stat.dig('stat', 'name')}: #{stat['base_stat']}"
      end
    end

    def type(types)
      types = types.map { |type| type.dig('type', 'name') }
    end
  end
end

En caso contrario lo que retornaremos un PokemonFailedResponse con el siguiente contenido:

module WebServices
  class PokemonFailedResponse
    attr_reader :response

    def initialize(response:)
      @response = response
      @pokemon_body = pokemon_body
    end

    def pokemon_body
      {
        'error': response.body,
        'status': response.status
      }
    end

    def status
      response.status
    end
  end
end

Con esto logramos que seguir el principio S de SOLID (Single Responability) y de esta manera podemos modificar en un futuro la respuesta exitosa o fallida en su clase correspondiente.

Ahora bien si ejecutamos bundle exec rspec nuestras pruebas deberan de pasar sin ningun problema y abremos terminado con la creacion del proyecto.

Repartiendo Responsabilidades En Rails Con composed_of

Daniel — Sat, 21 Oct 2023 02:02:51 +0000

El día de hoy me encuentro estudiando más acerca de técnicas para organizar código de una manera más adecuada con las bondades que brinda Ruby On Rails.
Por lo tanto, para dar inicio solo basta un simple, problema con su solución donde tenemos un modelo Student el cual estará compuesto de las siguientes columnas:

name
qualifications

Empezaremos generando nuestra migración con el siguiente comando:

rails g migration CreateStudent

Esta debera de lucir como se muestra enseguida:

class CreateStudent < ActiveRecord::Migration[7.0]
  def change
    create_table :students do |t|
      t.string  :name
      t.json :qualifications

      t.timestamps
    end
  end
end

Con lo cual podremos generar objetos del tipo Student de la siguiente manera:

Student.create!(name: 'Daniel', qualifications: { subject_one: 10, subject_two: 9, subject_three: 8, subject_four: 10 })

Enseguida se nos pide que calculemos el promedio de las calificaciones y lo primero que hariamos es generar los modelos en nuestro modelo Student como se muestra enseguida:

class Student < ApplicationRecord
  validates :name, presence: true
  validates :qualifications, presence: true

  def average_calculation
    sum_qualificiations / qualifications.size
  end

  private

  def sum_qualificiations
    qualifications.values.inject(0, :+)
  end
end

Con esto podremos obtener el promedio de un estudiante únicamente llamando al método average_calculation es decir:

student = Student.first
student.average_calculation #=> 9

En este caso tenemos la clase Student y está debe ser capaz de únicamente tratar con temas relacionados con el estudiante, su nombre, nombre de tutor, teléfono de emergencias, etcétera.Si bien hasta aquí podemos indicar que hemos hecho lo solicitado, estamos olvidando una regla muy importante en la POO que es la responsabilidad única en clases.

El problema

Este radica en que él hacer el calculo de calificaciones no es algo que una clase como Student debería de hacer y está logica la podemos pasar a un objeto compuesto que representara las calificaciones.

Todo esto lo podemos hacer gracias al método composed_of que brinda Ruby On Rails el cual lo que hace es delegar la responsabilidad a una clase externa.

Lo anterior es llamado composition el cual podremos definirla como una relación entre dos o más clases donde podemos adquirir un comportamiento y utilizar el código que está en otra clase en nuestro objeto actual.

La solucion

Lo que tendremos que hacer son dos cosas sencillas:

Actualizar nuestro modelo Student
Generar una nueva clase.

Nuestro modelo Student se actualizara de la siguiente manera:

class Student < ApplicationRecord
  validates :name, presence: true
  validates :qualifications, presence: true

  composed_of :calculations,
              class_name: 'QualificationCalculation',
              mapping: [%w(qualifications qualifications)]

La sintaxis de composed_of cuenta con tres opciones, primero el nombre del método al cual haremos referencia (calculations), el nombre de su clase (la clase que crearemos) y el mapeo de la columna qualifications al atributo qualifications en la nueva clase.

Dicho esto procederemos a crear nuestra nueva clase (qualification_calculation.rb) justo en el directorio de modelos.

class QualificationCalculation
  attr_accessor :qualifications

  def initialize(qualifications)
    @qualifications = qualifications
  end

  def average_calculation
    sum_qualifications / qualifications.size
  end

  private

  def sum_qualifications
    qualifications.values.inject(0, :+)
  end
end

Hecho esto podemos calcular el promedio de calificación de nuestro estudiante de la siguiente manera:

student = Student.first
student.calculations.average_calculation #=> 9

De esta manera nuestro modelo original no cuenta con la responsabilidad de calcular el promedio y además si ocupamos otro calculo lo podemos agregar directamente en nuestra nueva clase QualificationCalculation.

Docker En Rails - Parte 3

Daniel — Mon, 26 Sep 2022 20:18:03 +0000

Cada vez nos estamos acercando más al final de toda esta documentación / tutorial / estudio. Por lo que antes de movernos a ver contenedores, imágenes de diferentes servicios, el docker compose (que lo amo por cierto), etcétera; vamos a tunear un poquito nuestro Docker para hacernos la vida más sencilla.

Actualizando nuestra imagen de Docker.

Primeramente empezaremos por etiquetar nuestra imagen de la aplicación, si bien recordamos que contamos con un comando para correr Rails el cual es:

docker run -p 3000:3000 458acbbc731a bin/rails s -b 0.0.0.0

Como sabemos nos referimos a nuestra imagen por medio de su ID que en este caso es 458acbbc731a y siendo sincero no hay forma en que podamos recordar esta.
Por lo tanto una mejor opción es etiquetar ese ID con un nombre con la finalidad de que esto sea más sencillo mediante el siguiente comando.

docker tag 458acbbc731a theaapp

Enseguida para verificar que el cambio funcionó de manera correcta solo será necesario listar las imágenes con docker images lo cual nos dará como resultado lo siguiente.

Una vez que tenemos nombrada nuestra imagen ahora podremos iniciar nuestro servidor de Rails utilizando esta etiqueta como se muestra enseguida.

docker run -p 3000:3000 theapp bin/rails s -b 0.0.0.0

Definitivamente esto es mucho mejor que tener que estar ingresando el id de la imagen.
Siguiendo con la afinación de nuestra imagen si nos damos cuenta cada vez que deseamos ejecutar el servidor de Rails en un contenedor tenemos que especificar explícitamente el comando bin/rails s -b 0.0.0.0 todo esto como parte del comando docker run, es decir.

docker run -p 3000:3000 theapp bin/rails s -b 0.0.0.0

Esto viene a ser algo tedioso tener que ejecutarlo cada momento; por lo tanto lo que podemos hacer es agregar una nueva instrucción a nuestro Dockerfile especificando el comando por defecto a ejecutarse cuando un contenedor inicie desde una imagen.

FROM ruby:2.6

RUN apt-get update -yqq
RUN apt-get install -yqq --no-install-recommends nodejs

COPY . /usr/src/app

WORKDIR /usr/src/app
RUN bundle install

CMD ["bin/rails", "s", "-b", "0.0.0.0"]

Como podemos observar esta nueva línea CMD ["bin/rails", "s", "-b", "0.0.0.0"] es una instrucción en donde CMD omite la notación del arreglo por lo que en teoría lo que estaría ejecutándose lo siguiente.

CMD bin/rails s -b 0.0.0.0

Una vez realizado lo anterior será momento de reconstruir nuestra imagen con la nueva instrucción CMD mediante el siguiente comando.

docker build -t theapp .

Completada la reconstrucción de nuestra imagen podremos iniciar el servidor de Rails con el siguiente comando y tendremos desplegado nuestra aplicación en localhost:3000 como siempre.

docker run -p 3000:3000 theapp

Mantenimiento extra.

Ignorando archivos.

Es necesario restringir qué archivos serán enviados como parte del contexto de construcción de una imagen, debido a que entre mas archivos enviemos más lenta será la construcción y levantamiento de las imagenes, ademas como tema de seguridad podemos evitar adjuntar archivos con información sensible, como archivos de variables de ambiente.
Para excluir ciertos archivos y directorios de ser mandados como parte del contexto de construcción deberemos de crear un archivo llamado .dockerignore el cual estara situado en la raíz de nuestra aplicación con la siguiente información.

# Git
.git
.gitignore

# Logs
log/*

# temp files
tmp/*

# Editor temp files
*.swp
*.swo

Con esto puesto en marcha deberemos de reconstruir nuestra imagen y en un futuro poder agregar archivos que no sean necesarios para la construcción de la imagen.

docker build -t theapp .

El caché de la imagen.

Durante toda esta etapa de estar descubriendo Docker estamos reconstruyendo la imagen una y otra vez, ya sea para instalar gemas o para agregar cierta configuración al proyecto, es algo que estamos haciendo.
En este momento si volvemos a reconstruir nuestra imagen tendremos como resultado lo siguiente.

La imagen se construye de una manera rápida y de hecho si miramos la salida podremos observar que en cada paso tenemos la sentencia CACHED lo cual indica a Docker que no necesita crear una nueva imagen para este paso ya que solamente reuitiliza una imagen intermedia almacenada en cache de una construcción de imagen previa.
Teniendo en cuenta lo anterior es necesario señalar que contamos con dos pequeños detalles en el cacheo de nuestro Dockerfile.

1.- Actualizando paquetes.
Actualmente nuestro Dockerfile tiene las siguientes líneas:

RUN apt-get update -yqq
RUN apt-get install -yqq --no-install-recommends nodejs

Aunque esto funciona existe un problema, digamos que en unos días más es necesario agregar el paquete de vim al proyecto.

RUN apt-get update -yqq
RUN apt-get install -yqq --no-install-recommends nodejs vim

la instrucción RUN apt-get update se mantendrá sin cambiar y utilizara la versión cacheada del repositorio, todo esto en lugar de obtener la versión más nueva del paquete que agregamos.
Es por eso que es recomendado utilizar siempre la combinación entre apt-get update y apt-get install en una sola instrucción, es decir.

RUN apt-get update -yqq && apt-get install -yqq --no-install-recommends \
    nodejs

Esto asegura que cuando cambiemos los paquetes a ser instalados, también contaremos con la información del último repositorio al mismo tiempo. Con esto puedo en marcha será momento de reconstruir la imagen para incluir estos cambios.

docker build -t theapp .

2.- Gemas instaladas.
Actualmente si hacemos un cambio en nuestro archivo Readme, lo almacenamos con los nuevos cambios y procedemos a reconstruir la imagen nuevamente tendremos como consecuencia que todas las gemas van a ser de igual manera reconstruidas en nuestro proyecto.
Por lo tanto una alternativa para esto es actualizar nuestro Dockerfile de la siguiente manera.

FROM ruby:2.6

RUN apt-get update -yqq && apt-get install -yqq --no-instal-recommends \
        nodejs

COPY GEMFILE* /usr/src/app/
WORKDIR /usr/src/app
RUN bundle install

COPY . /usr/src/app/

CMD ["bin/rails", "s", "-b", "0.0.0.0"]

El cambio sustancial aquí es que contamos con una línea COPY Gemfile* /usr/src/app que lo que hace es copiar nuestra Gemfile y Gemfile.lock dentro de nuestra imagen antes del resto de nuestro código.
Esto crea una capa separada e independiente en donde el caché de Docker para esta capa solo se disparará si alguno de estos dos archivos cambia.
Después de haber copiado nuestro Gemfile y Gemfile.lock dentro de la imagen, podremos cambiarnos al directorio en donde están e instalar nuestras gemas.

WORKDIR /usr/src/app
RUN bundle install

Finalmente con nuestras gemas instaladas podemos copiar lo que queda de nuestros archivos fuente dentro de la imagen.

COPY . /urs/src/app

Volvemos a regresar nuestro archivo README a su estado original, reconstruimos la imagen y podremos ver cómo es que el proceso fue más rápido que la última vez que lo ejecutamos.

Docker En Rails - Parte 2

Daniel — Fri, 23 Sep 2022 20:43:51 +0000

Hasta ahora hemos visto cómo crear nuestra aplicación utilizando Docker sin embargo ¿como es que podemos ejecutar nuestra aplicación con Docker?.

Para poder responder nuestra pregunta anterior lo que necesitaremos es lo siguiente.

Un archivo para la creación de imágenes (Dockerfile).
Construir nuestra imagen.
Ejecutar nuestro servidor de Rails con esta imagen creada.

El Dockerfile

Este es un documento que contiene todas las instrucciones que un usuario puede llamar en la línea de comando para la construcción de imágenes. Una vez especifiquemos todos los comandos necesarios para que corra nuestra aplicación podremos utilizar docker build el cual podremos ver más adelante para crear nuestra imagen.

Enseguida procederemos a ubicarnos en la raíz de nuestra aplicación y crear el archivo Dockerfile con el siguiente contenido.

FROM ruby:3.0.4-bullseye

RUN apt-get update -yqq
RUN apt-get install -yqq --no-install-recommends nodejs

COPY . /usr/src/app

WORKDIR /usr/src/app
RUN bundle install

Cualquier imagen debe de empezar de algún otro lugar es decir de una imagen preexistente, por lo que esta es la razón por la cual Docker empieza con la instrucción FROM la cual especifica la imagen utilizada como punto de inicio.

Pero ¿qué es eso de 3.0.4-bullseye?, pues bien esta es una imagen de Ruby la cual puede ser encontrada en el hub de docker por lo que posteriormente si necesitamos agregar dependencias como Redis, Postgresql, MySql, etcétera, este será el lugar adecuado para ir a buscarlas.

Yo en este caso estoy utilizando la versión 3.0.4-bullseye sin embargo tu puedes utilizar la versión que llegues a necesitar.

Enseguida contamos con dos instrucciones RUN que son comandos para instalar software en distribuciones de Linux (si no mal recuerdo lo utiliza Ubuntu - Debian), para distribuciones como Fedora se utiliza YUM, pero este es otro tema.

La siguiente línea con la que contamos COPY estara como lo dice el comando copiando todos los archivos de nuestro directorio actual a el sistema de archivos de nuestra imagen dentro de /usr/src/app.

Enseguida contamos con WORKDIR que realiza lo mismo que el comando cd de Unix por lo que cambiará a lo que la imagen considera su directorio actual.

Finalmente tenemos la linea Run bundle install la cual como sabemos instalará todas las gemas definidas en el Gemfile de nuestro proyecto de Rails.

Con todo esto puesto dentro de nuestro Dockerfile procederemos a crear nuestra imagen con el siguiente comando.

docker build .

Esto como lo comentamos nos creara nuestra imagen por lo que en la salida de terminal tendremos algo parecido a lo siguiente.

Cabe mencionar que el comando docker build no nos entregara algún archivo en la salida. Este solo va a hacer que la nueva imagen esté disponible, agregandola a la lista de imágenes que Docker conoce y esto lo podemos ver con el comando docker images.

Ejecutando nuestro servidor de Rails con nuestra imagen

Ahora que ya tenemos nuestra imagen creada deberíamos de tener la habilidad de levantar nuestro servidor de Rails para ejecutar nuestra aplicación.

Para efectos prácticos vamos a referirnos a nuestra imagen por su ID sin embargo esto cambiará más adelante ya que como podemos apreciar en la última imagen (IMAGE ID) es un alfanumérico que se volvera un martirio estar tipeando en la terminal cada vez.
Por lo tanto para poder levantar Rails dentro del contenedor solo deberemos de ejecutar el siguiente comando.

docker run -p 3000:3000 458acbbc731a bin/rails s -b 0.0.0.0

Si todo sale de manera correcta lo que tendremos cómo resultado será lo siguiente:

Enseguida si visitamos la dirección http://localhost:3000 en nuestro navegador podremos apreciar que Rails se está ejecutando de manera correcta.

YEI! nuestra aplicación ya se está ejecutando de manera local pero ¿cómo es posible que pueda verlo en mi navegador?.

Pues bien esto se debe a que nosotros por medio de la opción docker run -p le indicamos a Docker que haga accesible externamente uno o más puertos.

Por lo que cuando especificamos -p 3000:3000 estamos indicando al contenedor que publique el puerto 3000 en el puerto 3000 de nuestra máquina local, lo cual viene a significar que una petición a nuestro localhost:3000 alcanzará a nuestro servidor de Rails dentro del contenedor en el puerto 3000.

Docker En Rails - Parte 1

Daniel — Thu, 08 Sep 2022 01:26:52 +0000

Tengo tiempo escuchando acerca de Docker (en realidad años), actualmente puedo decir que se como ejecutar algunos comandos para correr aplicaciones sin problemas, sin embargo si me llegan a preguntar cosas como ¿que es una imagen?, ¿que es un contenedor?, ¿como es que se puede agregar Docker a una aplicación?, sinceramente me quedaría en blanco.

Por lo tanto durante esta serie de posts que estaré creando a lo largo de unas cuantas semanas planeo adentrarme a su conocimiento y funcionamiento, todo esto con la finalidad de aprender y compartir como me fue en el camino de conocer esta gran herramienta que desde mi punto de vista debe ser un "must to have" si te encuentras en el desarrollo de software.
Así que a ti que estás leyendo esto que si aprecias algún error o detalle házmelo saber con la finalidad de actualizar todos estos posts. Estoy empezando en este proceso de aprender Docker y puede que durante el proceso escriba una que otra tarugada, por lo tanto ahí te encargo.

Toda la información que vaya a estar publicando de acuerdo a este tema (Docker) estara basado en información de terceros que recopile y estudie de diversas fuentes, por lo que las siguientes entradas a recursos se van a estar actualizando según progrese en el camino.

Libros:
- Docker for rails developers

¿Qué es Docker?

Esta es una herramienta que sirve para empaquetar y ejecutar software en pequeños entornos de pruebas (sandbox environments) conocidos como contenedores en donde se ubicara todo lo necesario para poder ejecutar nuestra aplicación.

Dado lo anterior puede surgir la pregunta ¿qué es un contenedor?, pues bien este es un entorno sandbox aislado que empaqueta todo el código y dependencias de una manera estándar; Este ambiente que proveemos cuando creamos un contenedor estara construido de varias capas con la meta de ejecutar código dentro del contenedor (una imagen).

Dicho lo anterior entonces en una imagen generalmente podemos configurar variables de entorno, comandos a ejecutar de algún framework o de unix, etcétera. Por lo tanto podemos definir a una imagen coloquialmente hablando como eso que nos va a servir como punto de entrada para nuestros contenedores.

Algo que debemos de tener en cuenta es la diferencia entre una máquina virtual y un contenedor.
Una máquina virtual es un sistema operativo completo funcionando de manera aislada dentro de otro sistema operativo host (el SO de nuestro equipo local), además de que cuando hablamos de una máquina virtual debemos de hacer uso de GB de nuestro equipo, memoria ram compartida, etcétera.
Un contenedor en cambio aísla el entorno de trabajo, no tiene su propio sistema operativo si no que más bien lo que hace es compartir recursos de nuestro equipo local con este.

¿Por qué deberíamos estar utilizando Docker?

Generalmente en un equipo de desarrollo hay cambios y es algo totalmente inevitable, por lo tanto debido a estos cambios imaginemos que tenemos una gran rotación, llegando nuevos desarrolladores y cada uno de ellos debe configurar los proyectos en sus equipos; esto va a consumir tiempo debido al sistema operativo, dependencias de terceros, configuraciones, etcétera y si bien esto se lee como algo que siempre hemos estado haciendo es algo tedioso y que lamentablemente me ha tocado vivir en persona.

Aquí es cuando desde mi punto de vista siento que vale la pena aprender y utilizar Docker ya que viene a realizar una automatización de configuración e instalación a el proyecto con la finalidad de que con unos cuantos comandos ya podamos tener la aplicación ejecutándose en nuestro equipo sin detalles.

Instalando Docker

Antes de proceder a adentrarnos a crear una aplicación Dockerizada necesitamos tener instalado Docker en nuestro equipo, por lo que para hacerlo podemos dirigirnos al siguiente sitio Docker Desktop y escoger en la sección de Download and Install la versión que necesitemos según nuestro sistema operativo.

Una vez que esté instalado Docker en nuestro equipo procederemos a abrir una terminal y ejecutar el siguiente comando y lo cual nos deberá arrojar lo que se muestra en la imagen posterior.

docker version

Creando una nueva aplicación de Rails con Docker.

Para poder ejecutar un servidor de Rails en nuestro ambiente local este necesita contar con algunos requerimientos, como por ejemplos tener un intérprete de JavaScript instalado (por lo menos en la versión 6 para Rails ya en Rails 7 es otro tema), tener nuestras gemas instaladas, librerías de terceros, etcétera.

Por lo tanto empezaremos de menos a más primero conociendo cómo movernos dentro de Docker y una vez que tengamos un poco dominado conceptos y algunas características vamos a utilizar esta misma aplicación base para estar trabajando con ella en el futuro.

Procederemos entonces a crear un nuevo directorio en el lugar deseado, por ejemplo yo lo voy a crear dentro de mi escritorio con el nombre de docker_and_rails una vez que lo hayamos creado procederemos a entrar a el.

1: cd Desktop
2: mkdir docker_and_rails
3: cd docker_and_rails
```


Posteriormente vamos a iniciar una sesión interactiva en Bash con la finalidad de instalar Rails de manera adecuada, por lo tanto ejecutaremos el siguiente comando.


```
docker run -i -t --rm -v ${PWD}:/usr/src/app ruby:3.0.4-bullseye bash
```


Esto nos arrojará en terminal un output muy parecido al siguiente que enseguida vamos a explicar.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jp03wx6jfq6hvak6i8o1.png)

Primero tenemos la advertencia de que no fue posible encontrar la imagen de ruby 3.0.4 localmente y esto se debe a que no lo hemos instalado, sin embargo Docker es inteligente y sabe que debe ejecutar esta instrucción por lo tanto procede a descargar esta imagen desde las imágenes oficiales de Ruby en Docker [Ruby Images On Docker](https://hub.docker.com/_/ruby) en partes y  posteriormente después de haber descargado la imagen podremos ver que tenemos en terminal **root@0254d2520dc7** lo cual nos indica que estamos ejecutando una sesión de Bash dentro de un contenedor.

Acto seguido entraremos a el directorio que especificamos en el comando anterior para crear el nuevo proyecto de Rails.


```
root@0254d2520dc7:/# cd /usr/src/app
```


Ahora es turno de instalar dentro de este directorio la gema de Rails.


```
root@0254d2520dc7:/# gem install rails
```


Una vez que hayamos instalado la gema de Rails y todas sus dependencias hayan sido instaladas vamos a estar listos para generar nuestro proyecto.


```
root@0254d2520dc7:/# rails new theapp --skip-test --skip-bundle
```


Estamos utilizando las opciones de **skip-test - skip-bundle** debido a que posteriormente utilizaremos RSpec para configurarlo dentro de nuestro proyecto y además indicamos con este comando que no se ejecute **bundle install** después de generar nuestro proyecto.

Bueno como ahora nuestro proyecto ya fue generado es necesario recordar que estamos dentro de una sesión de Shell dentro de nuestro contenedor por lo que tendremos que salirnos con el comando **exit**.

Enseguida si ejecutamos el comando **ls** dentro del mismo directorio donde estamos (docker_and_rails) podremos apreciar que contamos con un nuevo directorio llamado **theapp** y si ingresamos a este tendremos toda la estructura básica que una aplicación de Rails necesita para poder vivir.

¿Y por qué fue que se creó este nuevo directorio en nuestro equipo local?, pues bien esto se debe a la opción **-v** dentro de en el comando **docker run** que previamente escribimos, en el lenguaje de de Docker y esta opción indica que se monte un volumen es decir compartir una porción de nuestro sistema de archivos local con el contenedor.

Por lo que **-v ${PWD}:/usr/src/app** indica montar nuestro directorio actual dentro del contenedor en **/usr/src/app**.

Cuando hablamos de montar un volumen local significa que el proyecto de Rails generado dentro del contenedor en **(/usr/src/app)** se mantiene en nuestro directorio local incluso después de que el contenedor se haya terminado. 

De esta manera todos los cambios que hagamos en nuestros archivos locales de nuestro proyecto se van a ver reflejados automáticamente dentro del contenedor.

ViewComponent On Rails

Daniel — Wed, 20 Oct 2021 17:46:45 +0000

Introducción.

Si hay algo que siempre me ha gustado de ruby/rails es su comunidad, siento que es una comunidad súper rica en nuevas propuestas, que sigue con buenas convenciones y que ademas siempre trata de tener el código ordenado. De tal manera que al momento de crear algo nos evitemos tantos comentarios en el código y este hable por si mismo.

Que es ViewComponent?.

ViewComponent viene a ser un entorno de trabajo para la creación de componentes encapsulados de vistas que pueden ser reutilizables y testeables con mayor facilidad.
En este breve tutorial nos vamos a enfocar en crear ViewComponents básicos.

La problemática (Barra de progreso)!

Supongamos que tenemos la necesidad de crear una barra de progreso para varias vistas en una aplicación.
Por ejemplo en una todo list o en un finance tracker o algo parecido, el caso es que queremos que por lo menos este mas de una vez repetido este componente sobre nuestra aplicación.
Primero que nada imagínense la repetición de código HTML que vamos a tener que incorporar en nuestra aplicación, sinceramente esto no es practico y para nada estaríamos respetando el DRY.

<div class="progress">
  <div class="progress-bar" role="progressbar" style="width: <%= @valor_de_tu_objeto %>" aria-valuenow="<%= @valor_de_tu_objeto %>" aria-valuemin="0" aria-valuemax="100"></div>
</div>

Lo cual nos desplegara lo siguiente en cada una de las vistas que deseemos.

Para venir a salvarnos de este tipo de cosas y tener mejor organizado nuestro código aquí es en donde se presentan los ViewComponents.

Hands On

Para poder hacer uso de los ViewComponents es necesario instalar la siguiente gema.

gem "view_component", require: "view_component/engine"

# Posteriormente ejecutar bundle install

Una vez instalada la gema procederemos a crear el componente con el siguiente comando.

bin/rails g component ProgressBarComponent value

Este comando nos creara mas o menos la siguiente salida en terminal

invoke test_unit
create test/components/progress_bar_component_test.rb
create app/components/progress_bar_component.rb
create app/components/progress_bar_component.html.erb

Por lo tanto con esto podemos deducir que un ViewComponent esta compuesto por un archivo (progress_bar_component.rb) y una plantilla (progress_bar_component.html.erb).
Dado que cuando ejecutamos el generador de componentes pasamos un atributo (value) entonces nuestro component lucirá de la siguiente manera.

# app/components/progress_bar_component.rb

# frozen_string_literal: true

class ProgressBarComponent < ViewComponent::Base
    def initialize(value:)
      @value = value
    end
end

Ahora sera momento de agregar nuestro código HTML para la barra de progreso de la siguiente manera.

# app/components/progress_bar_component.html.erb
<div class="progress mb-4">
  <div class="progress-bar bg-info" role="progressbar" style="width: <%= @value %>%;" aria-valuenow="<%= @value %>" aria-valuemin="0" aria-valuemax="100" ></div>
</div>

Llamada desde una vista diferente

Supongamos que deseamos ahora llamar a este componente desde una vista index en donde tengamos una todo list con una cantidad de porcentaje completado de un modelo, para poder hacerlo deberíamos de hacerlo de la siguiente manera.

Calculamos el porcentaje completado de todos.

# app/models/todo.rb
def percent_complete
  Todo.count == 0 ? 0 : (100 * completed_items.to_f / total_items).round(1)
end
# El método anterior se puede descomponer para hacerlo mas legible ya lo dejo a su criterio.

Mandamos a llamar desde la vista que deseemos implementar la barra de progreso.

# app/views/todos/index.html.erb
<%= render(ProgressBarComponent.new(value: @todo.percent_complete)) %>

De esta manera este componente es totalmente re-utilizable en cualquier otra vista de nuestra aplicación sin necesidad de escribir nuevamente el código HTML y solo mandando a llamar al componente por medio del método render.

Fuentes y Recomendaciones.

View Components
Revisen con detenimiento las colecciones con ViewComponents son una chulada para reducir código.
He estado probando los ViewComponents con alguna que otra cosilla de Stimulus Reflex (en algún momento hablare acerca de este tema) y les puedo comentar que trabajan muy bien en conjunto.

Bloques con Ruby

Daniel — Wed, 13 Oct 2021 20:20:15 +0000

Hoy en día cuando hablamos de Ruby no podemos dejar de lado los bloques. Estos vienen a ser una parte súper importante al momento de estar (como se dice en mi barrio) tirando código y su complejidad puede variar dependiendo nuestras necesidades.

Lo básico

Comúnmente utilizamos bloques para iterar, generalmente sobre las vistas con objetos en Rails, por ejemplo:

<%= @elements.each do |e|%>
  <% e.inspect %>
<% end %>

Como podemos ver este es un bloque ejecutado desde una vista de Rails. Sin embargo transportando esto a un código sin frameworks, contamos con dos versiones para poder generar bloques los cuales son los siguientes:

* La versión larga
# Esta versión generalmente la uso cuando se que voy a realizar alguna operación dentro del bloque y se que voy a ocupar mas de una linea.
elements.each do |e|
  # operacion 1
  # operation 2
  # ........
end

* La versión corta
# Esta la utilizo cuando solo necesito una linea de retorno y la operacion no es muy compleja.
elements.each{|e| puts e}

Profundizando un poco mas en bloques.

Sin embargo que pasa cuando deseo llamar a un método y ademas requiero pasar una serie de instrucciones extra durante su invocación, como es que puedo realizar esto?
Agradezcamos a yield que viene a ayudarnos a realizar este tipo de acciones.

Supongamos que contamos con una tarea de convertir una cadena de asteriscos en una mitad de pirámide de caracteres, es decir:

half_pyramid_converter(*********) 
# Output deseado
*
**
***
****
.........n

Para poder hacer esto crearemos un algoritmo que realice el trabajo y posteriormente refactorizaremos

# Version larga
def half_pyramid_converter(characters)
  index = 0
  piramid = ""
  while(index < characters.length)
    yield(piramid << characters[index]) if block_given?
    index+=1
  end
end

# Version refactorizada
def half_pyramid_converter_refactor(characters)
  piramid = ""
  characters.each_char {|char| yield( piramid << char) if block_given?}
end

# Llamadas 
half_pyramid_converter("*******"){|c| puts "#{c}"}
half_pyramid_converter_refactor("**********"){|c| puts "#{c}"}

Como podemos ver en la primer versión lo que hacemos es comparar la variable index contra el tamaño de la cadena si es menor agregamos el carácter a la variable piramid y gracias a yield nuevamente estaremos ejecutando lo que se encuentra dentro de los bloques.
En la segunda versión refactorizada hacemos uso del método each_char que nos brinda la clase String de Ruby, por lo tanto como dice el dicho un poco modificado "you can have your cake and eat it too", es decir si ya esta ahí pues
hagamos uso de este.

Recomendaciones

Tal vez te pueda interesar echarle un ojo a el modulo Enumerable. Ya que en conjunto con los bloques es una gran herramienta para iterar y hacer cosas interesantes.
Utiliza el método block_given? para detectar si estamos pasando un bloque. De esta manera te evitaras el error "no block given (yield) (LocalJumpError)".
Ten en cuenta que el código que se vaya a ingresar en nuestro método iterador es el código de alguien mas, por lo tanto protegelo mediante excepciones.
Si vas a estar haciendo operaciones dentro de los métodos junto con bloques es recomendable utilizar el patrón compossed method, de esta manera el código queda mas legible para futuros devs que se montaran sobre este.

Omniauth + Devise + Rails Tutorial

Daniel — Mon, 04 Oct 2021 21:39:37 +0000

Una breve introducción.

Que tal buen día, me presento mi nombre es Daniel o Dany para los compas. Es mi primera vez escribiendo por aquí por lo tanto pido disculpas anticipadas si encuentran alguna falta ortográfica o alguna mala dicción en el contenido que vaya a estar liberando nuevos posts de cosas que me interesen.

Empiezo con toda esta idea de crear contenido en español debido a que si bien hay mucho contenido (tutoriales/herramientas/etcétera) en ingles explicando como realizar ciertas cosas o tips & tricks, hoy en día casi no hay contenido que pueda ser beneficioso para personas que no tengan muy buenas habilidades a la hora de leer/comprender contenido en ingles (que por cierto en esta carrera de desarrollador es algo que deberían de tener en sus metas a corto plazo). Por lo tanto espero que les agrade la información que vaya posteando por aquí.

By the way, se habla English too, so if you have any question regarding the topic just let me know in the comments section.

Stack

Las herramientas/gemas que serán necesarias para crear esta aplicación serán las siguientes:

omniauth-google-oauth2.
omniauth (en caso de tener algun error).
omniauth-rails_csrf_protection
devise
postgresql instalado en nuestro equipo.
ruby 3.0.
rails 6 o mayor.
Google API keys.

Configurando Google API keys

Deberemos de tener una cuenta de google cloud platform, una vez teniendo nuestra cuenta creada procederemos a dirigirnos a nuestro dashboard principal. En donde una vez situado sobre este procederemos a abrir el panel que se encuentra a la izquierda (el icono de hamburguesa) y hacer clic en la opción de API y Servicios.

Una vez situado sobre nuestro dashboard de API y Servicios procederemos a hacer clic en la opción de credenciales que se encuentra del lado izquierdo de nuestra pantalla. Posteriormente haremos clic en crear credenciales y en la opción de ID de cliente de OAuth.

Al momento de seleccionar esta opción deberemos de escoger un tipo de aplicación entre el listado que muestra el dropdown, que en este caso sera Aplicación Web. Hecho esto deberemos de agregar un nombre de nuestro cliente Omniauth el cual en este caso sera Omniauth Integration.
Ahora es momento de situarnos en las opciones de orígenes autorizados de javascript - URI de re direccionamiento autorizados, los cuales deberán de contener lo siguiente:
- Orígenes autorizados de javascript: http://localhost:3000
- URI de re-direccionamiento autorizados:http://localhost:3000/users/auth/google_oauth2/callback

Acto seguido solo deberemos de hacer clic en crear.

Realizado el punto anterior inmediatamente seremos redirigidos a nuestro dashboard de API y Servicios con una ventana emergente la cual nos brindara nuestro client id y nuestro secret key los cuales son datos que deberemos de almacenar en nuestro equipo o bien descargar el archivo JSON que se nos proporciona para tener resguardada esta información que deberá ser integrada posteriormente en nuestra aplicación.

Creando La Aplicación.

Empezaremos por crear la aplicación con el siguiente comando.

rails new OmniauthExample --database=postgresql

Lo que realizara este comando es crear nuestra aplicación con la base de datos postgresql, por lo que no deberías de tener problemas siempre y cuanto tengas instalado/configurado postgresql de manera correcta. En caso de no tenerlo lo puedes realizar sin problema con el gestor de base de datos por defecto en Rails (Sqlite).

Empezaremos por abrir nuestro proyecto OmniauthExample y posteriormente instalaremos las siguientes gemas.

gem 'devise'
gem 'omniauth-google-oauth2'
gem "omniauth-rails_csrf_protection"

Ejecutaremos bundle install para la instalación de las gemas en nuestro proyecto y con esto estaremos terminando la configuración de nuestra aplicación.

Una vez instaladas nuestras gemas de manera correcta, procederemos a configurar devise por medio de los siguientes comandos en consola.

rails generate devise:install

En caso de querer generar las vistas por defecto de devise (que en este caso no lo haremos) y poder modificarlas en un futuro con nuestro propio estilo podemos ejecutar el siguiente comando en consola.

rails generate devise:views

Posteriormente procederemos a crear nuestro modelo User o Admin (ustedes deciden el nombre) en este caso sera User.

rails generate devise User

Esto nos creara algunas cosas a tomar en cuenta como es el caso de el modelo user, la tabla users y una linea en nuestro archivo routes.rb el cual nos brindara todas nuestras acciones REST para nuestro modelo user.

devise_for :users

Dentro de este mismo archivo llamado config.rb procederemos a realizar algunos cambios los cuales serán explicados enseguida.

Rails.application.routes.draw do
  root to: 'home#index'
  devise_for :users, controllers: {
                                    omniauth_callbacks: 'users/omniauth_callbacks',
                                    sessions: 'users/sessions'
                                  }
  devise_scope :user do
    get 'sign_out' => 'devise/sessions#destroy'
  end
end

la linea de root indica que tendremos una ruta raiz (la vista principal) por medio del controlador home y la accion index.
devise_scope :user... esto lo creamos para tener un poco mas de personalizacion, de esta manera devise utiliza el scope user cuando accedemos a sign_out.
devise_for :users... indica que tendremos el controlador omniauth_callbacks y el controlador sessions dentro de un directorio users en controllers, es decir.
Vamos a crear un poco de código boiler plate con cada una de las clases de la siguiente manera.

# OmniauthController
class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController
end
# SessionsController
class Users::SessionsController < Devise::SessionsController
  def after_sign_out_path_for(_resource_or_scope)
    new_user_session_path
  end

  def after_sign_in_path_for(resource_or_scope)
    stored_location_for(resource_or_scope) || root_path
  end
end
# HomeController
class HomeController < ApplicationController
  def index
  end
end

Acto seguido deberemos de agregar en nuestro modelo user en la sección de devise modules la característica para que la aplicación funcione con Omniauth de la siguiente manera.

devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable,
         :omniauthable, omniauth_providers: %i[google_oauth2]

Por ultimo y no menos importante deberemos de crear las bases de datos en nuestro desarrollo local con el siguiente comando y ejecutar nuestras migraciones.

# Creando las bases de datos
rails db:create
# Ejecutando migraciones
rails db:migrate

Configurando nuestras keys en la aplicación.

Para poder configurar nuestras keys del API de google contamos con dos enfoques (en este caso solo utilizaremos uno), el primero puede ser con una gema llamada dotenv en donde una vez instalada podremos agregar las llaves a un archivo con el nombre de .env sin ningún problema. Sin embargo Rails por defecto ya tiene un archivo de configuración para guardar nuestras llaves llamado credentials.yml.enc el cual es un archivo encriptado con todas nuestras variables de entorno necesarias para nuestra aplicación. Por lo tanto para hacer uso de este (en visual studio code) lo deberemos de abrir con el siguiente comando.

EDITOR="code --wait" rails credentials:edit

Una vez realizado lo anterior tendremos un pop-up el cual prácticamente le deberemos dar clic en ok y esto a su vez nos presentara el archivo credentials.yml.enc des-encriptando con lo cual podremos agregar nuestras keys de la siguiente manera y procederemos a salvar el archivo con sus modificaciones. Con la finalidad de poder ver si nuestras credenciales fueron agregadas a nuestra aplicación solo deberemos de ejecutar el comando.

rails credentials:show

El cual nos desplegara en terminal todas las keys que hayamos agregado a este archivo. En lo personal a mi me gusta mas este approach ya que así nos evitamos de depender de dependencias externas a nuestro proyecto y se lo dejamos ya directamente a Rails para que lo maneje.

El ultimo paso de configuración que deberemos de hacer es directamente en el archivo devise.rb en la linea en donde aparezca la opción Omniauth (entre 270 - 280) y dentro de este agregaremos lo siguiente.

config.omniauth :google_oauth2, Rails.application.credentials.google[:google_id_client], Rails.application.credentials.google[:google_secret_key], access_type: "online"

Adaptando la funcionalidad a nuestra aplicación.

Hasta este momento si corremos nuestro servidor local tendremos un detalle debido a que no hemos creado ninguna vista para desplegar información, algo muy parecido a esto.

Por lo tanto lo que debemos de hacer es crear nuestra vista index dentro del home en nuestro directorio views, es decir.
Posteriormente deberemos de agregar algo de contenido a esta vista index, por lo que el codigo que agregaremos sera el siguiente.

<h1>This is the index view of home controller</h1>
<%= link_to "Login With Google", user_google_oauth2_omniauth_authorize_path, method: :post %>

Hasta ahora todo va a marchar bien sin embargo si hacemos click en el vinculo Login With Google tendremos como resultado lo siguiente en nuestro pantalla.

Esto se va a deber a que hasta el momento no hemos integrado una llamada a omniauth desde nuestra aplicación, por lo que vamos a tener que trabajar con algunas cosas que enseguida se listan.

Crear una miagracion para agregar los campos provider - uid dentro de nuestra tabla users.
Crear un método dentro del modelo user para que se retorne el usuario si ya fue creado en nuestra base de datos o si no en su defecto crearlo.
Crear la lógica para el controlador omniauth_callback.
Empezaremos por crear nuestra migración para agregar los campos.

rails generate migration addFieldsToUser provider:string uid:string

Esto nos creara un archivo de migración, por lo cual debemos de ejecutar nuestras migraciones con rails db:migrate

Enseguida agregaremos el siguiente código a nuestro modelo user.rb

Prácticamente lo que estamos haciendo aquí es retornar un usuario en base en su correo en la linea 9. En caso de no encontrarlo lo va a crear en nuestra base de datos y posteriormente retornarlo.

Posteriormente deberemos de crear la lógica para nuestro controlador omniauth de la siguiente manera.

Realizado esto reiniciaremos nuestro servidor solo con fines de empezar con todo el proceso desde el principio y nos ubicaremos en nuestra ruta principal localhost:3000. En donde al intentar hacer clic en nuestro vinculo "Login With Google" podremos ver que tendremos integrada de manera correcta la funcionalidad de Omniauth.

Por ultimo para atar cabos sueltos y poder visualizar que en efecto hicimos login, vamos a crear una nueva ruta en routes.rb con lo que al final nuestro archivo deberá de quedar así.

Rails.application.routes.draw do
  root to: 'home#index'
  # Esta es la nueva ruta que agregamos
  get 'omniauth_test', to: 'home#display_omniauth'

  devise_for :users, controllers: {
                                    omniauth_callbacks: 'users/omniauth_callbacks',
                                    sessions: 'users/sessions'
                                  }
  devise_scope :user do
    get 'sign_out' => 'devise/sessions#destroy'
  end
end

Por lo que enseguida deberemos de crear dentro de views/home el archivo display_omniaut.rb con una simple etiqueta html.

<h1>You are logged in now with google.</h1>

Con esto por fin si intentamos hacer todo el flujo al final tendremos como resultado la siguiente vista.

Recomendaciones

Ahora que ya tenemos la funcionalidad creada para nuestra aplicación, lo que desde mi punto de vista yo recomiendo es que realices lo siguiente.

Crear un servicio para manejar las llamadas a Omniauth, de esta manera el código estará mas DRY. (esto lo puedes ver en el repo de la aplicación que acabamos de crear). Una buena guía para esto la agrego enseguida Ruby Service Objects.

Ademas cabe mencionar que con esto estamos respetando uno de los principios de SOLID el cual es Single Responsability en donde una clase solo tiene que tener una responsabilidad, por lo que como pista te dejo mover toda la funcionalidad de user.rb a el servicio que vayas a crear y llamarlo desde el omniauth_callbacks_controller de la siguiente manera.

user = OmniauthService.call(request.env['omniauth.auth'])

Crear todo el proceso de login/logout junto cons sus hooks en application controller para cuando el usuario desee acceder a cierta pagina se compruebe que haya iniciado sesion.
Investigar acerca de como testear con rspec o minitest segun sea tu preferencia service objects y la integracion de omniauth.

Repo.

Omniauth Example.