DEV Community: Kattya Cuevas

Buenas Practicas en Rails

Kattya Cuevas — Mon, 29 Apr 2024 19:00:00 +0000

¿Por qué son tan importantes las buenas prácticas en Ruby on Rails o en cualquier proyecto?
Las razones son muchas pero 3 de las más importantes son:

Mantenimiento del código: Un código bien estructurado y organizado es más fácil de mantener y de modificar. Esto es especialmente importante en proyectos a largo plazo.
Colaboración en equipo: En proyectos con varios desarrolladores, seguir buenas prácticas ayuda a que todos los miembros del equipo puedan entender y trabajar en el código de los demás. Y si tu equipo aún es pequeño, seguir buenas prácticas te ayudará a que cuando crezca, la transición sea más sencilla.
Calidad del código: Las buenas prácticas ayudan a prevenir errores y vulnerabilidades de seguridad, lo que se traduce en un código más robusto y confiable. Además, facilitan la detección y corrección de errores.

Rails es mágico, pero no adivino

Ruby on Rails es un framework que fomenta muchas buenas prácticas por defecto. Una clara muestra de ello es:

Rails sigue el patrón de diseño Modelo-Vista-Controlador (MVC) y tiene una estructura de archivos y carpetas predefinida que facilita la separación de preocupaciones. Esto es un gran punto a favor del principio de responsabilidad única.
Rails sigue el principio convención sobre la configuración, lo que significa que sigue ciertas convenciones y buenas prácticas por defecto. Por ejemplo, Rails espera que los nombres de las tablas de la base de datos estén en plural y en minúsculas, y que los nombres de las clases de los modelos estén en singular y en mayúsculas.

Sin embargo, mientras más crezca tu proyecto, más probable es que necesites personalizar y extender la funcionalidad de Rails, o que necesites integrar otras gemas o servicios. En estos casos, es importante conocer y seguir buenas prácticas para mantener la calidad y la coherencia del código.

Buenas Prácticas con las que puedes empezar

Arquitectura Avanzada

Una de las áreas en las que puedes profundizar es en la arquitectura avanzada de Rails. Algunos temas que puedes explorar son:

Patrones de diseño avanzados: Rails ofrece muchas posibilidades para implementar patrones de diseño avanzados, como Service Objects, Decorators, etc. Estos patrones te ayudarán a mantener un código más limpio y modular.
Gemas especializadas: Existen muchas gemas especializadas que pueden mejorar la arquitectura de tu aplicación, como Trailblazer, ViewComponent, Cells, etc. Estas gemas te permiten implementar funcionalidades avanzadas y mantener una arquitectura más escalable y mantenible.

Patrones de diseño avanzados

Los patrones de diseño son soluciones generales a problemas comunes en el diseño de software. Algunos patrones de diseño avanzados que puedes aplicar en Rails son:

Decorators: Los Decorators son objetos que envuelven a otros objetos y añaden funcionalidades adicionales. Son útiles para añadir presentación y lógica de vista a tus modelos sin sobrecargarlos. Ejemplo de Decorator en Rails:

class ProductDecorator < SimpleDelegator
  def formatted_price
    number_to_currency(price)
  end
end

Policy Objects: Los Policy Objects son objetos que encapsulan la lógica de autorización de tu aplicación. Son útiles para centralizar la lógica de autorización y mantener un código más limpio y reutilizable. Ejemplo de Policy Object en Rails:

class OrderPolicy
  def initialize(user, order)
    @user = user
    @order = order
  end

  def can_create?
    @user.admin? || @user == @order.user
  end
end

Presenters: Los Presenters son objetos que encapsulan la lógica de presentación de tu aplicación. Son útiles para separar la lógica de presentación de los modelos y controladores, y para mantener un código más limpio y reutilizable. Ejemplo de Presenter en Rails:

class ProductPresenter
  def initialize(product)
    @product = product
  end

  def formatted_price
    number_to_currency(@product.price)
  end
end

Service Objects: Los Service Objects son objetos que encapsulan la lógica de negocio de tu aplicación. Son útiles para separar la lógica de negocio de los controladores y modelos, y para mantener un código más limpio y modular. Ejemplo de Service Object en Rails:

class CreateOrderService
  def initialize(user, product)
    @user = user
    @product = product
  end

  def call
    order = @user.orders.create(product: @product)
    SendOrderConfirmationEmailJob.perform_later(order)
    order
  end
end

Query Objects: Los Query Objects son objetos que encapsulan consultas complejas a la base de datos. Son útiles para mantener un código más limpio y reutilizable, y para separar la lógica de consulta de los modelos y controladores. Ejemplo de Query Object en Rails:

class ProductsQuery
  def initialize(relation = Product.all)
    @relation = relation
  end

  def cheap_products
    @relation.where('price < ?', 100)
  end
end

Gemas especializadas

Además de los patrones de diseño avanzados, existen muchas gemas especializadas que puedes utilizar en Rails para mejorar la arquitectura de tu aplicación. Algunas gemas especializadas que puedes explorar son:

Trailblazer: Trailblazer es un framework que te ayuda a implementar patrones de diseño avanzados en Rails, como Services (Operation), Presenter, etc. Trailblazer te permite mantener una arquitectura más limpia y modular. Ejemplo de Operation en Trailblazer:

class CreateOrder < Trailblazer::Operation
  step :validate
  step :create_order

  def validate(ctx, params:, **)
    ctx[:order] = Order.new(params)
    ctx[:order].valid?
  end

  def create_order(ctx, order:, **)
    order.save
  end
end

ViewComponent: ViewComponent es una gema que te ayuda a implementar componentes reutilizables en Rails. Los componentes de ViewComponent te permiten separar la lógica de presentación de los modelos y controladores, y a mantener un código más limpio y modular. Está inspirado en el concepto de componentes de React. Ejemplo de componente en ViewComponent:

class MessageComponent < ViewComponent::Base
  erb_template <<-ERB
    <h1>Hello, <%= @name %>!</h1>
  ERB

  def initialize(name:)
    @name = name
  end
end

Cells: Cells es una gema que te ayuda a implementar celdas reutilizables en Rails. Las celdas de Cells te permiten encapsular la lógica de presentación en componentes reutilizables, y a mantener un código más limpio y modular. Ejemplo de celda en Cells:

class ProductCell < Cell::ViewModel
  def show
    model.name + ' ' + model.price
  end
end

<% @products.each do |product| %>
  <%= cell(ProductCell, product) %>
<% end %>

AASM: AASM es una gema que te ayuda a implementar máquinas de estado en Rails. Esto te permiten modelar el comportamiento de tus modelos de forma más clara y modular, y a mantener un código más limpio y mantenible. Ejemplo de máquina de estado en AASM:

class Order < ApplicationRecord
  include AASM
  aasm do
    state :pending, initial: true
    state :confirmed, before_enter: :send_confirmation_email
    state :shipped
    state :delivered
    after_all_transitions :log_status_change
    event :confirm do
      transitions from: :pending, to: :confirmed
    end
    event :ship do
      after do
        send_shipping_notification
      end
      transitions from: :confirmed, to: :shipped
    end
    event :deliver do
      transitions from: :shipped, to: :delivered
    end
  end
end

Adicionalmente, la comunidad de Rails es muy activa y hay muchas gemas que pueden ayudarte a mejorar o avanzar rápidamente en tu proyecto. Una buena práctica es investigar y evaluar las gemas antes de integrarlas en tu proyecto, para asegurarte de que cumplen con tus necesidades y estándares de calidad. Y también recordar que muchas de las funcionalidades comunes entre proyectos ya tienen gemas que las implementan, y estas se dedican a mejorar y mantener esas funcionalidades, sobretodo en términos de seguridad.

Rendimiento y Escalabilidad

Otro aspecto importante en el desarrollo de aplicaciones web es el rendimiento y la escalabilidad. Algunos temas que puedes explorar en este ámbito son:

Optimización de rendimiento: Rails ofrece muchas posibilidades para optimizar el rendimiento de tu aplicación, como el uso eficiente de caché, la fragmentación de vistas, etc. Estas estrategias te ayudarán a mejorar la velocidad de carga de tu aplicación y la experiencia del usuario.
Arquitecturas escalables: Si tu aplicación crece, es importante tener en cuenta la escalabilidad. Algunas estrategias para implementar arquitecturas escalables en Rails son el uso de microservicios, el sharding de la base de datos, etc. #### Optimización de rendimiento La optimización de rendimiento es un aspecto crítico en el desarrollo de aplicaciones web, ya que influye directamente en la experiencia del usuario y en la eficiencia de la aplicación. Algunas estrategias para optimizar el rendimiento de tu aplicación en Rails son:
Uso eficiente de caché: Rails ofrece muchas posibilidades para implementar caché en tu aplicación, como el uso de fragmentos de caché, el uso de caché de página completa, etc. Estas estrategias te ayudarán a mejorar la velocidad de carga de tu aplicación y a reducir la carga en el servidor.
Optimización de activos estáticos: Los activos estáticos, como JavaScript, CSS e imágenes, pueden afectar el rendimiento de tu aplicación si no se optimizan correctamente. Algunas estrategias para optimizar los activos estáticos en Rails son la minificación, la concatenación, la compresión, etc.
Uso de bases de datos eficientes: La base de datos es uno de los componentes críticos en el rendimiento de una aplicación web. Algunas estrategias para optimizar el rendimiento de la base de datos en Rails son el uso de índices, la optimización de consultas, la fragmentación de tablas, etc. ### Seguridad en Profundidad La seguridad es un aspecto crítico en el desarrollo de aplicaciones web, ya que cualquier vulnerabilidad puede comprometer la integridad y la confidencialidad de los datos de los usuarios. Algunos temas que puedes explorar en este ámbito son:
Análisis detallado de vulnerabilidades comunes: Es importante conocer las vulnerabilidades comunes en aplicaciones web, como Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection, etc.
Herramientas avanzadas de seguridad: Existen muchas herramientas avanzadas de seguridad que puedes utilizar en Rails, como Brakeman, Bundler Audit, etc. Estas herramientas te ayudarán a identificar y corregir vulnerabilidades de seguridad en tu aplicación. Si tienes tu aplicación en GitHub, tienes a dependabot que te ayuda a mantener tus dependencias actualizadas y seguras. #### Análisis detallado de vulnerabilidades comunes Es importante conocer las vulnerabilidades comunes en aplicaciones web para poder prevenirlas y mitigarlas. Algunas vulnerabilidades comunes en aplicaciones web son:
Cross-Site Scripting (XSS): El XSS es una vulnerabilidad que permite a un atacante ejecutar código malicioso en el navegador de un usuario. Para prevenir el XSS en Rails, es importante escapar y sanitizar las entradas del usuario y utilizar métodos seguros para renderizar HTML.
Ejemplos de prevención de XSS en Rails:
- Siempre sanitizar las entradas del usuario antes de mostrarlas en la vista. Esto se puede hacer con el método sanitize o html_safe.
```
<%= sanitize @user.bio %>
```
- Utilizar el link_to solo para enlaces internos y no para enlaces externos.
```
<%= link_to 'Home', root_path %>
```
Cross-Site Request Forgery (CSRF): El CSRF es una vulnerabilidad que permite a un atacante realizar acciones no autorizadas en nombre de un usuario autenticado. Para prevenir el CSRF en Rails, es importante utilizar tokens de autenticidad y verificar la autenticidad de las solicitudes. Rails proporciona protección contra CSRF por defecto, pero también permite deshabilitarla si es necesario.

Para verificar la autenticidad de las solicitudes en Rails, en el ApplicationController o el controlador base de tu aplicación, debe estar la siguiente línea:

  protect_from_forgery with: :exception

Esto significa que Rails usa la estrategio :exception para protegerse de CSRF, que lanza un error si el request viene sin el token de autenticidad. Otra estrategia es :null_session que no lanza un error, pero limpia la sesión.
En muchas API hechas en Rails, se usaba el skip_before_action :verify_authenticity_token para deshabilitar la protección CSRF en los controllers que eran solo de la API.

SQL Injection: El SQL Injection es una vulnerabilidad que permite a un atacante ejecutar consultas SQL maliciosas en la base de datos. Para prevenir el SQL Injection en Rails, es importante utilizar consultas parametrizadas y escapar las entradas del usuario. Aquí es importante usar los métodos de ActiveRecord que permiten hacer consultas seguras. ### Testing Las pruebas automatizadas son una parte fundamental del desarrollo de software, ya que te permiten verificar el comportamiento de tu aplicación y prevenir errores. Algunos temas que puedes explorar en este ámbito son:
Pruebas unitarias: Las pruebas unitarias te permiten verificar el comportamiento de unidades individuales de código, como modelos, controladores, etc.
Pruebas de integración: Las pruebas de integración te permiten verificar el comportamiento de múltiples componentes de tu aplicación trabajando juntos.
Pruebas de aceptación: Las pruebas de aceptación te permiten verificar el comportamiento de tu aplicación desde la perspectiva del usuario. ## Conclusión En resumen, seguir buenas prácticas en Ruby on Rails es fundamental en muchos aspectos. Algunas áreas en las que puedes profundizar son la arquitectura avanzada, el rendimiento, la escalabilidad, la seguridad y las pruebas automatizadas. Recuerda que la comunidad de Rails es muy activa y hay muchos recursos disponibles para seguir aprendiendo y mejorando en el desarrollo con Rails. ¡Sigue aprendiendo y mejorando en tu viaje con Ruby on Rails! ¡Gracias por leerme! ❤️

Optimizing Active Record queries

Kattya Cuevas — Wed, 06 Apr 2022 23:30:10 +0000

Context: Some time ago, I worked on a project where I had to make a lot of reports. We had a lot of data, and most of the reports should be in the application's dashboard. The data was divided into more than one table, so I had to make queries joining many tables every time I wanted to generate a new report. That made our application slow and even sometimes broke.

In this article, I'll show you how I used Active Record to fix the app's problems and if there's a limit on how to customize Active Record queries.

The sample app I'll use will be a clone (in a base form) of Spotify or any music app. Let me explain how will be the tables relationship in our database.

All the songs belong to an artist and an album. We also have the users table who can vote or rate a song or album. The ratings table has a polymorphic relation to songs and albums.

NOTE: A polymorphic relation is how Rails associate with more than one table simultaneously without the need to create a foreign key with the name of the association.

Before Start

¿How will we know if these solutions are fast?

There are a lot of ways to analyze your code. In this article, I'll make with these 3 ways:

Elapsed time
Memory: space in the disk that the code occupies in execution
Iterations per second

To have these 3 ways to measure our code, we will use the Benchmark module inside Ruby and the gems benchmark-ips and benchmark-memory.

First Problem: Get the highest rating albums

Possible Solutions

First solution:
Using a combination of Active Record and Ruby methods:

Album.includes(:ratings).map { |album| album.ratings.length }.max

Second solution:
Using only Active Record methods

Album.from(Album.select(
  "albums.*", "COUNT(ratings.id) AS rating_count"
).joins(:ratings).group("albums.id")).maximum("rating_count")

Both return the same result: 20. What is the difference?

Let's analyze the first solution

The first part of this solution uses an Active Record method:

Album.includes(:ratings)

This expression executes the following SQL code:

SELECT "albums".* FROM "albums"

SELECT "ratings".* FROM "ratings" WHERE "ratings"."ratingable_type" = "Album" 
AND "ratings"."ratingable_id" IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ...)

The more albums we have in our database, the longer the ranking list we have.

The second part is

.map { |album| album.ratings.length }.max

The map method iterates over the result of the includes method we did before. Inside every album, we call all the ratings associated with that album, and we calculate (with Ruby) how many ratings have every album. Once we have the list with all the totals, with the max method of the Enumerators in Ruby, we can calculate the element with the max value inside the array.

Let's analyze the second solution

Let's break the solution in two parts, the first is inside the from method.

Album.select(
  "albums.*", "COUNT(ratings.id) AS rating_count"
).joins(:ratings).group("albums.id")

This will execute the following SQL code:

SELECT albums.*, COUNT(ratings.id) AS rating_count
FROM "albums" INNER JOIN "ratings"
ON "ratings"."votable_type" = "Album" AND "ratings"."votable_id" = "albums"."id"
GROUP BY "albums"."id"

Here we add the COUNT(rating.id) column with the alias rating_count to our query to count how many associated ratings have every album.

The second part is:

Album.from(...).maximum("rating_count")

This will execute the following SQL code:

SELECT MAX(rating_count) FROM (...) subquery

The first part of the query we explained becomes the subquery on which we will run another query. The query will get the maximum value of the rating_count column.

Let's compare the solutions

Elapsed Time
This is the code we will execute:

Benchmark.bmbm do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
end

Note: I'm using the bmbm method to execute the reports twice, so none of the methods will be affected, only for being the first.

This is the result:

Rehearsal -------------------------------------------------------------
Active Record + Ruby code   5.554467   0.788396   6.342863 (  7.404660)
Only Active Record          0.003204   0.001894   0.005098 (  0.741973)
---------------------------------------------------- total: 6.347961sec

                                user     system      total        real
Active Record + Ruby code   5.042479   0.540590   5.583069 (  5.776371)
Only Active Record          0.001858   0.000419   0.002277 (  0.532489)

If we analyze the result, there is a slight time difference between the two solutions, with the second one being faster.

Memory
This is the code we will execute:

Benchmark.memory do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
  x.compare!
end

This is the result:

Calculating -------------------------------------
Active Record + Ruby code
                       585.804M memsize (     0.000  retained)
                         6.099M objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
  Only Active Record    53.270k memsize (     0.000  retained)
                       511.000  objects (     0.000  retained)
                        50.000  strings (     0.000  retained)

Comparison:
  Only Active Record:      53270 allocated
Active Record + Ruby code:  585803866 allocated - 10996.88x more

If we look at this result, we can say that the first solution uses 1.54 times more memory than the second solution.

Iterations per second
This is the code we will execute:

Benchmark.ips do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
  x.compare!
end

This is the result:

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
  Only Active Record     1.000  i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          0.159  (± 0.0%) i/s -      1.000  in   6.277377s
  Only Active Record     12.768  (± 7.8%) i/s -     64.000  in   5.032453s

Comparison:
  Only Active Record:       12.8 i/s
Active Record + Ruby code:        0.2 i/s - 80.15x  (± 0.00) slower

As we see in the results, the first solution is 1.44 times faster than the second one.

Results of comparison

The second solution is faster than the first solution at elapsed time.
In terms of memory, the first solution uses 10996x times more memory than the second solution.
And on the number of iterations per second, the first solution is 80.15 times slower than the second solution.

So why is the second solution the best? Because we are doing only one call on the database, and the whole operation is done from the DB side.

Second problem: Top 10 songs with their artists that have the highest rating

Possible solutions

This time I have 3 solutions:

First solution

Using Active Record and Ruby

ratings = Rating
            .where(votable_type: "Song")
            .group(:votable_id).average(:vote)
            .sort_by { |r| -r[1] }.take(n).to_h

songs = Song.includes(:artists).find(ratings.keys)

ratings.map do |song_id, rating|
   song = songs.find { |song| song.id == song_id }
   {
       song: song.title,
       artist: song.artists.map(&:name).join(", "),
       rating_avg: rating.to_f
   }
end

Second solution

Using only one query with a lot of Active Record methods

Song
  .includes(:artists).joins(:ratings)
  .select("songs.*, AVG(ratings.vote) as rating_avg")
  .group("songs.id").order("rating_avg DESC").limit(n)
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: song.rating_avg
    }
  end

Third solution

Using 2 queries with Active Record methods and Ruby code

ratings = Rating
            .select("ratings.votable_id, AVG(ratings.vote) as rating_avg")
            .where(votable_type: "Song")
            .group(:votable_id).order("rating_avg DESC")
            .limit(n)

Song
  .includes(:artists)
  .find(ratings.map(&:votable_id))
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: ratings.find { |rating| rating.votable_id == song.id }.rating_avg
    }
  end

Let's analyze the first solution

To calculate the songs with the highest rating, I first search in the ratings table for the ratings related to the songs table.
Remember that the ratings table has a polymorphic relationship with songs, so we must look for those ratings whose votable_type is Song, so we will know which ratings are songs. Then we will group them by votable_id (song.id) to obtain the average of all the ratings.

Rating
  .where(votable_type: "Song")
  .group(:votable_id)
  .average(:vote)

This expression will return an array of arrays with the following structure: [[votable_id, vote_avg], [votable_id, vote_avg]]. It has all the songs' ids and the average of their ratings.

It will sort them by the second element of the array in descending order, then take the first 'n' elements and convert it into a hash.

.sort_by { |r| -r[1] }.take(n).to_h

The second part will get the songs of the hash we just generated, including the associated artists.

songs = Song.includes(:artists).find(ratings.keys)

Lastly, we iterate over the hash of the ratings to generate the required data. In every iteration, we search for the song which belongs to the rating, and we build the hash to return as a result.

ratings.map do |song_id, rating|
   song = songs.find { |song| song.id == song_id }
   {
       song: song.title,
       artist: song.artists.map(&:name).join(", "),
       rating_avg: rating.to_f
   }
end

Let's analyze the second solution

I tried to get the same result in this solution by doing only one query to the database.
First, I'll make a query over the joins of the tables songs and ratings, so I can have the data from both tables. I'll use the includes(:artists) method to call all the associated artists to the found songs.

Song.includes(:artists).joins(:ratings)

Over the joins, we will ask for the average (in SQL) grouped by song.id, then sort them by rating_avg and at the end call only the first n records.

.select("songs.*, AVG(ratings.vote) as rating_avg")
.group("songs.id")
.order("rating_avg DESC")
.limit(n)

Finally, we will iterate over the result to build the hash we should return as a result

.map do |song|
  {
    song: song.title,
    artist: song.artists.map(&:name).join(", "),
    rating_avg: song.rating_avg
  }
end

Let's analyze the third solution

We make something similar to the first solution, but we don't use the average method from ActiveRecord. Otherwise, we will do it by SQL using the select method. We call the group method to make the calculation for every song, then we filter the search to only songs with the where method, and lastly, we sort them and limit the result to the n first records

ratings = Rating
            .select("ratings.votable_id, AVG(ratings.vote) as rating_avg")
            .where(votable_type: "Song")
            .group(:votable_id)
            .order("rating_avg DESC")
            .limit(n)

Then, we search the songs with those ratings we found, and we format them to result in the expected result:

Song
  .includes(:artists)
  .find(ratings.map(&:votable_id))
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: ratings.find { |rating| rating.votable_id == song.id }.rating_avg
    }
  end

Let's compare the solutions

Elapsed Time

Rehearsal ----------------------------------------------------------------
Active Record + Ruby code      0.787713   0.196014   0.983727 (  1.645864)
Only Active Record             0.016700   0.002986   0.019686 (  0.567646)
Active Record + Ruby code v2   0.024173   0.000953   0.025126 (  0.403639)
------------------------------------------------------- total: 1.028539sec

                                   user     system      total        real
Active Record + Ruby code      0.595617   0.026087   0.621704 (  1.016591)
Only Active Record             0.008948   0.000577   0.009525 (  0.580103)
Active Record + Ruby code v2   0.002977   0.000137   0.003114 (  0.378619)

Memory

Calculating -------------------------------------
Active Record + Ruby code
                       175.136M memsize (     0.000  retained)
                         2.422M objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
  Only Active Record   303.235k memsize (     0.000  retained)
                         3.425k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
Active Record + Ruby code v2
                       347.840k memsize (     0.000  retained)
                         3.615k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)

Comparison:
  Only Active Record:     303235 allocated
Active Record + Ruby code v2:     347840 allocated - 1.15x more
Active Record + Ruby code:  175135967 allocated - 577.56x more

