Hay muchos casos en que los entornos de desarrollo pueden diferir de computadora a computadora. Este no es el caso con los editores de texto o IDE’s. Pienso que para el desarrollo en Rails un IDE es demasiado, pero alguien podría encontrarlo como la mejor forma de hacerlo, así que si es tú caso te recomiendo que lo hagas con RadRails o RubyMine, ambos están bien soportados y vienen con muchas integraciones 'out of the box'.

Editor de texto: En lo personal uso vim como mi editor por defecto con janus el cual puede añadir y manejar muchos de los plugins que probablemente vas a utilizar. En caso que no sea un fan de vim como yo, hay muchas otras soluciones como Sublime Text que es multi plataforma, fácil de aprender y personalizable (este es probablemente tú mejor opción), esta altamente inspirado por TextMate (solo disponible para Mac OS). Una tercera opción es usando un muy reciente editor de texto de los chicos de GitHub llamado Atom, es un prometedor editor de texto echo con JavaScript, es fácil de extender y personalizar para satisfacer tus necesidades, dale una oportunidad. Cualquiera de los editores que te presento harán del trabajo, así que te dejo elegir cual se ajusta a tu ojo.

Terminal: Si decides seguir con kaishi para configurar el entorno, notarás que pone pro defecto el shell con zsh, lo cual recomiendo bastante. Para la terminal, no soy fan de aplicaciones de Terminal que traen mejoras si estas en Mac OS, así que mira iTerm2, Que es un remplazo de la terminal para Mac OS. Si estas en Linux probablemente ya tienes una linda terminal, pero la que viene por defecto puede funcionar bien.

Cuando se trata de navegadores diría Firefox inmediatamente, pero algunos otros desarrolladores pueden decir Chrome o incluso Safari. Cualquiera de ellos ayudara a construir la aplicación que buscas, ellos vienen con un buen inspector no justamente para el DOM pero para el análisis de red y muchas otras características que ya conoces.

Usaremos Git bastante, y puedes usarlo no solo para el propósito de este tutorial sino para cada proyecto independiente.

Son muchos los caminos en que puedes instalar y gestionar ruby, y ahora tú puedes tener probablemente alguna versión instalada si estas en Mac OS, para ver la versión que tienes, solo ejecuta:

Rails 6.0 requiere la instalación de la versión 2.5 o mayor.

Yo recomiendo usar Ruby Version Manager (RVM) ó rbenv para instalarlo. Vamos a usar RVM en este tutorial, pero no hay problema con cuál de las 2 utilices.

El principio de esta herramienta es permitirte instalar varias versiones de Ruby en el mismo equipo, en un entorno hermético con una posible versión instalada en tu sistema operativo y luego tener la habilidad de cambiar de una a otra versión fácilmente.

Para instalar RVM, ve a https://rvm.io/ e instala la huella de la llave GPG: [La huella de la llave GPG te permite verificar la identidad del autor o del origen de la descarga.]. Para realizarlo ejecutamos:

Ahora instalaremos ruby:

Ahora es momento de instalar el resto de dependencias que vamos a usar.

Antes de comenzar a escribir código, preparamos el código con git. Vamos a estar usando una rama por capítulo, la subiremos a GitHub y entonces la fusionaremos con la rama master. Así que vamos a a iniciar abriendo la terminal, cd hacia el directorio market_place_api y tecleamos lo siguiente:

Únicamente vamos a estar trabajando en config/routes.rb, ya que solo vamos a establecer las restricciones y el formato de respuesta predeterminado para cada respuesta.

Primero que todo borra todo el código comentado que viene en el archivo, no lo vamos a necesitar. Entonces haz un commit, solo como un calentamiento:

Vamos a aislar los controladores del API bajo un espacio de nombres. Con Rails esto es bastante simple: solo tienes que crear un folder en app/controllers llamado api. El nombre es importante porque es el espacio de nombres que usaremos para gestionar los controladores para los endpoints del api.

Entonces agregamos el nombre de espacio dentro de nuestro archivo routes.rb:

