Individual Pojects - Everything

Individual Project - Henry Countries
Objetivos del Proyecto

• Construir una App utlizando React, Redux, Node y Sequelize.
• Afirmar y conectar los conceptos aprendidos en la carrera.
• Aprender mejores prácticas.
• Aprender y practicar el workflow de GIT.
• Usar y practicar testing.
Horarios y Fechas
El proyecto tendrá una duración máxima de tres semanas. En el caso de que completan
todas las tareas antes de dicho lapso podrán avisar a su Instructor para coordinar una
fecha de presentación del trabajo (DEMO).
Comenzando
1. Forkear el repositorio para tener una copia del mismo en sus cuentas
2. Clonar el repositorio en sus computadoras para comenzar a trabajar
Tendrán un boilerplate con la estructura general tanto del servidor como de cliente.
IMPORTANTE: Es necesario contar minimamente con la última versión estable de

Node y NPM. Asegurarse de contar con ella para poder instalar correctamente las
dependecias necesarias para correr el proyecto.
Actualmente las versiónes necesarias son:
• Node: 12.18.3 o mayor

• NPM: 6.14.16 o mayor
Para verificar que versión tienen instalada:
node -v
npm -v
BoilerPlate
El boilerplate cuenta con dos carpetas: api y client. En estas carpetas estará el código
del back-end y el front-end respectivamente.
En api crear un archivo llamado: .env que tenga la siguiente forma:
DB_USER=usuariodepostgres
DB_PASSWORD=passwordDePostgres
DB_HOST=localhost
Reemplazar usuariodepostgres y passwordDePostgres con tus propias credenciales para

conectarte a postgres. Este archivo va ser ignorado en la subida a github, ya que
contiene información sensible (las credenciales).
Adicionalmente será necesario que creen desde psql una base de datos llamada countries
El contenido de client fue creado usando: Create React App.
Enunciado
La idea general es crear una aplicación en la cual se pueda ver información de distintos
paises utilizando la api externa restcountries y a partir de ella poder, entre otras cosas:
• Buscar paises
• Filtrarlos / Ordenarlos
• Crear actividades turísticas
IMPORTANTE: Para las funcionalidades de filtrado y ordenamiento NO pueden utilizar

los endpoints de la API externa que ya devuelven los resultados filtrados u ordenados
sino que deben realizarlo ustedes mismos. En particular alguno de los ordenamientos o
filtrados debe si o si realizarse desde el frontend.
Únicos Endpoints/Flags que pueden utilizar
• GET https://restcountries.eu/rest/v2/all
• GET https://restcountries.eu/rest/v2/name/{name}
• GET https://restcountries.eu/rest/v2/alpha/{code}
Requerimientos mínimos:
A continuación se detallaran los requerimientos mínimos para la aprobación del

proyecto individial. Aquellos que deseen agregar más funcionalidades podrán hacerlo.
En cuanto al diseño visual no va a haber wireframes ni prototipos prefijados sino que
tendrán libertad de hacerlo a su gusto pero tienen que aplicar los conocimientos de
estilos vistos en el curso para que quede agradable a la vista.
IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la

aplicación. Tendrán que utilizar CSS con algunas de las opciones que vimos en dicha
clase (CSS puro, CSS Modules o Styled Components)
Tecnologías necesarias:
• React
• Redux
• Express
• Sequelize - Postgres
Frontend
Se debe desarrollar una aplicación de React/Redux que contenga las siguientes

pantallas/rutas.
Pagina inicial: deben armar una landing page con
• Alguna imagen de fondo representativa al proyecto

• Botón para ingresar al home (Ruta principal)
Ruta principal: debe contener
• Input de búsqueda para encontrar países por nombre

• Área donde se verá el listado de países. Al iniciar deberá cargar los primeros
resultados obtenidos desde la ruta GET /countries y deberá mostrar su:
◦ Imagen de la bandera
◦ Nombre
◦ Continente
• Botones/Opciones para filtrar por continente y por tipo de actividad turística
• Botones/Opciones para ordenar tanto ascendentemente como descendentemente
los países por orden alfabético y por cantidad de población
• Paginado para ir buscando y mostrando los siguientes paises, 9 paises por pagina,
mostrando los primeros 9 en la primer pagina.
Ruta de detalle de país: debe contener
• Los campos mostrados en la ruta principal para cada país (imagen de la bandera,
nombre, código de país de 3 letras y continente)
• Código de país de 3 letras (id)
• Capital
• Subregión
• Área (Mostrarla en km2 o millones de km2)
• Población
• Actividades turísticas con toda su información asociada
Ruta de creación de actividad turística: debe contener
• Un formulario controlado con los siguientes campos

◦ Nombre
◦ Dificultad
◦ Duración
◦ Temporada
• Posibilidad de seleccionar/agregar varios países en simultaneo
• Botón/Opción para crear una nueva actividad turística
Base de datos
El modelo de la base de datos deberá tener las siguientes entidades (Aquellas

propiedades marcadas con asterísco deben ser obligatorias):
• País con las siguientes propiedades:

◦ ID (Código de 3 letras) *
◦ Nombre *
◦ Imagen de la bandera *
◦ Continente *
◦ Capital *
◦ Subregión
◦ Área
◦ Población
• Actividad Turística con las siguientes propiedades:
◦ ID
◦ Nombre
◦ Dificultad (Entre 1 y 5)
◦ Duración
◦ Temporada (Verano, Otoño, Invierno o Primavera)
La relación entre ambas entidades debe ser de muchos a muchos ya que un país puede
contener varias actividades turísticas y, a su vez, una actividad turística puede darse en
múltiples países. Por ejemplo una actividad podría ser "Ski" que podría ocurrir en
Argentina y también en Estados Unidos, pero a su vez Argentina podría también incluir
"Rafting".
Backend
Se debe desarrollar un servidor en Node/Express con las siguientes rutas:
IMPORTANTE: No está permitido utilizar los filtrados, ordenamientos y paginados

brindados por la API externa, todas estas funcionalidades tienen que implementarlas
ustedes.
• GET /countries:
◦ En una primera instancia deberán traer todos los países desde restcountries y
guardarlos en su propia base de datos y luego ya utilizarlos desde allí (Debe
almacenar solo los datos necesarios para la ruta principal)
◦ Obtener un listado de los paises.
• GET /countries/{idPais}:
◦ Obtener el detalle de un país en particular
◦ Debe traer solo los datos pedidos en la ruta de detalle de país
◦ Incluir los datos de las actividades turísticas correspondientes
• GET /countries?name="...":
◦ Obtener los países que coincidan con el nombre pasado como query
parameter (No necesariamente tiene que ser una matcheo exacto)
◦ Si no existe ningún país mostrar un mensaje adecuado
• POST /activity:
◦ Recibe los datos recolectados desde el formulario controlado de la ruta de
creación de actividad turística por body
◦ Crea una actividad turística en la base de datos
Testing
• Al menos tener un componente del frontend con sus tests respectivos

• Al menos tener una ruta del backend con sus tests respectivos
• Al menos tener un modelo de la base de datos con sus tests respectivos
Individual Project - Henry Dogs

• Afirmar y conectar los conceptos aprendidos en la carrera.
• Aprender y practicar el workflow de GIT.
Horarios y Fechas
El proyecto tendrá una duración máxima de tres semanas. En el caso de que completan todas
las tareas antes de dicho lapso podrán avisar a su Instructor para coordinar una fecha de
presentación del trabajo (DEMO).
Comenzando
IMPORTANTE: Es necesario contar minimamente con la última versión estable de Node y

NPM. Asegurarse de contar con ella para poder instalar correctamente las dependecias
necesarias para correr el proyecto.

Para verificar que versión tienen instalada:
node -v
npm -v
BoilerPlate
El boilerplate cuenta con dos carpetas: api y client. En estas carpetas estará el código del
back-end y el front-end respectivamente.
DB_HOST=localhost

conectarte a postgres. Este archivo va ser ignorado en la subida a github, ya que contiene
información sensible (las credenciales).
Adicionalmente será necesario que creen desde psql una base de datos llamada dogs
Enunciado
La idea general es crear una aplicación en la cual se puedan ver distintas razas de perro junto
con información relevante de las mismas utilizando la api externa the dog api y a partir de ella
poder, entre otras cosas:
• Buscar perros
• Agregar nuevos perros
IMPORTANTE: Para poder utilizar esta API externa es necesario crearse una cuenta para
obtener una API Key que luego debera ser incluida en todos los request que hagamos a rawg
simplemente agregando ?api_key={YOUR_API_KEY} al final de cada endpoint. Agregar la clave
en el archivo .env para que la misma no se suba al repositorio por cuestiones de seguridad y
utilizarla desde allí.
IMPORTANTE: Para las funcionalidades de filtrado y ordenamiento NO pueden utilizar los

endpoints de la API externa que ya devuelven los resultados filtrados u ordenados sino que
deben realizarlo ustedes mismos. En particular alguno de los ordenamientos o filtrados debe si
o si realizarse desde el frontend.
• GET https://api.thedogapi.com/v1/breeds
• GET https://api.thedogapi.com/v1/breeds/search?q={raza_perro}
A continuación se detallaran los requerimientos mínimos para la aprobación del proyecto

individial. Aquellos que deseen agregar más funcionalidades podrán hacerlo. En cuanto al
diseño visual no va a haber wireframes ni prototipos prefijados sino que tendrán libertad de
hacerlo a su gusto pero tienen que aplicar los conocimientos de estilos vistos en el curso para
que quede agradable a la vista.
IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la aplicación.

Tendrán que utilizar CSS con algunas de las opciones que vimos en dicha clase (CSS puro,
CSS Modules o Styled Components)
• React
• Redux
• Express
Frontend
Se debe desarrollar una aplicación de React/Redux que contenga las siguientes pantallas/rutas.

• Input de búsqueda para encontrar razas de perros por nombre

• Área donde se verá el listado de razas de perros. Deberá mostrar su:
◦ Imagen
◦ Nombre
◦ Temperamento
• Botones/Opciones para filtrar por por temperamento y por raza existente o agregada por
nosotros
• Botones/Opciones para ordenar tanto ascendentemente como descendentemente las
razas de perro por orden alfabético y por peso
• Paginado para ir buscando y mostrando las siguientes razas, mostrando 9 razas
inicialmente en la página uno.
IMPORTANTE: Dentro de la Ruta Principal se deben mostrar tanto las razas de perros traidas
desde la API como así también las de la base de datos.
Ruta de detalle de raza de perro: debe contener
• Los campos mostrados en la ruta principal para cada raza (imagen, nombre y
temperamento)
• Altura
• Peso
• Años de vida
Ruta de creación de raza de perro: debe contener

◦ Nombre
◦ Altura (Diferenciar entre altura mínima y máxima)
◦ Peso (Diferenciar entre peso mínimo y máximo)
◦ Años de vida
• Posibilidad de seleccionar/agregar uno o más temperamentos
• Botón/Opción para crear una nueva raza de perro
Base de datos
El modelo de la base de datos deberá tener las siguientes entidades (Aquellas propiedades
marcadas con asterísco deben ser obligatorias):
• Raza con las siguientes propiedades:

◦ ID *
◦ Nombre *
◦ Altura *
◦ Peso *
◦ Años de vida
• Temperamento con las siguientes propiedades:
◦ ID
◦ Nombre
La relación entre ambas entidades debe ser de muchos a muchos ya que una raza de perro
puede tener varios "temperamentos" en simultaneo y, a su vez, un "temperamento" puede
corresponder a múltiples razas de perro distintas. Por ejemplo la raza pug es docil, inteligente y
sociable (entre otras). Pero a su vez existen otras razas de perro que también son sociables o
inteligentes.
IMPORTANTE: Pensar como modelar los IDs de las razas de perros en la base de datos.
Existen distintas formas correctas de hacerlo pero tener en cuenta que cuando hagamos click
en alguna, esta puede provenir de la API o de la Base de Datos por lo que cuando muestre su
detalle no debería haber ambigüedad en cual se debería mostrar. Por ejemplo si en la API la
raza Pug tiene id = 1 y en nuestra base de datos creamos una nueva raza Henry Pug con id = 1,
ver la forma de diferenciarlas cuando querramos acceder al detalle de la misma.
Backend
IMPORTANTE: No está permitido utilizar los filtrados, ordenamientos y paginados

brindados por la API externa, todas estas funcionalidades tienen que implementarlas ustedes.
• GET /dogs:
◦ Obtener un listado de las razas de perro
◦ Debe devolver solo los datos necesarios para la ruta principal
• GET /dogs?name="...":
◦ Obtener un listado de las razas de perro que contengan la palabra ingresada como
query parameter
◦ Si no existe ninguna raza de perro mostrar un mensaje adecuado
• GET /dogs/{idRaza}:
◦ Obtener el detalle de una raza de perro en particular
◦ Debe traer solo los datos pedidos en la ruta de detalle de raza de perro
◦ Incluir los temperamentos asociados
• GET /temperament:
◦ Obtener todos los temperamentos posibles
◦ En una primera instancia deberán obtenerlos desde la API externa y guardarlos en
su propia base de datos y luego ya utilizarlos desde allí
• POST /dog:
creación de raza de perro por body
◦ Crea una raza de perro en la base de datos
Testing

Individual Project - Henry Food

• Afirmar y conectar los conceptos aprendidos en la carrera.
• Aprender y practicar el workflow de GIT.
Horarios y Fechas
El proyecto tendrá una duración máxima de tres semanas. En el caso de que completan
todas las tareas antes de dicho lapso podrán avisar a su Instructor para coordinar una
fecha de presentación del trabajo (DEMO).
Comenzando
IMPORTANTE: Es necesario contar minimamente con la última versión estable de

Node y NPM. Asegurarse de contar con ella para poder instalar correctamente las
dependecias necesarias para correr el proyecto.

Para verificar que versión tienen instalada:
node -v
npm -v
BoilerPlate
El boilerplate cuenta con dos carpetas: api y client. En estas carpetas estará el código
del back-end y el front-end respectivamente.
DB_HOST=localhost

conectarte a postgres. Este archivo va ser ignorado en la subida a github, ya que
contiene información sensible (las credenciales).
Adicionalmente será necesario que creen desde psql una base de datos llamada food
Enunciado
La idea general es crear una aplicación en la cual se puedan ver distintas recetas de
comida junto con información relevante de las mismas utilizando la api externa
spoonacular y a partir de ella poder, entre otras cosas:
• Buscar recetas
• Crear nuevas recetas propias
IMPORTANTE: Para poder utilizar esta API externa es necesario crearse una cuenta
para obtener una API Key que luego debera ser incluida en todos los request que
hagamos a spoonacular simplemente agregando ?apiKey={YOUR_API_KEY} al final de cada
endpoint. Agregar la clave en el archivo .env para que la misma no se suba al repositorio
por cuestiones de seguridad y utilizarla desde allí. Por otro lado tienen un límite de
requests por día por lo que usenlos con cuidado!
IMPORTANTE: Para las funcionalidades de filtrado y ordenamiento NO pueden utilizar

los endpoints de la API externa que ya devuelven los resultados filtrados u ordenados
sino que deben realizarlo ustedes mismos. En particular alguno de los ordenamientos o
filtrados debe si o si realizarse desde el frontend.
• GET https://api.spoonacular.com/recipes/complexSearch
◦ Para obtener mayor información sobre las recetas, como por ejemplo el tipo
de dieta deben agregar el flag &addRecipeInformation=true a este endpoint
◦ Para los tipos de dieta deben tener en cuenta las propiedades vegetarian,
vegan, glutenFree por un lado y también analizar las que se incluyan dentro
de la propiedad diets
• GET https://api.spoonacular.com/recipes/{id}/information
A continuación se detallaran los requerimientos mínimos para la aprobación del

proyecto individial. Aquellos que deseen agregar más funcionalidades podrán hacerlo.
En cuanto al diseño visual no va a haber wireframes ni prototipos prefijados sino que
tendrán libertad de hacerlo a su gusto pero tienen que aplicar los conocimientos de
estilos vistos en el curso para que quede agradable a la vista.
IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la

aplicación. Tendrán que utilizar CSS con algunas de las opciones que vimos en dicha
clase (CSS puro, CSS Modules o Styled Components)
• React
• Redux
• Express
Frontend
Se debe desarrollar una aplicación de React/Redux que contenga las siguientes

pantallas/rutas.

• Input de búsqueda para encontrar recetas por nombre

• Área donde se verá el listado de recetas. Deberá mostrar su:
◦ Imagen
◦ Nombre
◦ Tipo de dieta (vegetariano, vegano, apto celíaco, etc)
• Botones/Opciones para filtrar por por tipo de dieta
• Botones/Opciones para ordenar tanto ascendentemente como descendentemente
las recetas por orden alfabético y por puntuación
• Paginado para ir buscando y mostrando las siguientes recetas, 9 recetas por
pagina, mostrando las primeros 9 en la primer pagina.
IMPORTANTE: Dentro de la Ruta Principal se deben mostrar tanto las recetas traidas
desde la API como así también las de la base de datos. Debido a que en la API existen
alrededor de 5 mil recetas, por cuestiones de performance pueden tomar la
simplificación de obtener y paginar las primeras 100.
Ruta de detalle de receta: debe contener
• Los campos mostrados en la ruta principal para cada receta (imagen, nombre, tipo
de plato y tipo de dieta)
• Resumen del plato
• Puntuación
• Nivel de "comida saludable"
• Paso a paso
Ruta de creación de recetas: debe contener

◦ Nombre
◦ Resumen del plato
◦ Puntuación
◦ Nivel de "comida saludable"
◦ Paso a paso
• Posibilidad de seleccionar/agregar uno o más tipos de dietas
• Botón/Opción para crear una nueva receta
Base de datos
El modelo de la base de datos deberá tener las siguientes entidades (Aquellas

propiedades marcadas con asterisco deben ser obligatorias):
• Receta con las siguientes propiedades:

◦ ID: *
◦ Nombre *
◦ Resumen del plato *
◦ Puntuación
◦ Nivel de "comida saludable"
◦ Paso a paso
• Tipo de dieta con las siguientes propiedades:
◦ ID
◦ Nombre
La relación entre ambas entidades debe ser de muchos a muchos ya que una receta
puede ser parte de varios tipos de dieta en simultaneo y, a su vez, un tipo de dieta
puede contener múltiples recetas distintas. Un ejemplo tomado de la API sería el
Strawberry Mango Green Tea Limeade que es vegetariano, vegano y apto para celíacos, todo al
mismo tiempo. Pero a su vez existen otras recetas para vegetarianos.
IMPORTANTE: Pensar como modelar los IDs de las recetas en la base de datos.
Existen distintas formas correctas de hacerlo pero tener en cuenta que cuando hagamos
click en alguna receta, esta puede provenir de la API o de la Base de Datos por lo que
cuando muestre su detalle no debería haber ambigüedad en cual se debería mostrar.
Por ejemplo si en la API la receta Strawberry Mango Green Tea Limeade tiene id = 1 y en
nuestra base de datos creamos una nueva receta Medialunas de Manteca con id = 1, ver la
forma de diferenciarlas cuando querramos acceder al detalle de la misma.
Backend
IMPORTANTE: No está permitido utilizar los filtrados, ordenamientos y paginados

brindados por la API externa, todas estas funcionalidades tienen que implementarlas
ustedes.
• GET /recipes?name="...":
◦ Obtener un listado de las recetas que contengan la palabra ingresada como
query parameter
◦ Si no existe ninguna receta mostrar un mensaje adecuado
• GET /recipes/{idReceta}:
◦ Obtener el detalle de una receta en particular
◦ Debe traer solo los datos pedidos en la ruta de detalle de receta
◦ Incluir los tipos de dieta asociados
• GET /types:
◦ Obtener todos los tipos de dieta posibles
◦ En una primera instancia, cuando no exista ninguno, deberán precargar la
base de datos con los tipos de datos indicados por spoonacular acá
• POST /recipe:
creación de recetas por body
◦ Crea una receta en la base de datos
Testing

Individual Project - Henry Pokemon

Horarios y Fechas
Comenzando


node -v
npm -v
BoilerPlate
DB_HOST=localhost

Adicionalmente será necesario que creen desde psql una base de datos llamada pokemon
Enunciado
La idea general es crear una aplicación en la cual se puedan ver los distintos Pokemon
utilizando la api externa pokeapi y a partir de ella poder, entre otras cosas:
• Buscar pokemons
• Crear nuevos pokemons

• GET https://pokeapi.co/api/v2/pokemon
• GET https://pokeapi.co/api/v2/pokemon/{id}
• GET https://pokeapi.co/api/v2/pokemon/{name}
• GET https://pokeapi.co/api/v2/type


• React
• Redux
• Express
Frontend

• Input de búsqueda para encontrar pokemons por nombre (La búsqueda será exacta, es
decir solo encontrará al pokemon si se coloca el nombre completo)
• Área donde se verá el listado de pokemons. Al iniciar deberá cargar los primeros
resultados obtenidos desde la ruta GET /pokemons y deberá mostrar su:
◦ Imagen
◦ Nombre
◦ Tipos (Electrico, Fuego, Agua, etc)
• Botones/Opciones para filtrar por tipo de pokemon y por pokemon existente o creado
por nosotros
• Botones/Opciones para ordenar tanto ascendentemente como descendentemente los
pokemons por orden alfabético y por fuerza
• Paginado para ir buscando y mostrando los siguientes pokemons, 9 pokemons por
pagina, mostrando los primeros 9 en la primer pagina.
IMPORTANTE: Dentro de la Ruta Principal se deben mostrar tanto los pokemons traidos
desde la API como así también las de la base de datos. Por otro lado, si revisan el endpoint que
trae todos los pokemons verán que no muestra la información del pokemon sino una URL para
hacer un subrequest y obtener los datos de allí. Tendrán que por cada pokemon que van a
mostrar hacer otro request a esa URL para obtener su imagen y tipos. Debido a que esto puede
hacer que la búsqueda sea muy lenta limitar el resultado total a 40 pokemons totales.
Ruta de detalle de Pokemon: debe contener
• Los campos mostrados en la ruta principal para cada pokemon (imagen, nombre y tipos)
• Número de Pokemon (id)
• Estadísticas (vida, fuerza, defensa, velocidad)
• Altura y peso
Ruta de creación: debe contener
• Un formulario controlado con los campos mencionados en el detalle del pokemon

• Posibilidad de seleccionar/agregar más de un tipo de pokemon
• Botón/Opción para crear un nuevo pokemon
Base de datos
• Pokemon con las siguientes propiedades:

◦ ID (Número de Pokemon) * : No puede ser un ID de un pokemon ya existente en
la API pokeapi
◦ Nombre *
◦ Vida
◦ Fuerza
◦ Defensa
◦ Velocidad
◦ Altura
◦ Peso
• Tipo con las siguientes propiedades:
◦ ID
◦ Nombre
La relación entre ambas entidades debe ser de muchos a muchos ya que un pokemon puede
pertenecer a más de un tipo y, a su vez, un tipo puede incluir a muchos pokemons.
IMPORTANTE: Pensar como modelar los IDs de los pokemons en la base de datos. Existen
distintas formas correctas de hacerlo pero tener en cuenta que cuando hagamos click en
alguno, este puede provenir de la API o de la Base de Datos por lo que cuando muestre su
detalle no debería haber ambigüedad en cual se debería mostrar. Por ejemplo si en la API el
pokemon Bulbasaur tiene id = 1 y en nuestra base de datos creamos un nuevo pokemon Henry
con id = 1, ver la forma de diferenciarlos cuando querramos acceder al detalle del mismo.
Backend

• GET /pokemons:
◦ Obtener un listado de los pokemons desde pokeapi.
• GET /pokemons/{idPokemon}:
◦ Obtener el detalle de un pokemon en particular
◦ Debe traer solo los datos pedidos en la ruta de detalle de pokemon
◦ Tener en cuenta que tiene que funcionar tanto para un id de un pokemon existente
en pokeapi o uno creado por ustedes
• GET /pokemons?name="...":
◦ Obtener el pokemon que coincida exactamente con el nombre pasado como query
parameter (Puede ser de pokeapi o creado por nosotros)
◦ Si no existe ningún pokemon mostrar un mensaje adecuado
• POST /pokemons:
creación de pokemons por body
◦ Crea un pokemon en la base de datos
• GET /types:
◦ Obtener todos los tipos de pokemons posibles
◦ En una primera instancia deberán traerlos desde pokeapi y guardarlos en su propia
base de datos y luego ya utilizarlos desde allí
Testing

Individual Project - Henry Videogames

Horarios y Fechas
Comenzando


node -v
npm -v
BoilerPlate
DB_HOST=localhost

Adicionalmente será necesario que creen desde psql una base de datos llamada videogames
Enunciado
La idea general es crear una aplicación en la cual se puedan ver los distintos videojuegos
disponibles junto con información relevante de los mismos utilizando la api externa rawg y a
partir de ella poder, entre otras cosas:
• Buscar videjuegos
• Agregar nuevos videojuegos
IMPORTANTE: Para poder utilizar esta API externa es necesario crearse una cuenta para
obtener una API Key que luego debera ser incluida en todos los request que hagamos a rawg
simplemente agregando ?key={YOUR_API_KEY} al final de cada endpoint. Agregar la clave en el
archivo .env para que la misma no se suba al repositorio por cuestiones de seguridad y
utilizarla desde allí.

• GET https://api.rawg.io/api/games
• GET https://api.rawg.io/api/games?search={game}
• GET https://api.rawg.io/api/genres
• GET https://api.rawg.io/api/games/{id}


• React
• Redux
• Express
Frontend

• Input de búsqueda para encontrar videojuegos por nombre

• Área donde se verá el listado de videojuegos. Deberá mostrar su:
◦ Imagen
◦ Nombre
◦ Géneros
• Botones/Opciones para filtrar por género y por videojuego existente o agregado por
nosotros
• Botones/Opciones para ordenar tanto ascendentemente como descendentemente los
videojuegos por orden alfabético y por rating
• Paginado para ir buscando y mostrando los siguientes videojuegos, 9 juegos por pagina,
mostrando los primeros 9 en la primer pagina.
IMPORTANTE: Dentro de la Ruta Principal se deben mostrar tanto los videjuegos traidos
desde la API como así también los de la base de datos. Debido a que en la API existen
alrededor de 500 mil juegos, por cuestiones de performance pueden tomar la simplificación de
obtener y paginar los primeras 100.
Ruta de detalle de videojuego: debe contener
• Los campos mostrados en la ruta principal para cada videojuegos (imagen, nombre, y
géneros)
• Descripción
• Fecha de lanzamiento
• Rating
• Plataformas
Ruta de creación de videojuegos: debe contener

◦ Nombre
◦ Descripción
◦ Fecha de lanzamiento
◦ Rating
• Posibilidad de seleccionar/agregar varios géneros
• Posibilidad de seleccionar/agregar varias plataformas
• Botón/Opción para crear un nuevo videojuego
Base de datos
• Videojuego con las siguientes propiedades:

◦ ID: * No puede ser un ID de un videojuego ya existente en la API rawg
◦ Nombre *
◦ Descripción *
◦ Fecha de lanzamiento
◦ Rating
◦ Plataformas *
• Genero con las siguientes propiedades:
◦ ID
◦ Nombre
La relación entre ambas entidades debe ser de muchos a muchos ya que un videojuego puede
pertenecer a varios géneros en simultaneo y, a su vez, un género puede contener múltiples
videojuegos distintos. Un ejemplo sería el juego Counter Strike pertenece a los géneros
Shooter y Action al mismo tiempo. Pero a su vez existen otros videojuegos considerados como
Shooter o como Action.
IMPORTANTE: Pensar como modelar los IDs de los videojuegos en la base de datos. Existen
distintas formas correctas de hacerlo pero tener en cuenta que cuando hagamos click en algun
videojuego, este puede provenir de la API o de la Base de Datos por lo que cuando muestre su
detalle no debería haber ambigüedad en cual se debería mostrar. Por ejemplo si en la API el
videojuego Age of Empires II: Age of Kings tiene id = 1 y en nuestra base de datos creamos
un nuevo videojuego Age of Henry con id = 1, ver la forma de diferenciarlos cuando
querramos acceder al detalle del mismo.
Backend

• GET /videogames:
◦ Obtener un listado de los videojuegos
• GET /videogames?name="...":
◦ Obtener un listado de las primeros 15 videojuegos que contengan la palabra
ingresada como query parameter
◦ Si no existe ningún videojuego mostrar un mensaje adecuado
• GET /videogame/{idVideogame}:
◦ Obtener el detalle de un videojuego en particular
◦ Debe traer solo los datos pedidos en la ruta de detalle de videojuego
◦ Incluir los géneros asociados
• GET /genres:
◦ Obtener todos los tipos de géneros de videojuegos posibles
◦ En una primera instancia deberán traerlos desde rawg y guardarlos en su propia
base de datos y luego ya utilizarlos desde allí
• POST /videogame:
creación de videojuego por body
◦ Crea un videojuego en la base de datos
Testing


Individual Pojects - Everything

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Individual Pojects - Everything

Cargado por

Copyright:

Formatos disponibles

Individual Project - Henry Countries

Objetivos del Proyecto

IMPORTANTE: Es necesario contar minimamente con la última versión estable de

Actualmente las versiónes necesarias son:

• Node: 12.18.3 o mayor

Para veriﬁcar que versión tienen instalada:

En api crear un archivo llamado: .env que tenga la siguiente forma:

Reemplazar usuariodepostgres y passwordDePostgres con tus propias credenciales para

El contenido de client fue creado usando: Create React App.

IMPORTANTE: Para las funcionalidades de ﬁltrado y ordenamiento NO pueden utilizar

Únicos Endpoints/Flags que pueden utilizar

A continuación se detallaran los requerimientos mínimos para la aprobación del

IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la

Se debe desarrollar una aplicación de React/Redux que contenga las siguientes

Pagina inicial: deben armar una landing page con

• Alguna imagen de fondo representativa al proyecto

Ruta principal: debe contener

• Input de búsqueda para encontrar países por nombre

Ruta de detalle de país: debe contener

Ruta de creación de actividad turística: debe contener

• Un formulario controlado con los siguientes campos

El modelo de la base de datos deberá tener las siguientes entidades (Aquellas

• País con las siguientes propiedades:

Se debe desarrollar un servidor en Node/Express con las siguientes rutas:

IMPORTANTE: No está permitido utilizar los ﬁltrados, ordenamientos y paginados

• Al menos tener un componente del frontend con sus tests respectivos

Objetivos del Proyecto

IMPORTANTE: Es necesario contar minimamente con la última versión estable de Node y

Actualmente las versiónes necesarias son:

• Node: 12.18.3 o mayor

Para verificar que versión tienen instalada:

En api crear un archivo llamado: .env que tenga la siguiente forma:

Reemplazar usuariodepostgres y passwordDePostgres con tus propias credenciales para

El contenido de client fue creado usando: Create React App.

IMPORTANTE: Para las funcionalidades de filtrado y ordenamiento NO pueden utilizar los

Únicos Endpoints/Flags que pueden utilizar

A continuación se detallaran los requerimientos mínimos para la aprobación del proyecto

IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la aplicación.

Pagina inicial: deben armar una landing page con

• Alguna imagen de fondo representativa al proyecto

Ruta principal: debe contener

• Input de búsqueda para encontrar razas de perros por nombre

Ruta de detalle de raza de perro: debe contener

Ruta de creación de raza de perro: debe contener

• Un formulario controlado con los siguientes campos

• Raza con las siguientes propiedades:

Se debe desarrollar un servidor en Node/Express con las siguientes rutas:

IMPORTANTE: No está permitido utilizar los filtrados, ordenamientos y paginados

• Al menos tener un componente del frontend con sus tests respectivos

Objetivos del Proyecto

IMPORTANTE: Es necesario contar minimamente con la última versión estable de

Actualmente las versiónes necesarias son:

• Node: 12.18.3 o mayor

Para veriﬁcar que versión tienen instalada:

En api crear un archivo llamado: .env que tenga la siguiente forma:

Reemplazar usuariodepostgres y passwordDePostgres con tus propias credenciales para

El contenido de client fue creado usando: Create React App.

IMPORTANTE: Para las funcionalidades de ﬁltrado y ordenamiento NO pueden utilizar

Únicos Endpoints/Flags que pueden utilizar

A continuación se detallaran los requerimientos mínimos para la aprobación del

IMPORTANTE: No se permitirá utilizar librerías externas para aplicar estilos a la

Se debe desarrollar una aplicación de React/Redux que contenga las siguientes

Pagina inicial: deben armar una landing page con