Iterations per second

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
  Only Active Record     1.000  i/100ms
Active Record + Ruby code v2
                         1.000  i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          0.947  (± 0.0%) i/s -      5.000  in   5.294872s
  Only Active Record      1.867  (± 0.0%) i/s -     10.000  in   5.357158s
Active Record + Ruby code v2
                          2.646  (± 0.0%) i/s -     14.000  in   5.292725s

Comparison:
Active Record + Ruby code v2:        2.6 i/s
  Only Active Record:        1.9 i/s - 1.42x  (± 0.00) slower
Active Record + Ruby code:        0.9 i/s - 2.79x  (± 0.00) slower

Results of comparison

The elapsed time of the third solution is faster than the two first solutions.The first solution is slower than the other two.
The third solution uses 1.15 times more memory than the second solution, and the first solution uses 557 times more memory than the second solution.
And on the number of iterations per second, the second solution is 1.42 times slower than the third solution and the first solution 2.79 times slower than the third solution.

In conclusion, the third solution is the best, and the first solution is the least optimal. Why is the solution using pure Active Record the least optimal this time? Because the query we are doing makes joins of two tables, this has an optimization cost, as we can observe.

Third Problem: Top "N" songs with the highest rating and pass as parameters if you want their artists and albums

Possible Solutions:

Build the result by calling different methods based on the parameters.
Using SQL y Materialized views.

SQL Views

They are virtual tables created from a SELECT query that usually joins multiple tables.
Each time they are called, the query they have been defined will be executed.

Materialized views

They are also virtual tables created from a SELECT query that normally joins multiple tables.
They store the query results in this virtual table. They are read-only.
They can be updated whenever you need them.

Let's compare the solutions

I'm using the best solution from the previous problem to compare with the SQL and Materialized views.

Elapsed Time

Rehearsal -------------------------------------------------------------
Active Record + Ruby code   0.096419   0.036263   0.132682 (  0.598458)
SQL View                    0.000640   0.000259   0.000899 (  0.001701)
Materialized View           0.000671   0.000172   0.000843 (  0.001408)
---------------------------------------------------- total: 0.134424sec

                                user     system      total        real
Active Record + Ruby code   0.008866   0.001029   0.009895 (  0.382414)
SQL View                    0.000122   0.000003   0.000125 (  0.000121)
Materialized View           0.000100   0.000000   0.000100 (  0.000098)

Memory

Calculating -------------------------------------
Active Record + Ruby code
                       347.036k memsize (     0.000  retained)
                         3.611k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
            SQL View     1.992k memsize (     0.000  retained)
                        29.000  objects (     0.000  retained)
                         1.000  strings (     0.000  retained)
   Materialized View     1.992k memsize (     0.000  retained)
                        29.000  objects (     0.000  retained)
                         1.000  strings (     0.000  retained)

Comparison:
            SQL View:       1992 allocated
   Materialized View:       1992 allocated - same
Active Record + Ruby code:     347036 allocated - 174.21x more

Iterations per second

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
            SQL View    10.036k i/100ms
   Materialized View    10.049k i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          2.652  (± 0.0%) i/s -     14.000  in   5.284182s
            SQL View     99.936k (± 1.1%) i/s -    501.800k in   5.021873s
   Materialized View    100.465k (± 0.7%) i/s -    502.450k in   5.001495s

Comparison:
   Materialized View:   100465.2 i/s
            SQL View:    99935.8 i/s - same-ish: difference falls within error
Active Record + Ruby code:        2.7 i/s - 37887.16x  (± 0.00) slower

Results of comparison

The elapsed time of the second and third solution are faster than the first one.
The first solution uses 174.21 times more memory than the second and third solutions.
And on the number of iterations per second, the first solution is 37887.16 times slowerd than the two first solutions.
In conclusion, the difference between the optimized solution from the previous problem and SQL and Materialized views is considerable.

Conclusions

The first problem showed us how to use Active Record to make it more powerful using SQL queries
The second problem shows us that it is OK to use Ruby to support Active Record.
The third one shows us that Active Record can also have a limit, and we can use SQL when needed.

Remember

If you will handle a considerable amount of data, try to get only the needed data. You can use the select and pluck methods from Active Record.
Sometimes, the Ruby methods are better than the Active Record ones.
Don't be afraid to use SQL with Active Record.
Use size or length instead of count if you don't want to make an extra query.
Avoid n + 1 queries with includes method.

I hope you enjoyed and learned something from this article. Thanks for reading! ❤️

Optimización de queries en Rails

Kattya Cuevas — Wed, 06 Apr 2022 23:28:37 +0000

Contexto: Hace un tiempo, trabajé en un proyecto en el que tenía que dar reportes de la data que teníamos, la mayoría de los reportes que teníamos que calcular estarían en el dashboard. Teníamos una cantidad regular de data que consultar y esta data estaba dividida en muchas tablas. Las consultas que hacíamos a la base de datos, tenían que estar optimizadas para que nuestra API no demore tanto en responder o a veces para que no muera.

En este artículo, te contaré cómo fui solucionando cada uno de los problemas que tuve, iré desde los problemas más simples que uno puede ver en todos los proyectos en Rails hasta los más complejos.

La aplicación de ejemplo que usaré será un clon en su forma básica de Spotify o cualquier aplicación de música. Les explico cómo será las relaciones de nuestras tablas en nuestra base de datos.

Tengo canciones que le pertenece a un artista y esta canción le pertenece a un album, también tenemos una tabla de usuarios, que son los que pueden votar o poner un rating a una canción o a un album. La tabla ratings tiene una relación polimórfica hacia canciones y hacia albums.

NOTA: Una relación polimórfica es una forma en Rails de relacionar una tabla con más de una tabla a la vez sin necesidad de crear un foreign key con el nombre de la relación.

Antes de empezar

¿Cómo analizaremos si estas soluciones son más rápidas?

Hay muchas formas de analizar tu código, aquí lo haré de 3 formas:

Tiempo de ejecución (Elapsed time)
Memoria (memory): espacio en tu disco que ocupa este código al ejecutar
Iteraciones por segundo

Para tener estas 3 formas de medir nuestro código, usaremos el módulo Benchmark que nos da ruby, y las gemas benchmark-ips y benchmark-memory

Primer Problema: Obtener el rating más alto en los albums

Posibles Soluciones

Primera solución:
Usando una combinación de métodos de ActiveRecord con métodos de Ruby:

Album.includes(:ratings).map { |album| album.ratings.length }.max

Segunda solución:
Usando solo métodos de Active Record

Album.from(Album.select(
  "albums.*", "COUNT(ratings.id) AS rating_count"
).joins(:ratings).group("albums.id")).maximum("rating_count").explain

Ambos devuelven el mismo resultado 20. ¿Cuál es la diferencia?

Analicemos la primera solución

La primera parte de esta solución usa un método de ActiveRecord:

Album.includes(:ratings)

Esto ejecuta el siguiente código SQL

SELECT "albums".* FROM "albums"

SELECT "ratings".* FROM "ratings" WHERE "ratings"."ratingable_type" = "Album" 
AND "ratings"."ratingable_id" IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ...)

(mientras más albums tengamos en nuestra base de datos, más grande será la lista de ratings que traeremos)

La segunda parte es

.map { |album| album.ratings.length }.max

Este map itera sobre la respuesta que nos devuelve el includes que hicimos. En cada album, llama a todos los rating y calculamos (con Ruby) cuántos ratings tiene cada album. Una vez que tenemos la lista con todos los totales, con el método max de los Enumerators en Ruby podemos calcular el elemento con el máximo valor.

Analicemos la segunda solución

Partiremos esta solución en dos partes, la primera que es la que está dentro del método from.

Album.select(
  "albums.*", "COUNT(ratings.id) AS rating_count"
).joins(:ratings).group("albums.id")

Esto se ejecturá en el siguiente código SQL:

SELECT albums.*, COUNT(ratings.id) AS rating_count
FROM "albums" INNER JOIN "ratings"
ON "ratings"."votable_type" = "Album" AND "ratings"."votable_id" = "albums"."id"
GROUP BY "albums"."id"

Aquí estamos agregando la columna COUNT(ratings.id) con el alias rating_count a nuestra consulta para que por cada album cuente cuántos ratings asociados tiene.

La segunda parte es:

Album.from(...).maximum("rating_count")

Esto se ejecutarán en el siguiente código SQL:

SELECT MAX(rating_count) FROM (...) subquery

Toda la consulta que explicamos en la primera parte pasa a ser la subquery sobre la que vamos a hacer otra consulta, en este caso sacar el máximo valor de una de la columna rating_count.

Comparemos las soluciones

Tiempo de ejecución

Este es el código que ejecutaremos:

Benchmark.bmbm do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
end

Nota: Estoy usando el método bmbm para que se ejecute dos veces los reportes, así ninguno de los métodos se verá afectado por ser el primero en ejecutarse.

Este es el resultado:

Rehearsal -------------------------------------------------------------
Active Record + Ruby code   5.554467   0.788396   6.342863 (  7.404660)
Only Active Record          0.003204   0.001894   0.005098 (  0.741973)
---------------------------------------------------- total: 6.347961sec

                                user     system      total        real
Active Record + Ruby code   5.042479   0.540590   5.583069 (  5.776371)
Only Active Record          0.001858   0.000419   0.002277 (  0.532489)

Si analizamos el resultado hay una ligera diferencia de tiempo entre ambas soluciones, siendo la segunda solución la más rápida.

Memoria

Este es el código que ejecutaremos:

Benchmark.memory do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
  x.compare!
end

Este es el resultado:

Calculating -------------------------------------
Active Record + Ruby code
                       585.804M memsize (     0.000  retained)
                         6.099M objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
  Only Active Record    53.270k memsize (     0.000  retained)
                       511.000  objects (     0.000  retained)
                        50.000  strings (     0.000  retained)

Comparison:
  Only Active Record:      53270 allocated
Active Record + Ruby code:  585803866 allocated - 10996.88x more

Si vemos este resultado, podemos decir que la primera solución está utilizando 1.54 veces más de memoria en comparación con la segunda solución.

Iteraciones por segundo

Este es el código que ejecutaremos:

Benchmark.ips do |x|
  x.report("Active Record + Ruby code") { first_solution }
  x.report("Only Active Record") { second_solution }
  x.compare!
end

Este es el resultado:

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
  Only Active Record     1.000  i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          0.159  (± 0.0%) i/s -      1.000  in   6.277377s
  Only Active Record     12.768  (± 7.8%) i/s -     64.000  in   5.032453s

Comparison:
  Only Active Record:       12.8 i/s
Active Record + Ruby code:        0.2 i/s - 80.15x  (± 0.00) slower

Como vemos en los resultados, la primera solución es 1.44 veces más rápida que la segunda solución.

Resultados de la comparación

En tiempo de ejecución la segunda solución es más rápida que la primera solución
En cuento a la memoria la primera solución está utilizando 10996x más de memoria en comparación con la segunda solución.
Y sobre la cantidad de iteraciones por segundo, la primera solución es 80.15 veces más lenta que la segunda solución.

Entonces ¿por qué la segunda solución es la mejor?

Porque se hace una sola llamada en la base de datos y toda la operación se hace desde el lado de la BD. Esto hace que la busqueda se haga más rápida al estar en contacto directo con la data.

Segundo problema: Top 10 canciones con su respectivos artistas que tienen el mayor rating

Posibles soluciones

Esta vez tengo tres soluciones:
Primera solución
Usando métodos de Active Record y código de Ruby

ratings = Rating
            .where(votable_type: "Song")
            .group(:votable_id)
            .average(:vote)
            .sort_by { |r| -r[1] }
            .take(n).to_h

songs = Song
          .includes(:artists)
          .find(ratings.keys)

ratings.map do |song_id, rating|
   song = songs.find { |song| song.id == song_id }
   {
       song: song.title,
       artist: song.artists.map(&:name).join(", "),
       rating_avg: rating.to_f
   }
end

Segunda solución
Usando una sola query con muchos métodos de Active Record

Song
  .includes(:artists)
  .joins(:ratings)
  .select("songs.*, AVG(ratings.vote) as rating_avg")
  .group("songs.id")
  .order("rating_avg DESC")
  .limit(n)
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: song.rating_avg
    }
  end

Tercera solución
Usando dos queries con métodos de Active Record y poco código de Ruby

ratings = Rating
            .select("ratings.votable_id, AVG(ratings.vote) as rating_avg")
            .where(votable_type: "Song")
            .group(:votable_id)
            .order("rating_avg DESC")
            .limit(n)

Song
  .includes(:artists)
  .find(ratings.map(&:votable_id))
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: ratings.find { |rating| rating.votable_id == song.id }.rating_avg
    }
  end

Analicemos la primera solución

Para calcular las canciones con mayor rating, primero busco en la tabla ratings, los ratings que están relacionados con la tabla songs.

Recuerden que la tabla ratings tenía una relación polimórfica con songs, por eso es que debemos buscar aquellos ratings cuyo votable_type es Song, así sabremos cuáles ratings son solo de songs. Luego vamos a agruparlos por votable_id (song.id) para poder sacar el average (promedio) de todos los ratings.

Rating
  .where(votable_type: "Song")
  .group(:votable_id)
  .average(:vote)

Esto nos devolverá un array de arrays de la siguiente forma: [[votable_id, vote_avg], [votable_id, vote_avg]], con todos los ids de las canciones y el promedio de los ratings de estas.

Lo que hará ahora es ordenarlos por el segundo elemento del array de forma descendente, tomar los n primeros elementos y convertirlo en un hash.

.sort_by { |r| -r[1] }.take(n).to_h

En la segunda parte, obtenemos las canciones del hash que acabamos de generar, incluyendo los artistas asociados.

songs = Song.includes(:artists).find(ratings.keys)

Por último iteramos sobre el hash de ratings para generar la data requerida. En cada iteración buscamos el song al que le pertenece el rating y con eso armamos el hash a retornar como resultado.

ratings.map do |song_id, rating|
  song = songs.find { |song| song.id == song_id }
  {
    song: song.title,
    artist: song.artists.map(&:name).join(", "),
    rating_avg: rating.to_f
  }
end

Analicemos la segunda solución

En esta solución intenté obtener el mismo resultado haciendo solo una consulta a la base de datos.

Primero haré una query sobre el joins de las tablas songs y ratings, para poder tener la data de ambas tablas. Usaré el método includes(:artists) para poder llamar a los artistas asociados a las canciones encontradas

Song.includes(:artists).joins(:ratings)

Sobre este joins vamos a pedir el average (por SQL gracias al método select) agrupados por song.id, luego ordenarlos por rating_avg y por último llamando solo a los n primeros records.

.select("songs.*, AVG(ratings.vote) as rating_avg")
.group("songs.id")
.order("rating_avg DESC")
.limit(n)

Finalmente iteramos sobre este resultado, para armar el hash que debemos retornar como resultado

.map do |song|
  {
    song: song.title,
    artist: song.artists.map(&:name).join(", "),
    rating_avg: song.rating_avg
  }
end

Analicemos la tercera solución

Hacemos algo similar a la primera solución, pero no usamos el método average de ActiveRecord, sino lo haremos por SQL usando el método select. Hacemos el group para que se el cálculo se haga por canción, filtramos la busqueda a solo las canciones con el método where, y por último lo ordenamos y limitamos el resultado a los n primeros

ratings = Rating
            .select("ratings.votable_id, AVG(ratings.vote) as rating_avg")
            .where(votable_type: "Song")
            .group(:votable_id)
            .order("rating_avg DESC")
            .limit(n)

Luego buscamos los songs que de esos ratings que encontramos y le damos el formato que necesitamos para retornar el resultado esperado:

Song
  .includes(:artists)
  .find(ratings.map(&:votable_id))
  .map do |song|
    {
      song: song.title,
      artist: song.artists.map(&:name).join(", "),
      rating_avg: ratings.find do |rating|
                    rating.votable_id == song.id
                  end.rating_avg
    }
  end

Comparemos las soluciones

Tiempo de ejecución

Rehearsal ----------------------------------------------------------------
Active Record + Ruby code      0.787713   0.196014   0.983727 (  1.645864)
Only Active Record             0.016700   0.002986   0.019686 (  0.567646)
Active Record + Ruby code v2   0.024173   0.000953   0.025126 (  0.403639)
------------------------------------------------------- total: 1.028539sec

                                   user     system      total        real
Active Record + Ruby code      0.595617   0.026087   0.621704 (  1.016591)
Only Active Record             0.008948   0.000577   0.009525 (  0.580103)
Active Record + Ruby code v2   0.002977   0.000137   0.003114 (  0.378619)

Memoria

Calculating -------------------------------------
Active Record + Ruby code
                       175.136M memsize (     0.000  retained)
                         2.422M objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
  Only Active Record   303.235k memsize (     0.000  retained)
                         3.425k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
Active Record + Ruby code v2
                       347.840k memsize (     0.000  retained)
                         3.615k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)

Comparison:
  Only Active Record:     303235 allocated
Active Record + Ruby code v2:     347840 allocated - 1.15x more
Active Record + Ruby code:  175135967 allocated - 577.56x more

Iteraciones por segundo

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
  Only Active Record     1.000  i/100ms
Active Record + Ruby code v2
                         1.000  i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          0.947  (± 0.0%) i/s -      5.000  in   5.294872s
  Only Active Record      1.867  (± 0.0%) i/s -     10.000  in   5.357158s
Active Record + Ruby code v2
                          2.646  (± 0.0%) i/s -     14.000  in   5.292725s

Comparison:
Active Record + Ruby code v2:        2.6 i/s
  Only Active Record:        1.9 i/s - 1.42x  (± 0.00) slower
Active Record + Ruby code:        0.9 i/s - 2.79x  (± 0.00) slower

Resultados de la comparación

The elapsed time of the third solution is faster than the two first solutions.The first solution is slower than the other two.
The third solution uses 1.15 times more memory than the second solution, and the first solution uses 557 times more memory than the second solution.
And on the number of iterations per second, the second solution is 1.42 times slower than the third solution and the first solution 2.79 times slower than the third solution.

En tiempo de ejecución, la tercera solución es más rápida que las dos primeras. La primera solución es mucho más lenta que las otras dos.
En cuanto a la memoria, la tercera solución está utilizando 1.15 veces más de memoria en comparación con la segunda solución y la primera solución usa 557 veces más memoria en comparación con la segunda solución
Y sobre la cantidad de iteraciones por segundo, la segunda solución es 1.42 veces más lenta que la tercera solución y la primera solución es 2.79 veces más más rápida que la tercera solución.

Sacando conclusiones, la tercera solución es la mejor y la primera solución es la menos óptima. ¿Por qué esta vez la solución que usa puro Active Record es la menos óptima? Porque la consulta que estamos haciendo hace un joins de dos tablas y esto tiene un costo de optimización como podemos observar.

Tercer Problema: Reporte de reportes

Generar un reporte que tenga las top “N” canciones con el mayor rating y como párametros se pase aparte del número de canciones si queremos saber los artistas y albums de dichas canciones

Opciones de solución:

Armar un hash con que contenga todo lo requerido llamando a diferentes métodos de acuerdo a los parámetros.
Usar SQL y materialized views

SQL Views

Son tablas virtuales creadas a partir de una consulta SELECT que normalmente une múltiples tablas.
Cada vez que se llaman se ejecutará la consulta con la que ha sido definida.

Materialized views

También son tablas virtuales creadas a partir de una consulta SELECT que normalmente une múltiples tablas como los SQL views.
Pero esta almacena el resultado de la consulta haciendolos funcionar como una tabla de solo lectura.
Como ventaja tiene que se pueden actualizar cuando lo necesitemos. Esto lo podemos hacer con la gema scenic.
Pueden ser actualizados cuando lo necesitemos.

Comparemos las soluciones

Estoy usando la mejor solución del segundo problema para compararlo con SQL y Materialized views.

Tiempo de ejecución

Rehearsal -------------------------------------------------------------
Active Record + Ruby code   0.096419   0.036263   0.132682 (  0.598458)
SQL View                    0.000640   0.000259   0.000899 (  0.001701)
Materialized View           0.000671   0.000172   0.000843 (  0.001408)
---------------------------------------------------- total: 0.134424sec

                                user     system      total        real
Active Record + Ruby code   0.008866   0.001029   0.009895 (  0.382414)
SQL View                    0.000122   0.000003   0.000125 (  0.000121)
Materialized View           0.000100   0.000000   0.000100 (  0.000098)

Memoria

Calculating -------------------------------------
Active Record + Ruby code
                       347.036k memsize (     0.000  retained)
                         3.611k objects (     0.000  retained)
                        50.000  strings (     0.000  retained)
            SQL View     1.992k memsize (     0.000  retained)
                        29.000  objects (     0.000  retained)
                         1.000  strings (     0.000  retained)
   Materialized View     1.992k memsize (     0.000  retained)
                        29.000  objects (     0.000  retained)
                         1.000  strings (     0.000  retained)

Comparison:
            SQL View:       1992 allocated
   Materialized View:       1992 allocated - same
Active Record + Ruby code:     347036 allocated - 174.21x more

Iteraciones por segundo

Warming up --------------------------------------
Active Record + Ruby code
                         1.000  i/100ms
            SQL View    10.036k i/100ms
   Materialized View    10.049k i/100ms
Calculating -------------------------------------
Active Record + Ruby code
                          2.652  (± 0.0%) i/s -     14.000  in   5.284182s
            SQL View     99.936k (± 1.1%) i/s -    501.800k in   5.021873s
   Materialized View    100.465k (± 0.7%) i/s -    502.450k in   5.001495s

Comparison:
   Materialized View:   100465.2 i/s
            SQL View:    99935.8 i/s - same-ish: difference falls within error
Active Record + Ruby code:        2.7 i/s - 37887.16x  (± 0.00) slower

Resultados de la comparación

El tiempo de ejecución de la segunda y tercera solución es mucho más rápido que la primera solución.
La primera solución usa 174.21 veces más memoria que las dos primeras soluciones.
Y sobre el número de iteraciones por segundo, la primera solución is 37887.16 veces más lenta que las dos primeras soluciones.

En conclusión, la diferencia entre la solución optimizada del problema anterior y las nuevas soluciones usando SQL y Materialized views es muy notoria.

Conclusiones

El primer problema nos muestra cómo hacer Active Record más poderoso usando SQL queries.
El segundo problema nos muestra que está bien usar Ruby como apoyo de Active Record.
El tercer problema nos muestra que Active Record también tiene un límite, y que podemos usar SQL cuando lo necesitemos.

EXTRA

Si tienes que lidiar con una cantidad considerable de data, intenta obtener solo data que necesites. Puedes usar los métodos select y pluck de Active Record.
A veces los métodos de Ruby son mejores que los de Active Record, sobretodo para hacer cálculos.
No tengas miedo de usar SQL con Active Record.
Usa size o length en lugar de count si no quieres hacer un query adicional.
Evita los queries n + 1 con el método includes.

Espero que hayas disfrutado y aprendido algo nuevo de este artículo. ¡Gracias por leerme! ❤️

Cómo me afecto la “experiencia universitaria”

Kattya Cuevas — Sat, 19 Mar 2022 17:10:22 +0000

En un taller #IamRemarkable que di, conté sobre una experiencia mía en la universidad, bueno, un super resumen, así que reflexioné un poco del tema. Esta experiencia solo se la he contado a personas cercanas a mí, y aún así nunca les dije cómo me sentía y que aún a veces me da miedo sobresalir a causa de esto.

Cuando estaba en la universidad, sacaba buenas notas, enseñaba a mis compañeros y era responsable, por lo que los profesores me tenían más confianza. Y no tenía miedo de hablarle a los profesores, y decirle cuándo algo me parecía injusto o preguntar cuando tenía dudas.

No recuerdo la primera vez que mis compañeros empezaron a hablar mal de mí o estar en mi contra, pero les voy a contar de las dos veces que me hicieron sentir mal, y sola.

La primera fue cuando un profesor me encargó recolectar todos los trabajos, a pesar que no era la delegada del salón. El profesor sentía más en confianza con que yo lo hiciera y yo creía que no tenía la culpa de ello. Una de las veces que salí del salón a hacer otras cosas entre clases, uno de mis compañeros reunió al resto para ponerse de acuerdo para no enviarme los trabajos y hacerme quedar mal frente al profesor. Así lo dijeron. Cerca de la mitad del salón (quizá por miedo) no aceptó la propuesta de este compañero, así que me enviaron los trabajos. Un amigo me contó sobre lo que querían hacer, como un chiste. Así que en su momento, no dije ni hice nada. Pero me quedé pensando que quizá sí fue mi culpa por aceptar estar a cargo.

La segunda fue algo peor que solo hablar delante de mis compañeros. Enviaron un mail a todos los de mi salón y otros alumnos de la facultad, hablando mal de mí y de una amiga, diciendo que nos regalaban la nota porque éramos amigas de los profesores. El correo era algo largo, pero ese era el resumen, no merecíamos el puesto que ocupábamos. Mis compañeros no me quisieron decir del mail porque faltaba poco para mi cumpleaños. Sin embargo el mail llegó a oídos de los profesores y directivos de mi facultad, que hablaron con mi salón un día que salí temprano de clases. Un amigo me hizo llegar el correo, porque se le escapó detalles de la reunión y se lo pedí. Al leer el mail, no sabía qué hacer, sólo empecé a llorar, no pude evitarlo. Mi mamá lo notó y me preguntó qué me pasaba, le señalé la computadora para que lo leyera, no tenía fuerza para hablar. Mi mamá, que siempre me dijo que termine la universidad cuando le decía que quería dejarla para estudiar por mi cuenta, en ese momento me preguntó si quería dejar la universidad o hacer un cambio de universidad o de carrera. No sabía qué hacer o qué decir, mi amigo estaba un poco preocupado así que le tuve que decir que estaba bien, pero me daba cólera lo que decían de mí. Pero en aquel entonces, solo pensaba qué hice mal, quizá no debí sacar buenas notas o hablar con los profesores o llamar la atención.

Olvidé comentar que muchas veces yo hablé con los profesores para que les dieran otra oportunidad, porque varios de mis compañeros estaban muy cerca de pasar y yo había visto su esfuerzo. Y uno (o más) de ellos creía todo esto de mí. Quizá por eso me dolió tanto, porque hice cosas para ayudarlos, y aún así algo había hecho mal.

Los días siguientes por suerte teníamos exámenes y podía decir que estaba ocupada haciendo los proyectos o estudiando, y así no tenía que verlos. Pero también se acercaba mi cumpleaños y mis amigos me preguntaban qué haría. Yo no quería nada, ni siquiera quería tener que pensar en eso. Días después, más amigos de otros años se enteraron también de lo que había pasado, y publicaron en los grupos de la facultad en redes sociales, defendiéndome, diciendo que yo me había ganado con esfuerzo el puesto en el que estaba y que ellos sabían lo que valía. Pero el problema es que yo empecé a dejar de pensar así. Por eso es que aún a veces tengo esta duda ¿será que merezco el lugar en el que estoy?

Siempre pensé que tuve mala suerte en tener esos compañeros y me tocó este tipo de situaciones, pero ahora que lo pensé mejor, muchos de mis amigos de otros años también se llevaban bien con los profesores, incluso mejor que yo, pero nunca les pasó lo que me pasó a mí. (Machismo tal vez?)

Tuve mucha suerte de tener un grupo de apoyo en ese momento, para ayudarme a olvidar lo que había pasado o al menos a que no duela tanto.

Ahora, gracias a los talleres que he recibido y estoy facilitando, entendí que sí merezco lo que tengo hoy, y en ese momento también lo merecía, porque era fruto de mi esfuerzo y dedicación. Me hubiera gustado tanto haber llevado estos talleres antes y, así, no hubiera sufrido tanto en ese momento.

Authentication with Auth0 on Rails

Kattya Cuevas — Tue, 08 Mar 2022 17:26:18 +0000

Spanish version here

One of the essential features that most applications have in common is Authentication.
There are many options to authenticate us nowadays. In this article, I’ll talk about a solution used a lot lately: Auth0 and implementing it in a Rails project.

Auth0 as an Authentication Solution

Authentication?

First, let's define authentication as to how a user or a resource, in general, can be identified in your application, which means it is a way to recognize that a particular resource (user) is interacting with our application.

How to authenticate in Rails applications?

The authentication’s most known way is a form with a field for an email and another for a password. We can do it with only Rails, but we need to consider the security of storing this information because it is the user's personal information.

There are many other ways of authentication, such as the one which is becoming more known last years: through social media apps. And, if our Rails application is API only, then we have other options like JWT (JSON Web Tokens). But we will leave this as a topic for another article.

What does Auth0 give us as a solution?

There are many ways in which a user can identify itself in our application. The more options the user has, the easier it will be to authenticate and use our application. In Rails, there are gems for each option we want to implement. This means a configuration for each one.

Auth0 gives us a solution to this problem. Auth0 offers us one way to make only one configuration in our application, and in its platform, we could choose what options (also known as identity providers) we want to give to our users. And, if we don’t know what options our users need to authenticate at the beginning, we could add them later without the necessity of changing our codebase.

You can find more info here: https://github.com/auth0/omniauth-auth0#what-is-auth0

Demo Time!

We’re going to integrate Auth0 in an application. This demo only will have two features: login and logout.

Configuration in Auth0 platform

First, let’s register in Auth0 or log in if we already have an account.
- We can create a new application for this demo if we already have an account.
  - Applications will be in the Applications menu, in the Applications submenu, choose Regular Web Application as the application type.
- If we have created a new account for this demo, we can use the default application in Auth0.
  - In our Default Application, we can change the application typo in theApplication Properties section in the Application Type field. Choose Regular Web Application and save the changes.
  - Let’s ensure that the Token Endpoint Authentication Method field is POST as the selected option.
- Now let’s configure some fields we will need to integrate our Rails app. In the Application URIs section, we will change these fields with the following values:
- Allowed Callback URLs: http://localhost:3000/auth/auth0/callback
  - URL where the user will be redirected after being authenticated or not (return errors) in Auth0.
- Allowed Logout URLs: http://localhost:3000
  - URL where the user without session will be redirected after his session finish.
- Also, we have to select at least one connection for our app, which means select one option for authentication:
- Go to the Connections tab and enable the Username-Password-Authentication option.

Base Configuration of Auth0 in our app

Let’s create our Rails app if we don’t have one already.
- In my case, I used the rails new command to create a demo app. I’m using rails 7.0 and ruby 3.1.
Add the omniauth-auth0 gem, which helps us with the Auth0 configuration in the OAuth process, and the omniauth-rails_csrf_protection gem, which helps us with the CSRF protection in the OAuth requests.
Now, we have to add these environment variables with the values we have in our app in the Auth0 platform:

  AUTH0_CLIENT_ID
  AUTH0_CLIENT_SECRET
  AUTH0_DOMAIN

  - I will use the `dotenv-rails` gem to handle the environment variables. With this gem, you can have a `.env` file to save all the environment variables needed in your application.

To the initial configuration of Auth0, we need to create a file called auth0.rb in the config/initializers folder:
- Or you can run this command: touch config/initializers/auth0.rb

Add the following configuration in the file:

Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
   :auth0,
   ENV["AUTH0_CLIENT_ID"],
   ENV["AUTH0_CLIENT_SECRET"],
   ENV["AUTH0_DOMAIN"],
   callback_path: "/auth/auth0/callback",
   authorize_params: { scope: "openid profile" }
 )
end

In authorize_params, we tell Auth0 what info of the user we want Auth0 to give us. Here you can see some additional params we can pass in this hash.

Add the Login Feature

First, let’s add the following routes in routes.rb:

scope "/auth" do
  get "/auth0/callback", to: "auth0#callback"
  get "failure", to: "auth0#failure"
end

Let’s create the controller for the action of Auth0:
touch app/controllers/auth0_controller.rb
Inside the controller, let’s define the callback and failure actions:
```
def callback
  info = request.env['omniauth.auth']
  session[:user_info] = info['extra']['raw_info']
  redirect_to posts_path
end

def failure
  @error_msg = request.params['message']
end
```
- In the callback action, we’re reading the information I receive from the request with the key omniauth.auth. This value will be a hash with a key extra which has a hash as a value and inside this hash, we have a key raw_info.
  - For more info about the hash we receive: https://github.com/auth0/omniauth-auth0#authentication-hash
- Once we have the user’s info given by Auth0, we will save it in the user session and redirect to the page we want the logged user to see (this could be any page, I generated a scaffold for posts and used posts#index)
- In the failure action, we’re storing in a class variable the error message Auth0 sent, and then we can redirect the user or render a custom error page we want in our app.
Now we’ll add the login button inside the main layout, this is in views/layouts/application.html.erb
```
<%= button_to "Login", "/auth/auth0", method: :post, data: { turbo: false } %>
```
- I added data: { turbo: false } because the Rails buttons use turbo by default, and I’m deactivating in this particular case. You will have to make the same if your application use turbolinks.
In the ApplicationController, we’ll add a helper called current_user to can call the logged user.
```
helper_method :current_user

def current_user
  session[:user_info]
end
```

Now, let’s update the button_tag we use before to only show it if the current_user doesn’t exist, that means if there’s no logged user:

<% if current_user %>
  Hi <%= current_user["name"] %>
<% else %>
  <%= button_to "Login", "/auth/auth0", method: :post, data: { turbo: false } %>
<% end %>

Add the Logout feature

Let’s define the logout action in our routes and Auth0Controller:
```
# routes.rb inside de /auth scope
get '/auth/logout' => 'auth0#logout'

# Auth0Controller
def logout
  reset_session
  redirect_to logout_url
end
```
- The reset_session method, will delete all we have stored in the session
- And we redirect to a logout URL we’ll generate.

We’ll create a private method to generate this logout URL:

def logout_url
  request_params = { returnTo: post_url, client_id: ENV["AUTH0_CLIENT_ID"] }
  URI::HTTPS.build(
    host: ENV["AUTH0_DOMAIN"], path: "/v2/logout", query: to_query(request_params)
  ).to_s
end

def to_query(hash)
  hash.map { |k, v| "#{k}=#{CGI.escape(v)}" unless v.nil? }.compact.join("&")
end

Finally, we’ll add the logout button in our application/layout:

<%= button_to "Logout", "auth/logout", method: :get, data: { turbo: false } %>

Let’s try our app and that’s it! You now can implement Auth0 in a Rails app.

Autenticación con Auth0 en Rails

Kattya Cuevas — Mon, 28 Feb 2022 17:13:59 +0000

Versión en Inglés aquí

Uno de los features más importantes que la mayoría de aplicaciones tienen en común es la Autenticación.
Hay muchas opciones de autenticarnos actualmente, les hablaré de una solución que se viene usando mucho últimamente: Auth0 y cómo implementarlo en un proyecto en Rails.

Auth0 como una solución de Autenticación

¿Autenticación?

Primero definamos autenticación como la forma en que un usuario o un recurso en general se puede identificar en tu aplicación, es decir, una forma de reconocer que ese recurso en particular está interactuando con nuestra aplicación.

¿Cómo se puede autenticar en aplicaciones hechas en Rails?

La forma más conocida de autenticación es a través de un formulario con un campo para un email y otro para una contraseña. Esta forma podemos hacerla con Rails puro, pero tenemos que tener en cuenta la seguridad con que guardamos ese información, porque es información personal del usuario

Existen muchas otras formas de autenticación, como la que se está haciendo más conocida en los últimos años: a través de redes sociales. Y si nuestra aplicación en Rails solo es una API, entonces tenemos otras opciones con los JWT (Json Web Tokens). Esto lo dejaremos como tema para otro artículo.

¿Qué solución nos da Auth0?

Cómo mencioné antes, hay muchas formas en las que un usuario se puede identificar en nuestra aplicación.
Mientras más opciones le demos al usuario, será más fácil para este usuario autenticarse en nuestra aplicación.
En rails existen gemas para cada opción que queramos implementar. Pero, esto significa una configuración para cada una.

Auth0 nos da una solución a esto.
Nos dará una forma segura de hacer solo una configuración en nuestra aplicación y a través de su plataforma elegir qué opciones (identity providers) queremos darle a nuestros usuarios.
Y si al inicio aún no sabemos qué opciones les podemos dar, las podríamos ir agregando con el tiempo sin necesidad de volver a cambiar nuestro código.
Pueden encontrar un poco más de información sobre Auth0 por aquí: https://github.com/auth0/omniauth-auth0#what-is-auth0

Demo Time!

Haremos una aplicación de prueba para integrar Auth0, esta aplicación solo tendrá los features de inicio y cierre de sesión.

Configuración en la plataforma de Auth0

Primero nos crearemos una cuenta en Auth0 o nos loguearemos si ya tenemos una cuenta.
- Si ya tenemos una cuenta, podemos crear una nueva aplicación para este ejemplo
- Las aplicaciones estarán en el menu Applications, en el sub menú Applications, escoger Regular Web Application como tipo de aplicación
- Si nos hemos creado una cuenta para hacer este ejemplo, podemos usar la aplicación inicial que tenemos.
- En nuestra Default Application, podemos cambiar el tipo de aplicación en la sección Application Properties, en el campo Application Type escogemos Regular Web Application y guardamos los cambios.
- Asegurémonos que en el campo Token Endpoint Authentication Method esté POST como opción seleccionada.
- Ahora configuremos algunos campos que necesitaremos para la integración con nuestra aplicación en Rails. En la sección Application URIs, cambiemos estos campos con los siguientes valores:
- Allowed Callback URLs: http://localhost:3000/auth/auth0/callback
  - Este es la URL donde el usuario será redirigido una vez se haya autenticado o no (errores) en Auth0.
- Allowed Logout URLs: http://localhost:3000
  - Esta es la URL donde el usuario sin sesión será redirigido una vez que termine su sesión.
- Además tenemos que seleccionar al menos una conexión para nuestra aplicación, es decir selección una opción de autenticación:
- Nos vamos al tab Connections y habilitamos la opción Username-Password-Authentication

Configuración base de Auth0 en nuestra aplicación

Primero creamos nuestra aplicación en Rails si es que no la tenemos.
- En mi caso, usé el comando rails new para crear una app de ejemplo. Estoy usando rails 7.0 con ruby 3.1.
Agreguemos las gemas omniauth-auth0 que nos ayuda con la configuración de Auth0 y omniauth-rails_csrf_protection que nos ayuda con la protección CSRF en los requests de tipo OAuth.
Ahora tenemos que agregar estas variables de entorno con los valores que tenemos en nuestra aplicación en la plataforma de Auth0:
```
AUTH0_CLIENT_ID=
AUTH0_CLIENT_SECRET=
AUTH0_DOMAIN=
```
- Para manejar las variables de entorno, usaré la gema dotenv-rails. Con esta gema puedes tener un archivo .env el que guardes todas tus variables de entorno.
Creamos un archivo para la configuración inicial de Auth0, este debe estar en la carpeta config/initializers con el nombre auth0.rb
- O puedes ejecutar este comando: touch config/initializers/auth0.rb

Agregar la siguiente configuración en el archivo:

Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
   :auth0,
   ENV["AUTH0_CLIENT_ID"],
   ENV["AUTH0_CLIENT_SECRET"],
   ENV["AUTH0_DOMAIN"],
   callback_path: "/auth/auth0/callback",
   authorize_params: { scope: "openid profile" }
 )
end

En authorize_params estamos diciendo a Auth0 qué información queremos que nos devuelva. Por aquí, podrán ver algunos parámetros adicionales que podemos pasarle a este hash.

Agregar el feature de Inicio de Sesión

Primero agregaremos las siguientes rutas en routes.rb:

scope "/auth" do
  get "/auth0/callback", to: "auth0#callback"
  get "failure", to: "auth0#failure"
end

Creamos el controller para las acciones de Auth0:
- touch app/controllers/auth0_controller.rb
Dentro del controller, vamos a definir las acciones callback y failure:
```
def callback
  info = request.env['omniauth.auth']
  session[:user_info] = info['extra']['raw_info']
  redirect_to posts_path
end

def failure
  @error_msg = request.params['message']
end
```
- En la acción callback, estoy leyendo la información que me llega en el request con la key omniauth.auth. Este nos dará un hash con un key extra que tiene un hash como valor y dentro de este hash tenemos otro hash en el key raw_info.
- Para más información sobre el hash que nos llega: https://github.com/auth0/omniauth-auth0#authentication-hash
- Una vez que tenemos esta info del usuario que nos dió Auth0, lo guardaremos en la sesión del usuario y redirigimos a la página que queremos que vea el usuario logueado. (Creen cualquier página que quieran, yo generé un scaffold de posts)
- En la acción failure, estamos guardando en una variable de clase el mensaje del error que nos envia Auth0, y allí podemos hacer un redirect o un render de una página de error custom que queramos en nuestra app.
Ahora agreguemos el button para iniciar sesión dentro del layout principal, este está en views/layouts/application.html.erb
```
<%= button_to "Login", "/auth/auth0", method: :post, data: { turbo: false } %>
```
- Le agregué data: {turbo: false} porque los botones en Rails por defecto usan turbo, y lo estoy desactivando en este caso en particular. Tendrás que hacer lo mismo si tu aplicación usa turbolinks.
En el ApplicationController, agregaremos un helper llamado current_user para poder llamar al usuario logueado.
```
helper_method :current_user
def current_user
  session[:user_info]
end
```

Ahora actualizamos el button_tag que usamos hace un momento, para que se muestre solo si no existe el current_user, es decir si no hay usuario logueado:

<% if current_user %>
  Hi <%= current_user["name"] %>
<% else %>
  <%= button_to "Login", "/auth/auth0", method: :post, data: { turbo: false } %>
<% end %>

Agregar el feature de Cierre de Sesión

Definamos la acción logout en nuestras rutas y en Auth0Controller:
```
# routes.rb inside de /auth scope
get '/auth/logout' => 'auth0#logout'

# Auth0Controller
def logout
  reset_session
  redirect_to logout_url
end
```
- El método reset_session, borrará todo lo que tenemos guardado en sesión
- Y redirigimos a un url de logout que vamos a generar.

Crearemos un método privado para generar esta URL:

def logout_url
  request_params = { returnTo: post_url, client_id: ENV["AUTH0_CLIENT_ID"] }
  URI::HTTPS.build(
    host: ENV["AUTH0_DOMAIN"], path: "/v2/logout", query: to_query(request_params)
  ).to_s
end

def to_query(hash)
  hash.map { |k, v| "#{k}=#{CGI.escape(v)}" unless v.nil? }.compact.join("&")
end

Finalmente, agregaremos el button para cerrar sesión en nuestro application layout:

<%= button_to "Logout", "auth/logout", method: :get, data: { turbo: false } %>

Probemos cómo funciona nuestra app y listo! Ya puedes implementar Auth0 en una aplicación hecha en Rails.

Evitar Re-Renders al usar Context en React

Kattya Cuevas — Sat, 17 Apr 2021 19:41:39 +0000

Hace algunos meses, estaba haciendo un refactor en un proyecto de React y me quedé horas intentando resolver el problema. El refactor se debía a un problema típico de proyectos de React, pasar muchos props a los componentes hijos para así pasarlos a los hijos de estos y así.
Cuando este tipo de situaciones pasa, al querer actualizar alguno de los componentes o quizá solo quieras reutilizarlos en alguna otra parte, te obliga a tener información en tu nuevo componente que no necesitas en ese momento.

English version here

En fin, al terminar el refactor, separé la información en varios contextos, para así solo compartir la data necesaria con los componentes que lo necesitaban. Aunque suena como un refactor exitoso, no lo era, mis componentes se seguían actualizando cuando actualizaba un estado de un contexto del que no dependían. No tiene sentido, ¿verdad?

Para explicar mi problema, pondré un ejemplo.
Tengo 3 componentes:

SessionForm: Componente para agregar tu username. Si ya lo has ingresado, entonces te muestra un saludo y un botón para desloguearte (borrar el username). Si no lo has ingresado, te muestra un input para agregarlo.
SessionCounterMessage: Componente que muestra un mensaje con el username ingresado o un ‘You’ y el número que devuelva mi contador.
CounterButtons: Componente que tiene un contador. Son 2 botones que puedes sumar o restar al counter.

Siguiendo mi primera solución, aquí crearía 2 contextos. Uno para el username (SessionContext) y otro para el counter (CounterContext). Entonces la dependencia de contextos de mis componentes quedaría así:

SessionForm depende de SessionContext
CounterButtons depende de CounterContext
SessionCounterMessage depende de SessionContext y CounterContext

Esta fue mi solución inicial:

function App() {
  const [currentUser, setCurrentUser] = React.useState(null);
  const [counter, setCounter] = React.useState(1);

  return (
    <SessionContext.Provider
      value={React.useMemo(() => ({ currentUser, setCurrentUser }), [
        currentUser,
        setCurrentUser
      ])}
    >
      <CounterContext.Provider
        value={React.useMemo(() => ({ counter, setCounter }), [
          counter,
          setCounter
        ])}
      >
        <SessionForm />
        <SessionCounterMessage />
        <CounterButtons />
      </CounterContext.Provider>
    </SessionContext.Provider>
  );
}

Para que se den cuenta de mi error, agregué un console.log a mis componentes para que vean cuántas veces se renderizaba:

Allí pueden ver que cuando actualizo el counter, se vuelve a renderizar el componente SessionForm, a pesar de que no depende del contexto CounterContext que es quien tiene a counter como estado. Y que cuando actualizo el username se vuelve a renderizar el componente CounterButtons, que no depende del contexto SessionContext, que tiene a username como estado.

Ahora que vieron mi código, ¿encontraron el error?
Bueno, yo no encontraba fallas en mi lógica. Si los había separado en diferentes contextos. Entonces ¿por qué se seguían renderizando todos los componentes?

Lo que hice fue pedir ayuda. Le pregunté a @sergiodxa que tiene más tiempo usando React y me dijo:
Esto

const MyContext = React.useContext({});

function App() {
  const [state, setState] = React.useState(false);

  return (
    <MyContext.Provider value={ { state, setState } }>
      <MyCustomComponent />
    </MyContext.Provider>
  );
}

Es diferente a esto:

const MyContext = React.useContext({});

function MyContextProvider({ children }) {
  const [state, setState] = React.useState(false);

  return (
    <MyContext.Provider value={ { state, setState } }>
      {children}
    </MyContext.Provider>
  );
}

function App() {
  return (
    <MyContextProvider>
      <MyCustomComponent />
    </MyContextProvider>
  );
}

No me explicó el por qué en ese momento, quizá estaba ocupado, no lo recuerdo. Pero me di cuenta que estaba renderizando mi componente en el mismo lugar que estaba creando mis estados. Así que cada vez que actualizaba el estado, volvió a renderizar mi componente padre, que a su vez renderizaba a todos sus hijos.

Con esto en mente, voy a cambiar el ejemplo que les dí al inicio, para comprobar que realmente funciona.

function SessionProvider({ children }) {
  const [currentUser, setCurrentUser] = React.useState(null);

  return (
    <SessionContext.Provider
      value={React.useMemo(() => ({ currentUser, setCurrentUser }), [
        currentUser,
        setCurrentUser,
      ])}
    >
      {children}
    </SessionContext.Provider>
  );
}

function CounterProvider({ children }) {
  const [counter, setCounter] = React.useState(1);

  return (
    <CounterContext.Provider
      value={React.useMemo(() => ({ counter, setCounter }), [
        counter,
        setCounter,
      ])}
    >
      {children}
    </CounterContext.Provider>
  );
}

function App() {
  return (
    <SessionProvider>
      <CounterProvider>
        <SessionForm />
        <SessionCounterMessage />
        <CounterButtons />
      </CounterProvider>
    </SessionProvider>
  );
}

Aquí pueden ver los logs de las veces que se renderiza cada componente

¡Funciona! ¡No más renders innecesarios!

Puede parecer una cambio muy pequeño, incluso se puede llegar a pensar que el usuario no se va a dar cuenta. Pero los componentes que estaba refactorizando renderizaban audios y videos. Cada vez que hacían un cambio respecto a los audios, los videos se volvían a renderizar y se sentía como un bug en la aplicación.

Si llegaron hasta aquí, gracias por leerme. ❤️

Fixing Re-Renders When Using Context in React

Kattya Cuevas — Sat, 17 Apr 2021 19:40:05 +0000

Some months ago, I was refactoring a React project, and I was stuck in one problem for hours. The refactor was because of a common problem in React projects: Pass a lot of props to the child components, then you have to pass them to the child of them, and so. When this happens, if you want to reuse those components on another part of the app, you have to get information in your new component that maybe you don't need to worry about that time.

Versión en español aquí

I separated the data into many contexts, so I only share the necessary data with the component that needs them. So I stopped to pass a lot of props in every component. Even that sounds like a successful refactor, it wasn't. My components keep updating when I updated an state of a context which they didn't depend on. It doesn't make sense, right?

To explain my problem, I'll give you an example.
I'll have 3 components:

SessionForm: Component to add a username. If you have already entered it, it shows a greeting and a button to log out (delete the username). If you haven't entered it, it shows you an entry to add it.
SessionCounterMessage: Component that shows a message with the username entered or a You and the number returned by a counter.
CounterButtons: Component with a counter and 2 buttons that allow you to add or subtract from the counter.

Based on my first solution, I would create 2 contexts. One for the username (SessionContext) and one for the counter (CounterContext). Then the dependency of contexts of my components would look like this:

SessionForm depends onSessionContext
CounterButtons depends onCounterContext
SessionCounterMessage depends onSessionContext and CounterContext

This was my initial solution:

function App() {
  const [currentUser, setCurrentUser] = React.useState(null);
  const [counter, setCounter] = React.useState(1);

  return (
    <SessionContext.Provider
      value={React.useMemo(() => ({ currentUser, setCurrentUser }), [
        currentUser,
        setCurrentUser,
      ])}
    >
      <CounterContext.Provider
        value={React.useMemo(() => ({ counter, setCounter }), [
          counter,
          setCounter,
        ])}
      >
        <SessionForm />
        <SessionCounterMessage />
        <CounterButtons />
      </CounterContext.Provider>
    </SessionContext.Provider>
  );
}

I added a console.log to my components to make you aware of my error, I added a console.log to my components so that they see how many times it was rendered:

There you can see, when I update the counter, it re-renders the SessionForm component. Even when it doesn't depend on the CounterContext context, which has counter state.
And when I update the username, it re-renders the CounterButtons component. Even when it doesn't depend on the SessionContext context, which has username as a state.

Now you see my code, do you find my mistake?
Well, I didn't find any mistakes in my code if I had separated them into different contexts. Why did they keep re-render all the components?

What I did was ask for help. I asked @sergiodxa, who has been using React longer, and he said:
This

const MyContext = React.useContext({});

function App() {
  const [state, setState] = React.useState(false);

  return (
    <MyContext.Provider value={{ state, setState }}>
      <MyCustomComponent />
    </MyContext.Provider>
  );
}

is different from this:

const MyContext = React.useContext({});

function MyContextProvider({ children }) {
  const [state, setState] = React.useState(false);

  return (
    <MyContext.Provider value={{ state, setState }}>
      {children}
    </MyContext.Provider>
  );
}

function App() {
  return (
    <MyContextProvider>
      <MyCustomComponent />
    </MyContextProvider>
  );
}

He didn't explain why at that time; maybe he was busy, I don't remember. But I realized that I was rendering my component in the same place that I created my states. Every time I updated the state, it re-rendered my parent component, which re-render all its children.

With this in my mind, I'll change my initial example to check it works.

function SessionProvider({ children }) {
  const [currentUser, setCurrentUser] = React.useState(null);

  return (
    <SessionContext.Provider
      value={React.useMemo(() => ({ currentUser, setCurrentUser }), [
        currentUser,
        setCurrentUser,
      ])}
    >
      {children}
    </SessionContext.Provider>
  );
}

function CounterProvider({ children }) {
  const [counter, setCounter] = React.useState(1);

  return (
    <CounterContext.Provider
      value={React.useMemo(() => ({ counter, setCounter }), [
        counter,
        setCounter,
      ])}
    >
      {children}
    </CounterContext.Provider>
  );
}

function App() {
  return (
    <SessionProvider>
      <CounterProvider>
        <SessionForm />
        <SessionCounterMessage />
        <CounterButtons />
      </CounterProvider>
    </SessionProvider>
  );
}

Here you can see the logs when every component is rendered

It works! No more unnecessary renders!

It could look like a small change, and even you could think the user won't notice this change. But the components I was refactoring rendered audios and videos. Every time I updated the audios, the videos would be re-rendered, and it looks like a bug in the app.

If you made it this far, thanks for reading. ❤️

Mi primera app con React Native

Kattya Cuevas — Mon, 22 Jun 2020 01:17:10 +0000

React Native es un framework para desarrollar aplicaciones nativas iOS y Android con React. Hay dos formas de empezar una aplicación con React Native, la primera es usando el CLI (línea de comandos) de react-native y la segunda es usando el CLI de Expo.

Expo es una buena opción ya que tiene varios componentes adicionales construidos a partir de ReactNative para tener control de más APIs nativas y además te permite hacer build y deploy de tus aplicaciones para iOS, Android y web a la vez.

Para este tutorial, haré una aplicación de posts con comentarios usando expo. Si quieres seguir usando la primera opción, te recomiendo hacer el setup inicial siguiendo la documentación oficial de ReactNative.

Requerimientos:

node
yarn
expo-cli ```sh

$ npm install -g expo-cli

  > Para este post tengo la versión 3.21.9
- **(Opcional)** Emuladores Android y iOS, es opcional ya que con expo puedes probar desde tu celular, debes instalarte expo en tu celular.

Para crear una aplicación, para este caso llamado `MyPostApp`, solo debes correr:

```sh


$ expo init MyPostApp

Escoge empty template, para empezar con una página en blanco.

Para ingresar al proyecto:



$ cd MyPostApp

Para iniciar el proyecto:



$ yarn start

Expo te dará un código QR con el que podrás abrir la aplicación desde tu celular.

Para empezar a editar tu aplicación, solo debes ir al archivo App.js.



import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