Por definición un espacio de nombres en el archivo routes.rb. Rails automáticamente mapeara que espacio de nombres corresponde al folder de los controlladores, en nuestro caso el directorio api/`.

Esto es importante porque vamos a trabajar con JSON, uno de los tipos MIME aceptados por Rails, solo necesitamos especificar que este es el formato por defecto:

Hasta este punto no hemos hecho nada loco. Ahora lo que queremos es una base_uri que incluye la versión de la API. Pero hagamos commit antes de ir a la siguiente sección:

Comenzaremos por generar nuestro modelo User. Este modelo será realmente básico y tendrá solo dos campos:

Generamos nuestro modelo User usando el comando generate model provisto por Ruby on Rails. Es muy fácil de usar:

¡Este comando genera un montón de archivos! No te preocupes revisaremos uno por uno.

El archivo de migración contenido en el forder db/migrate contiene la migración que describe los cambios que realizará en la base de datos. Este archivo puede lucir así:

Haremos un pequeño cambio a la migración a fin de añadir algunas validaciones a la base de datos. Con rails es una práctica común hacer validaciones directamente en el modelo Ruby. Es buena práctica hacer algo en el esquema de la base de datos.

Por lo tanto haremos dos restricciones adicionales:

La migración quedaría así:

Una vez completa la migración, podemos correr los cambios con el siguiente comando:

Previamente implementamos el almacenamiento de los datos del usuario. Pero seguimos teniendo un problema por resolver: el almacenamiento de la contraseña está en texto plano.

Así que vamos a usar la gema bcrypt para hashear la contraseña.

Primero debemos agregar la gema Bcrypt al Gemfile. Podemos usar el comando bundle add. Que hará:

Por lo tanto, ejecutamos el siguiente comando:

Una vez que el comando es ejecutado, la siguiente línea es añadida al final del Gemfile:

Active Record nos ofrece un método ActiveModel::SecurePassword::has_secure_password que hará interfaz con Bcrypt y nos ayudará con la contraseña lo que lo hace más fácil.

has_secure_password agrega las siguientes validaciones:

En adición, este método añadirá un atributo User#password que será automáticamente hasheado y guardado en el atributo User#password_digest.

Vamos a intentarlo ahora mismo en la consola de Rails. Abre una consola con rails console:

Puedes ver que cuando llamas al método User#create! , el atributo password es hasheado y guardado en password_digest. Vamos a enviar también un atributo password_confirmation que ActiveRecord comparará con password:

¡Todo está trabajando como lo planeamos! Vamos a hacer un commit para mantener la historia concisa:

Así que finalmente tenemos un recurso para probar. Tenemos muchas soluciones para probarlo. La primera que se me viene a la mente es hacer uso de cURL, el cual está integrado en la mayoría de distribuciones Linux. Así que vamos a probarlo:

Primero inicializamos el servidor de Rails en una nueva terminal.

Entonces cambia de nuevo a tu otra terminal y corre:

Encontramos el usuario que creamos con la consola de Rails en la sección previa. Ahora tienes una entrada en el API para registro de usuarios.

Ahora que tenemos mejor entendimiento de como construir "entry points" (puntos de entrada), es tiempo de extender nuestra API. Una de las características más importantes es darles a los usuarios que puedan crear un perfil en nuestra aplicación. Como siempre, vamos a escribir nuestras pruebas antes de implementar nuestro código para extender nuestro banco de pruebas.

Asegura que tu directorio de Git está limpio y que no tienes algún archivo en staging. Si es así hazles commit que vamos a empezar de nuevo.

Así que vamos a iniciar por escribir nuestra prueba añadiendo una entrada para crear un usuario en el archivo users_controller_test.rb:

Es un montón de código. No te preocupes explicare todo:

Hasta este punto, la prueba debería de fallar (como esperábamos):

Asi que es tiempo de implementar el código para que nuestra prueba sea exitosa:

Recuerda que cada vez que agregamos una entrada en nuestra API debemos agregar esta acción en nuestro archivo routes.rb.

Como puedes ver, la implementación es bastante simple. También hemos añadido el método privado user_params para proteger de la asignación masiva de atributos. Ahora nuestra prueba debería de pasar:

Yeah! Hagamos commit de los cambios y a continuar construyendo nuestra aplicación:

El esquema para actualizar usuarios es muy similar a la de creación. Si eres un desarrollador Rails experimentado, ya sabes las diferencias entre estas dos acciones:

Como siempre, empezamos escribiendo nuestra prueba:

Para que la prueba se exitosa, debemos construir la acción update en el archivo users_controller.rb y agregar la ruta al archivo routes.rb. Como puedes ver, tenemos mucho código duplicado, vamos a rediseñar nuestra prueba en el capítulo 4. Primero añadimos la acción al archivo routes.rb:

Entonces implementamos la acción update en el controlador del usuario y corremos las pruebas:

Todas nuestras pruebas deberían pasar:

Hacemos un commit ya que todo funciona:

Hasta aquí, hemos hecho un montón de acciones en el controlador del usuario con sus propias pruebas, pero no hemos terminado. Solo necesitamos una cosa más, que es la acción de destruir. Así que vamos a crear la prueba:

Como puedes ver, la prueba es muy simple. Únicamente respondemos con estado 204 que significa No Content (Sin contenido). También podríamos devolver un código de estado 200, pero encuentro más natural la respuesta No Content (Sin contenido) en este caso porque eliminamos un recurso y una respuesta exitosa podría ser bastante.

La implementación de la acción de destrucción es muy simple:

No olvides añadir la acción destroy en el archivo routes.rb:

Las pruebas deberían de pasar si todo es correcto:

Recuerda que después de hacer algunos cambios en nuestro código, es buena práctica hacerles commit así podremos tener un historial segmentado correctamente.

Y a medida que llegamos al final de nuestro capítulo, es tiempo de aplicar nuestra modificaciones a la rama master haciendo un merge:

Cuando nos acercamos a los tokens de autenticación, tenemos un estándar: el JSON Web Token (JWT).

En general un token JWT se compone de tres partes:

Estas tres partes son cada una codificadas en base64 y entonces concatenadas usando puntos (.). Lo cual nos da algo como:

Una ves decodificado, este token nos da la siguiente información:

Esto tiene muchas ventajas justo como enviar información en payload de tokens. Por ejemplo, podemos elegir integrar información del usuario en el payload.

El estándar JWT tiene muchas implementaciones en varios lenguajes y librerías. Por supuesto, hay una gema de Ruby en este tema: ruby-jwt.

Asi que vamos a comenzar instalándola:

Una vez completada la siguiente línea es añadida a tu Gemfile:

La librería es muy simple. Hay dos métodos: JWT.encode y JWT.decode. Vamos a abrir una terminal con console rails y a correr algunas pruebas:

En la primera línea codificamos un payload con la llave secreta my_secret_key. así obtenemos un token que podemos decodificar de manera simple. La segunda línea decodifica el token y vemos que podemos encontrar sin dilema nuestro payload.

Vamos a incluir toda la lógica en una clase JsonWebToken en un nuevo archivo localizado en lib/. Esto nos permite evitar el código duplicado. Esta clase justamente codificará y decodificará los tokens JWT. Así que aquí está la implementación.

Yo se que es un montón de código pero lo revisaremos juntos.

Ahí tienes. Para cargar el archivo en tú aplicación, necesitas especificar el directorio lib en la lista de _autoload de Ruby on rails. Para hacerlo, agrega la siguiente configuración al archivo application.rb:

Y eso es todo. Ahora es tiempo de hacer un commit:

Tenemos sin embargo que configurar el sistema para generar un token JWT. Es ahora tiempo de crear una ruta que generará este token. Las acciones que implementaremos serán administradas como servicios RESTful: la conexión será gestionada por una petición POST a la acción create.

Para empezar, iniciaremos creando el controlador y el método create en el namespace /api/v1. Con Rails, una orden es suficiente:

Modificaremos la ruta un poco para respetar las convenciones REST:

Vamos a construir pruebas funcionales antes de ir más lejos. El comportamiento deseado es el siguiente:

Las pruebas por lo tanto se materializan de la siguiente forma:

Te estarás preguntando: "¿pero como puedes saber la contraseña del usuario?". Simplemente usa el método BCrypt::Password.create en los fixtures de users:

En este preciso momento, si corres las pruebas obtendrás dos errores:

Es normal. Ahora es tiempo de implementar la lógica para crear el token JWT. Es muy sencillo.

Es un montón de código pero es muy simple:

¿Estas hasta aquí? ¡No te preocupes, esta terminado! Ahora tus pruebas deberían pasar.

¡Muy bien! Es tiempo de hacer un commit que contendrá todos nuestros cambios:

Es tiempo ahora de actualizar nuestro archivo users_controller.rb para negar el acceso a ciertas acciones. Vamos también a implementar el método current_user en las acciones update y destroy para asegurarnos que el usuario que esta logueado solo podrá actualizar sus datos y puede únicamente borrar (y solo) su cuenta.

Por lo tanto dividimos nuestra prueba en dos pruebas should update user y should destroy user.

Iniciamos por actualizar la prueba should update user.

Puedes ver ahora que tenemos que añadir una cabecera Authorization para la acción de modificar usuarios. De lo contrario queremos recibir una respuesta forbidden.

Podemos pensar de forma similar para la prueba should forbid destroy user:

Por el momento estas pruebas pueden fallar como ya lo podrías esperar:

La solución es muy simple. Vamos a añadir un before_action el cual llamará al método check_owner para las acciones update y destroy. De esta forma comprobamos que el usuario que corresponde al token JWT es el mismo que el usuario que necesita ser actualizado.

Ésta es la implementación:

¡Ahí tienes! La implementación es realmente simple. Es por lo tanto tiempo de hacer un commit:

La plantilla Product necesitara varios campos:

El archivo de migración debería lucir así:

Ahora solo tenemos que iniciar la migración:

Una prueba debería de fallar hasta este punto:

Seguramente dirás:

Lo que he visto en el código de otros desarrolladores, cuando ellos trabajan con asociaciones, es que se olvidan de la destrucción de dependencias entre modelos. Lo que digo con esto es que si un usuario es eliminado, también lo deberían de ser los productos del usuario.

Necesitamos un usuario con uno de los productos para probar esta interacción entre modelos. Entones eliminaremos este usuario esperando que los productos desaparezcan con él. Rails ya tiene generado esto por nosotros. Echa un vistazo a el fixture de los productos:

Puedes ver que este fixture no usa el atributo user_id pero si user. Esto significa que el producto one tendrá un atributo user_id correspondiente al ID de usuario one.

Es por lo tanto necesario especificar un borrado en cascada a fin de que sea eliminado el producto one cuando el usuario one es eliminado. Vamos empezar con la prueba unitaria:

Justamente tienes que modificar el modelo User y especificar la relación has_many con la opción depend: :destroy. Veremos más tarde que hace este método con mas detalle.

Eso es todo. Ahor hacemos un commit:

Las validaciones son una parte importante cuando construimos cualquier tipo de aplicación. Esto evitará que cualquier dato basura sea guardado en la base de datos. En el producto tenemos que asegurarnos que por ejemplo el precio es un number (número) y que no es negativo.

También una cosa importante sobre la validación es validar que cada producto tiene un usuario. En este caso necesitamos validar la presencia del user_id. Puedes ver que estoy hablando en siguiente fragmento de código.

Ahora necesitamos añadir la implementación para hacer que la prueba pase:

La prueba ahora está en verde:

Tenemos un montón de código de buena calidad. Hagamos un commit y sigamos moviéndonos:

Como es usual iniciaremos por añadir algunas especificaciones para la acción show para el producto en su controlador. La estrategia aquí es muy simple: justamente necesitamos crear un único producto y asegurar que la respuesta desde el server es la que esperamos.

Entonces añadimos el código que hará pasar las pruebas:

¡Espera! Aun no corras las pruebas. Recuerda que necesitamos añadir el recuro al archivo routes.rb:

Ahora nos aseguramos que las pruebas están bien y en verde:

Como puedes notar ahora las especificaciones e implementación son muy sencillas. En realidad, se comportan igual que el usuario.

Ahora es tiempo de devolver una lista de productos (los cuales serán mostrados como catálogo de productos de la tienda). Este endpoint debe ser accesible sin credenciales. Significa que no requerimos que el usuario este logueado para acceder a la información. Como es usual empezaremos escribiendo algunas pruebas:

Vamos a la implementación, la cual por ahora está siendo un método index simple:

No olvides añadir la ruta correspondiente:

Terminamos por ahora con el endopint al producto público. En la siguiente sección nos enfocaremos en la construcción de las acciones solicitando un usuario logueado para acceder a ellos. Dicho esto, haremos commit de estos cambios y continuamos.

Crear productos es un poco más complejo porque necesitaremos una configuración adicional. La estrategia que seguiremos es asignar el producto creado al usuario que pertenece al token JWT proporcionado en la cabecera HTTP Authorization.

Así que iniciamos con el archivo products_controller_test.rb:

¡Wow! Añadimos un montón de código. Si recuerdas la sección anterior, las pruebas son muy similares que las de la creación de usuarios. Excepto por algunos cambios menores.

De esta forma, podemos ver al usuario y la creación del producto asociado con el. Pero espera! Hay algo mejor.

Si adoptamos este enfoque, podemos incrementar el alcance de nuestro mecanismo de autenticación. Realmente construimos la lógica para obtener al usuario logueado desde la cabecera Authorization y asignarle un método current_user. Es por lo tanto bastante fácil de configurar simplemente añadiendo la cabecera de autorización a la solicitud y recuperando el usuario desde ahí. Entonces hagamoslo.

Como puedes ver, protegemos la acción create con el método check_login. También creamos al producto por asociación con el usuario. Yo agregué este método tan sencillo al concern del archivo authenticable.rb:

Una última cosa antes de hacer tus pruebas: la ruta necesaria:

Ahora las pruebas deberían pasar:

Espero que por ahora entiendas la lógica para construir la acciones que vienen. En esta sección nos enfocaremos en la acción update que funcionará a la acción create. Solamente necesitamos buscar el producto desde la base de datos y actualizarlo.

Añadiremos primer la acción a las rutas así no nos olvidamos después:

Antes de iniciar borrando alguna prueba quiero aclarar que similarmente a la acción create vamos a dar alcance en el producto al con el método current_user. En este caso queremos asegurar que el producto que se está actualizando pertenece al usuario actual. Así que buscaremos los productos de la asociación user.products proveída por Rails.

Agreguemos algunas especificaciones:

Las pruebas parecen complejas, pero echa un segundo vistazo. Son casi lo mismo que construimos para los usuarios.

Ahora vamos a implementar el código para hacer pasar nuestras pruebas:

La implementación es muy simple. Simplemente recuperaremos el producto desde el usuario conectad y simplemente lo actualizamos. Tenemos también agregadas esta acción a el before_action para prevenir cualquier usuario no autorizado desde la actualización de un producto.

Ahora las pruebas deberían pasar:

Nuestra última parada para los endpoints de los productos será la acción destroy (destruir). Podrías ahora imaginar cómo se vería esto. La estrategia aquí será demasiado similar a las acciones create y destroy: obtenemos al usuario logueado con el token JWT y entonces buscamos el producto desde la asociación user.products y finalmente lo destruimos, regresamos un código 204.

Vamos a iniciar de nuevo añadiendo el nombre de la ruta al archivo de rutas:

Después de esto, tenemos que añadir algunas pruebas como se muestra en este fragmento de código:

Ahora simplemente añadimos el código necesario para hacer pasar las pruebas:

Como puedes ver las cuatro líneas implementadas hacen el trabajo. Podemos correr las pruebas para asegurar que todo está bien y entonces haremos un commit de los cambios ya que hemos añadido un montón de código. También asegúrate que llamas a esta acción en el callback before_action al igual que en la acción update.

Hagamos commit de los cambios:

Hemos trabajado con serializadores y has notado que es muy simple. En algunos casos la decisión difícil es nombrar tus rutas o estructurar la salida JSON. Cuando se está trabajando con asociaciones entre modelos en la API hay muchos enfoques que puedes tomar.

No debemos preocuparnos de este problema en nuestro caso: Las especificaciones JSON:API lo hicieron por nosotros!

Para recapitular tenemos un tipo de asociación has_many entre usuarios y productos.

Es una buena idea integrar usuario en las salidas JSON de productos. Esto hará la salida más incomoda pero prevendrá al cliente de la API ejecutar otras peticiones para recibir información del usuario relacionada a los productos. Este método realmente puede salvarte de un enorme cuello de botella.

La primera solución (una buena en mi opinión) es integrar identificadores de usuarios enlazados a los productos un meta atributo. Así obtenemos un JSON como abajo:

Así que el cliente puede recuperar estos usuarios desde user_ids.

Otra solución es incorporar el objeto user en el objeto product. Esto debería hacer a la primera petición lenta, pero de esta forma el cliente no necesita hacer otra petición adicional. Un ejemplo del resultado esperado se presenta a continuación:

El problema con este enfoque es que tenemos duplicados del objeto `User' para cada producto que pertenece al mismo usuario:

LA tercer solución (elegida por JSON:API) es una combinación de las primeras dos.

Incluiremos todas las relaciones en una llave include que contendrá todas las relaciones de los objetos previamente mencionados. También, cada objeto incluirá una llave de relación que define la relación y que debería encontrar en cada llave include.

Un JSON vale mas que mil palabras:

¿Ves la diferencia? Esta solución reduce drásticamente el tamaño del JSON y por lo tanto el ancho de banda utilizado.

¿Entiendes el principio? tenemos incluida información del usuario en el JSON de los productos. Podemos hacer lo mismo incluyendo información del producto relacionada a un usuario para la página /api/v1/users/1.

Empecemos con la prueba:

serializer:

Y para finalizar el controlador:

Ahí tienes. Obtenemos un JSON como el siguiente:

Fue realmente fácil. Hagamos un commit:

Crearemos un scope para encontrar los registros que coinciden con un patrón de caracteres en particular. Vamos a llamarlo filter_by_title.

Comenzaremos por añadir algunos fixtures con diferentes productos para probar:

Y ahora podemos construir algunas pruebas:

La siguiente prueba se asegura que el método Product.filter_by_title buscará correctamente los productos de acuerdo con su título. Usamos el término tv en minúsculas para asegurar que nuestra búsqueda no sea sensitiva a mayúsculas y minúsculas.

Esta implementación es suficiente para que nuestras pruebas pasen:

Para filtrar por precio, las cosas pueden ser un poco más delicadas. Separaremos la lógica del filtrado por precio en dos diferentes métodos: uno que buscará por productos con precio mayor al recibido y otro que busque aquellos que son menores que el precio. De esta forma, mantendremos algo de flexibilidad y podemos fácilmente probar el scope.

Vamos a iniciar por construir las pruebas del scope above_or_equal_to_price:

La implementación es muy, muy sencilla:

Esto es suficiente para convertir nuestra prueba en verde:

Puedes imaginar el comportamiento del método opuesto. Aquí está la prueba:

y la implementación.

Para nuestros motivos, vamos a hacer la prueba y revisar que todo está hermosamente en verde:

Como puedes ver, no tuvimos muchos problemas. Vamos a añadir otro scope para acomodar los registros por la fecha de la última actualización. En el caso cuando el propietario de los productos decide actualizar alguna información seguramente buscará acomodar sus productos por la fecha de creación.

Este scope es muy fácil. Vamos a añadir algunas pruebas primero:

Y la implementación:

Todas nuestras pruebas deberían de pasar:

Vamos a guardar nuestros cambios: