Datos 2
Last Update：16/09/2024
Esta documentación provee una vista completa a la aplicación DARE, su crecimiento y evolución desde una página funcional con una base de datos SQL a ser una webapp que funciona sobre una base de datos noSQL.
Como usuario, quiero tener una red social donde pueda involucrarme más en la vida de las otras personas, escogiendo de cuatro desafios diarios que puedo completar. Estos desafios también los tendrán las otras personas y todos deberemos escoger uno de esos 4. Los desafios serán divididos por categorías. Para asegurar que se completó el desafio hay que subir una foto haciendolo.
La pagina web actúa como una red social que empuja a sus usuarios a involucrarse y crear contenido en vez de solamente consumirlo. Cada día todos los usuarios serán sorprendidos con 4 diferentes desafíos de los cuales deberán escoger 1 para completarlo y subir la prueba de que lo hicieron. Los demás usuarios calificarán este post del 1 al 5, lo que que funcionará como peer review para saber si el usuario completo bien el reto o no. Si la calificación promedio es mayor a 2.5, entonces el usuario obtendrá los puntos de ese dasafío y se mostrarán en su perfíl.
La estructura del backend hasta este primer periodo estaba estructurado de la siguiente manera:
server/ ├── middlewares/ ├── models/ ├── routes/ ├── uploads/ └── index.js
Base de datos y los modelos utilizados para la webapp
Esta ruta permite obtener una etiqueta específica de la base de datos, usando su ID como parámetro. Si se encuentra la etiqueta, devuelve sus datos en formato JSON; si no se encuentra, responde con un error 404. En caso de error en el servidor, responde con un código 500.
javascript
Copy code
// Ruta para obtener una etiqueta por su ID
router.get("/:id", async (req, res) => {
try {
const id = req.params.id;
const tag = await Tags.findByPk(id);
if (tag) {
res.json(tag); // Devuelve la etiqueta si se encuentra
} else {
res.status(404).json({ error: "Etiqueta no encontrada" }); // Error 404 si no existe
}
} catch (error) {
console.error("Error al buscar etiqueta por ID", error);
res.status(500).json({ error: "Error interno del servidor" }); // Error 500 en caso de fallo del servidor
}
});
Endpoint: GET /tags/:id
id (obligatorio): El ID de la etiqueta que se desea obtener.Este es solamente un ejemplo de las rutas y su estado para esta fase. Como podemos observar, solo habia ruta y no estaba desglosado entre servicios, controladores o repositorios.
json
Copy code
{
"id": 1,
"tagName": "EjemploEtiqueta",
"createdAt": "2023-01-01T00:00:00.000Z",
"updatedAt": "2023-01-02T00:00:00.000Z"
}
GET /comments/:postId - Obtener todos los comentarios de una publicación específica.
/comments - Crear un comentario en una publicación./comments/delete/:commentId - Eliminar un comentario/dares/random - Obtener 4 desafios aleatorios./dares/:id - Obtener un dare por su id./posts - Obtener todas las publicaciones./posts/byId/:id - Obtener una publicación específica por ID./posts/byDare/:id - Obtener todas las publicaciones de un Dare especifico/posts/byTag/:id - Obtener Todas las publicaciones con un tag especifico./posts/byUser/:id - Obtener todas las publicaciones de un usuario/posts - Crear una nueva publicación./posts/:id - Eliminar una publicación específica./ratings - Calificar o actualizar la calificación de un post./ratings - Obtener la calificación pasada del usuario para todos los posts./ratings/:postId - Obtener la calificación del usuario para un post especifico./tags/:id - Obtener una etiqueta específica por ID./auth/ - Registrar un nuevo usuario./auth/login - Iniciar sesión./auth/check - verifica el token/auth/login - obtener informacion basica del usuarioCambio de estructura en backend e implementación de cache
server/ ├── controllers/ ├── middlewares/ ├── models/ ├── repositories/ ├── routes/
├── services/ ├── uploads/ └── index.js
Como podemos observar, las pruebas de estrés muestran una disminución en el tiempo de respuesta de las llamadas en los APIs al implementar cache e incluso aún mayor disminución al mover la base de datos de SQL a noSQL. Como podemos ver, en las pruebas de estrés es una reducción de un poco más del 50% cuando se usa mongo y el cache a comparación del normal. En todos los datos que tenemos, vemos que al implementar el cache, tenemos una reducción del tiempo de respuesta, que es muy bueno.
Un buen throughput significa que el sistema puede procesar una alta cantidad de solicitudes por unidad de tiempo de manera eficiente, manteniendo un rendimiento óptimo bajo la carga esperada. Podemos observar en las gráficas que el throughput comienza en 3,400,000/min a 4,000,000/min al implementar cache, hasta finalmente llegar a 6,200,000 con la implementación de una base de datos noSQL encima del cache con redis.