osw4l / crs-api

CRS-API

Requerimientos

• Tener instalado Docker Y Docker compose
• Sistema operativo: Unix, Linux o Mac

El objetivo de esta prueba es crear un servicio que permita:

• Búsqueda de disponibilidad, mediante el cual se pueda consultar si hay habitaciones disponibles, es decir con cupo y precio, para un hotel y rango de fechas dado.
• Consultar y modificar la información básica necesaria para cargar la información de propiedades (hotel, habitaciones) e inventario (tarifas y precios).

Para levantar el proyecto se debe clonar de este repositorio y luego navegar hasta el en el terminal

para correr el proyecto solo se debe hacer uso de los comandos escritos en el Makefile, tiene comandos tanto para desarrollo, tests, cobertura, creacion de usuarios administradores, reiniciar contenedores y mas

Levantar el proyecto

para levantar el proyecto, solo se debe correr en la raiz del mismo el siguiente comando:

make up

este comando construirá la imagen de docker de este proyecto, ademas instalará de manera automatizada las dependencias, ejecutará las migraciones y cargará los archivos estáticos

Los contenedores son:

• backend (contiene el api)
• elastic (contiene elastic search para hacer búsquedas sencillas y evitar golpear la base de datos)
• postgres-skeleton-db (contiene la base de datos en postgres)

nuestra imagen con los contenedores por dentro seria esta

el backend está corriendo en el puerto 6060, en esta dirección -> http://0.0.0.0:6060/

una vez le des click al enlace vas a ver esta pantalla ->

si haces un poco mas de scroll serás capaz de ver todos

Un poco mas abajo se encuentran los modelos que contienen la definición de las estructuras de datos que vamos a manejar en el api

Setup de datos

este proyecto tiene 2 maneras de crear data, por el api docs de swagger (que es bastante intuitiva) y por el admin de Django, la segunda me gusta más porque es bastante visual y mas directa a la hora de insertar los datos.

Para acceder al administrador solo basta con ir a este link http://0.0.0.0:6060/admin/

Para crear un usuario administrador debemos ir al terminar y escribir make admin, recuerda presionar enter cuando termines un paso, tambien recuerda que por seguridad no se muestra la longitud de la contraseña por lo que cuando termines de escribir cualquiera de los campos de password deberas presionar enter

con nuestro usuario ya creado podremos volver al admin http://0.0.0.0:6060/admin/ e ingresar las credenciales que creamos para iniciar sesión

una vez dentro nos dirigimos a Hotels y presionamos Add + para crear nuestro hotel y sus habitaciones

Hemos agregado un hotel con una habitación, podemos seguir agregando mas habitaciones en el futuro

El campo deleted hace referencia a un campo marcado que sirve para simbolizar un borrado logico, cuando se encuentra en true el registro no estará visible por fuera del admin, quiere decir que no será listado tampoco en ninguna de las apis

En caso de eliminación por error se podrán restablecer los objetos afectados sin problema, si se elimina un hotel, todos los registros asociados al hotel dejarán de mostrarse en la api

Ahora vamos a crear un Rate, que pertenece solo a una habitación y tiene todos los precios y la ocupación para fechas especificas

podremos agregar tantos inventarios queramos, la única regla es que no se deben repetir fechas, cada fecha debe ser única en cada inventario asociado a un rate

con la data configurada podemos ver la información usando la ui de swagger http://0.0.0.0:6060/

Con data ingresada ya estamos listos para probar el api que nos genera este esquema de datos

es esta

Anotaciones varias

• Todos los endpoints tienen las operaciones crud con posibilidad de reversión en el delete

• Toda la data de los endpoints get que listan objetos, contienen paginación

• Los filtros de los objetos eliminados se hacen a través del BookingModelManager

• Todos los endpoints devuelven la información con el esquema que promete excepto el de la disponibilidad porque los atributos no son claves fijas sino que son claves dinámicas armadas a partir de los valores que van arrojando las habitaciones, rates y más

• El unico endpoint que tiene tests es el de Availability y el de Hotels

• se hicieron tests de integración para probar los servicios

• en el servicio de availability solo se hacen 2 queries

• hay una clase de paginación propia que puede modificarse a conveniencia

• todas las apis a diferencia de la de disponibilidad contienen buscador y filtros que pueden agregarse a conveniencia

• la primera linea roja es un registro de una clase que permite crear nuevos validadores para los tipos de datos esperados en los parametros de las urls

se usó django-extensions para obtener los alias de las urls para evitar llamarlas explicitamente

Estas son las tests que tiene el código actualmente

cosas que hubiese querido hacer

• mejorar la estructura de los serializadores
• optimizar las queries
• testear todos los serializer
• testear todas las vistas
• testear todos los modelos
• testear todos los managers y querysets
• testear el decorador action_paginated para paginar actions en los viewsets como los rooms de los hotels