export default function App() {
  return (
    <View style={styles.container}>
      <Text>Open up App.js to start working on your app!</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

Llamamos a 3 componentes de ReactNative:

View: Es un componente que representa un contenedor básico en la UI, este puede agrupar texto, imágenes, vídeos. Comparándolo con desarrollo web, es lo más parecido a una etiqueta div.
Text: Este componente se usa solo para mostrar texto o anidar etiquetas de texto. Solo con esta etiqueta se puede mostrar texto.
StyleSheet: Es una forma de escribir código CSS lo más parecido a CSS StyleSheets.

Listar Posts

Guardemos nuestros posts en un array por el momento, ya que no tendremos una interacción con una base de datos.



const POSTS = [
  {
    id: 1,
    body:
      "In irure minim in pariatur nisi irure reprehenderit cupidatat. Consequat ea enim veniam Lorem id nulla proident aute.",
    createdAt: new Date(2020, 3, 15),
    author: "elizabeth",
  },
  {
    id: 2,
    body:
      "Nisi laborum ea ad sit exercitation eu incididunt elit nostrud excepteur irure enim. Magna do aliqua officia officia dolore ad proident. Occaecat cillum sit veniam ea nostrud deserunt duis cupidatat laboris enim nostrud deserunt ex non.",
    createdAt: new Date(2020, 5, 2),
    author: "elizabeth",
  },
  {
    id: 3,
    body:
      "Nulla Lorem Lorem occaecat laboris minim anim sit ea eiusmod. Sunt ea ex exercitation est veniam.",
    createdAt: new Date(2020, 5, 25),
    author: "emma",
  },
];

Para renderizar listas con ReactNative, se usa FlatList estos props son las más básicos:

data: aquí se pasa nuestra estructura de datos
renderItem: se pasa el componente a renderizar, este va a recibir item como prop, conteniendo cada uno de los ementos de la lista
keyExtractor: Como es una lista, cada elemento debe tener un key



export default function App() {
  return (
    <View style={styles.container}>
      <FlatList
        data={POSTS}
        renderItem={({ item }) => <Text>{item.body}</Text>}
        keyExtractor={(post) => Number(post.id)}
      />
    </View>
  );
}

Si estas en iOS, verás que tu aplicación se renderiza sin importarle el StatusBar, para evitar que tome este espacio se usa SafeAreaView.

Agreguemos un poco de estilos a nuestra lista de posts:
Primero crearemos un componente para el card de cada post:



// components/PostCard.js

import React from "react";
import { View, Text, StyleSheet } from "react-native";

export default function PostCard({ post }) {
  return (
    <View style={styles.postContainer}>
      <Text style={styles.postBody}>{post.body}</Text>
      <Text style={styles.postAuthor}>{post.author}</Text>
    </View>
  );
}

const styles = StyleSheet.create({
  postContainer: {
    backgroundColor: "#dfefff",
    marginHorizontal: 20,
    marginVertical: 8,
    borderWidth: 1,
    borderColor: "#d1dcdf",
    borderRadius: 5,
    padding: 10,
  },
  postBody: {
    fontSize: 16,
    color: "#292944",
  },
  postAuthor: {
    alignSelf: "flex-end",
    color: "#6e6e7e",
    fontSize: 14,
  }
});

Actualizamos la página principal agregando un título y algunos estilos:



export default function App() {
  return (
    <SafeAreaView style={styles.container}>
      <Text style={styles.heading}>Posts List</Text>
      <FlatList
        data={POSTS}
        renderItem={({ item }) => <PostCard post={item} />}
        keyExtractor={post => post.body}
      />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: "#b4cefe",
    alignItems: "center",
    justifyContent: "center",
  },
  heading: {
    color: "#292944",
    fontSize: 24,
    fontWeight: "600",
    marginTop: 20,
    marginBottom: 10,
  }
});

Agregar un post

Para crear un post, se abrirá un modal con un formulario. Para esto, usaremos tres componentes nuevos:

TouchableOpacity: Es un componente que al presionarlo cambiará la opacidad. Este componente puede encerrar muchos componentes dentro. Tendrá un prop onPress que recibe una función que se ejecutará cuando se presione el componente.
Modal: Componente que representa un modal. Este recibe el prop visible que se encargará de mostrar o no la vista que se encuentre dentro de este componente.
TextInput: Componente que representa un input de tipo texto, adicional puedes pedir que al presionarlo abra un teclado en especial.

Primero crearemos nuestro componente con el contenido del modal, el formulario para agregar un nuevo post. Este componente recibirá tres props, visible que indicará si el modal se ve o no, setVisible será una función que recibe el nuevo valor de visible, y setPosts para editar la lista de posts inicial.

Para los valores del formulario, tendremos 2 estados, body y author. Para la UI, usaremos dos TextInput y un TouchableOpacity. En el prop onChangeText de los TextInput cambiaremos los valores de cada estado. Para el body, le agregaremos el prop multiline con valor true, así daremos la impresión de que el body contiene más que una linea de textos. El TouchableOpacity lo usaremos para agregar un nuevo post a nuestra lista de posts y limpiar el valor de cada estado usado en el formulario.



// components/NewPostModal.js

import React from "react";
import {
  Modal,
  View,
  TouchableOpacity,
  Text,
  TextInput,
  StyleSheet,
} from "react-native";

export default function NewPostModal({ visible, setVisible, setPosts }) {
  const [body, setBody] = React.useState("");
  const [author, setAuthor] = React.useState("");
  const createPost = () => {
    setPosts((posts) => [
      ...posts,
      { id: Date.now(), body, author, createdAt: Date.now() },
    ]);
    setBody("");
    setAuthor("");
    setVisible(false);
  };

  return (
    <Modal visible={visible} transparent={true}>
      <View style={styles.modalContainer}>
        <View style={styles.modalContent}>
          <TouchableOpacity onPress={() => setVisible(false)}>
            <View style={styles.closeButton}>
              <Text>X</Text>
            </View>
          </TouchableOpacity>
          <Text style={styles.title}>Nuevo post</Text>
          <View style={styles.inputGroup}>
            <TextInput
              placeholder="Body"
              style={[styles.textInput, { height: 35 }]}
              value={body}
              onChangeText={(text) => setBody(text)}
              multiline={true}
            />
          </View>
          <View style={styles.inputGroup}>
            <TextInput
              placeholder="Author"
              style={styles.textInput}
              value={author}
              onChangeText={(text) => setAuthor(text)}
            />
          </View>
          <TouchableOpacity
            onPress={() => createPost()}
            style={styles.createButton}
          >
            <Text>AGREGAR</Text>
          </TouchableOpacity>
        </View>
      </View>
    </Modal>
  );
}

const styles = StyleSheet.create({
  modalContainer: {
    backgroundColor: "rgba(0,0,0,0.8)",
    flex: 1,
    justifyContent: "center",
    alignItems: "center",
    paddingHorizontal: 25,
  },
  modalContent: {
    backgroundColor: "#fff",
    width: "100%",
    paddingHorizontal: 15,
    paddingVertical: 20,
  },
  closeButton: { alignSelf: "flex-end" },
  title: {
    fontSize: 20,
    textAlign: "center",
    marginBottom: 12,
  },
  inputGroup: { flexDirection: "row", marginVertical: 10 },
  textInput: {
    flex: 1,
    borderBottomWidth: 1,
    borderColor: "#b7b7b7",
    height: 24,
    paddingVertical: 4,
    paddingHorizontal: 5,
  },
  createButton: {
    alignSelf: "flex-end",
    borderWidth: 1,
    borderColor: "gray",
    paddingHorizontal: 20,
    paddingVertical: 5,
    marginTop: 15,
  },
});

Ahora agregaremos un botón en la página principal (App.js) que abrirá el nuevo modal que hemos creado. Para esto usaremos un TouchableOpacity.



// App.js

export default function App() {
  const [modalVisible, setModalVisible] = React.useState(false);
  const [posts, setPosts] = React.useState(POSTS);

  return (
    <SafeAreaView style={styles.container}>
      <Text style={styles.heading}>Posts List</Text>
      <FlatList
        data={posts}
        renderItem={({ item }) => <PostCard post={item} />}
        keyExtractor={(post) => post.body}
      />
      <TouchableOpacity onPress={() => setModalVisible(true)} style={styles.button}>
        <Text>Agregar post</Text>
      </TouchableOpacity>
      <NewPostModal visible={modalVisible} setVisible={setModalVisible} setPosts={setPosts} />
    </SafeAreaView>
  );
}

Con esto tenemos una app básica con ReactNative, con el que mostramos una lista de posts y podemos agregar un nuevo post en nuestra lista.

Building and Consuming a JSON API with Rails and React

Kattya Cuevas — Thu, 10 Oct 2019 22:58:17 +0000

When I thought about how to build an API, I started to search for what is the "best way" to do it. I found that exists specifications to build an API, you can found it here https://jsonapi.org. There, you would found a list of "rules" which we have to follow about how to send and receive data in an API.

The next doubt I had, after knowing the "best way" to build an API, is how am I going to build that API with all those rules? It looks so much work to do. Well... That's not true! In Rails, it's easy with a gem called jsonapi-resources.

In this project, the frontend will be done with React. The last version of Rails (v.6.0.0), Rails comes with Webpacker integrated (gem to handle the integration Rails + Webpack). It will make easier for us to use React. 🙌

Consume the data from our API with React, it's not hard. But, formatting the data to send to the API could be complex. There is another library to do this! Also, this library is going to help you to validate the form data. This library is Formik.

Let's start!

Versions of the tools we are going to use:

Ruby 2.6.3
Rails 6.0.0
Yarn 1.17.3

Setup Base Project

To create a new project with rails, we need to use the rails new command with the project name at the end.

We could also add some additional options. In this case, we will use --database=postgresql to use PostgreSQL as our database, --skip-turbolinks to avoid using turbolinks because we will handle routing in the frontend, and --webpack=react to make Rails generate the configuration for us to use React.js.

$ rails new my-app --database=postgresql --skip-turbolinks --webpack=react

Now, we're going to add a model called Post with 2 attributes: title and body. title is a string and body is a text. In Rails, the model represents the database tables. We can generate it with the rails generate model command followed by the model name with the attributes. The attributes should be separated by spaces and has the name and the type divided by :, like title:string. If we don't specify the type of the attribute, Rails will default to the type string.

The command generates a file with the model definition and a migration file that specifies the change to be made in the database, in this case, is the creation of the new table.

$ rails generate model Post title body:text
$ rails db:create
$ rails db:migrate

Note: We could also use rails g which is an alias of rails generate.

The rails db:create command creates the database of the project and the rails db:migrate command runs all the pending migrations since this is a new project it will run every migration.

We could add some seed data. To do it, we have to open the db/seeds.rb file and add the following lines:

Post.create(title: "Post 1", body: "My first Post")
Post.create(title: "Post 2", body: "My second Post")

And to populate the database with our seed data, we need to run the command:

$ rails db:seed

In Rails projects, we should define the main route of the application this one is going to handle the path /. Go to config/routes.rb to define it and inside of the block Rails.application.routes.draw, add:

root to: "home#index"

get "*path", to: "home#index", constraints: { format: "html" }

Note: The routes are defined as "home#index", this means the controller which is going to control the behavior is HomeController and the specified action in the controller is index.

We have to create the HomeController. First, let's create the home_controller.rb file in app/controllers folder. Inside, add the index action:

class HomeController < ApplicationController
  def index; end
end

Every action renders a view, in this case using HTML. We need to create the view in app/views/home folder and name it index.html.erb. In this file, we have to render the script to load our React app.

<%= javascript_pack_tag 'posts' %>

The helper javascript_pack_tag will generate the following script tag:

<script src="/packs/js/posts-a447c92837fa3b701129.js"></script>

Note: The name of the pack is generated with a hash added at the end to let us cached it for a long time.

This script will load the pack posts.jsx. We have to create that pack in the app/javascript/packs folder:

import React from "react";
import ReactDOM from "react-dom";
import App from "components/App";

document.addEventListener("DOMContentLoaded", () => {
  ReactDOM.render(
    <App />,
    document.body.appendChild(document.createElement("div"))
  );
});

We are going to use @reach/router to handle the routes in our React app. To install it, run:

$ yarn add @reach/router

Let's create the component App.js in app/javascript/components folder. We will use this component to manage the routes.

import React from "react";
import { Router } from "@reach/router";
import PostList from "./PostList";

function App() {
  return (
    <Router>
      <PostList path="/" />
    </Router>
  );
}

export default App;

Here we will create our first route /, which is going to render the PostList component.

Now we are going to create the component PostList.js in app/javascript/components folder.

import React from "react";

function PostList() {
  return <div>Hello from my React App inside my Rails App!</div>;
}

export default PostList;

Inside we are going to render a div to test our React App.

Start the Server

We need to install foreman to run the React and Rails apps at the same time. We can install it with the command:

$ gem install foreman

We should create a Procfile.dev file in the root of the project. Inside it, add:

web: bundle exec rails s
webpacker: ./bin/webpack-dev-server

To start the server, we need to run the command:

$ foreman start -f Procfile.dev

Create the API

To create our API following the JSON:API specification, we are going to use the gem jsonapi-resources. To use it, we have to add it to the Gemfile and install it running bundle install.

JSONAPI::Resources provides helper methods to generate correct routes. We'll add the routes for API in config/routes.rb, before get "*path":

namespace :api do
  jsonapi_resources :posts
end

Note: namespace :api is going to generate routes with /api before the route. Eg. /api/posts.

We're going to create the ApiController, to extend the controller from the ActionController::API module of Rails, and also we're going to include the JSONAPI::ActsAsResourceController from JSONAPI::Resources.

class ApiController < ActionController::API
  include JSONAPI::ActsAsResourceController
end

Now we need to create the PostsController. We should create it inside a folder named api because our routes config is going to search for an Api::PostsController class.

class Api::PostsController < ApiController
end

jsonapi_resources :posts require a PostResource class defined. We have to create PostResource in app/resources/api/post_resource.rb.

class Api::PostResource < JSONAPI::Resource
  attributes :title, :body
end

Here, we define the attributes and relationships we want to show as part of the resource.

To see how our response looks like, go to localhost:5000/api/posts.

Consume the API

We will make the React app consume our API. First, let's only read the data. Edit the PostList component to fetch the list of posts.

import React, { useEffect, useState } from "react";

function PostList() {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    const requestPosts = async () => {
      const response = await fetch("/api/posts");
      const { data } = await response.json();
      setPosts(data);
    };
    requestPosts();
  }, []);

  return posts.map(post => <div>{post.attributes.title}</div>);
}

export default PostList;

Inside a useEffect, we will do the fetch to /api/posts and save the response in the state of the component.

Now, let's create the form to add more posts. But first, we have to add formik as a dependency in the React app.

$ yarn add formik

We are going to create a new component to show the form, let's call it AddPost.js. In this component, we are going to make a POST method to /api/posts with the correct format of data to create a new post.

import React from "react";
import { navigate } from "@reach/router";
import { Formik, Field, Form } from "formik";

function AddPost() {
  const handleSubmit = values => {
    const requestPosts = async () => {
      // We get the CSRF token generated by Rails to send it
      // as a header in the request to create a new post.
      // This is needed because with this token, Rails is going to
      // recognize the request as a valid request
      const csrfToken = document.querySelector("meta[name=csrf-token]").content;
      const response = await fetch("/api/posts", {
        method: "POST",
        credentials: "include",
        headers: {
          "Content-Type": "application/vnd.api+json",
          "X-CSRF-Token": csrfToken
        },
        body: JSON.stringify({ data: values })
      });
      if (response.status === 201) {
        navigate("/");
      }
    };
    requestPosts();
  };

  return (
    <div>
      <h2>Add your post</h2>
      <Formik
        initialValues={{
          type: "posts",
          attributes: {
            title: "",
            body: ""
          }
        }}
        onSubmit={handleSubmit}
        render={() => (
          <Form>
            <Field type="text" name="attributes.title" />
            <Field type="text" name="attributes.body" />

            <button type="submit">Create</button>
          </Form>
        )}
      />
    </div>
  );
}

export default AddPost;

Finally, we need to add the route /add in our React app.

import React from "react";
import { Router } from "@reach/router";
import PostList from "./PostList";
import AddPost from "./AddPost";

function App() {
  return (
    <Router>
      <PostList path="/" />
      <AddPost path="/add" />
    </Router>
  );
}

export default App;

If we go to localhost:5000/add, we will see the form. If we fill the fields and click on Submit, it will create a new post and will navigate automatically to localhost:5000/, where we will see our new post as part of the list.

If we reload the page, the React app will fetch our post again with the new post we just created.

That's how we can create an application with Rails + React, following the JSON:API spec.

I would love any feedback about the post or the libraries used here. ❤️