Cuando trabajamos con bases de datos, especialmente en aplicaciones que manejan información dinámica como resultados deportivos, es fundamental anticipar que pueden surgir errores. Por eso, siempre debemos envolver nuestras consultas en bloques try para capturar cualquier excepción que pueda ocurrir y responder adecuadamente. Por ejemplo, si al intentar obtener datos de equipos o resultados algo falla, lo prudente es devolver un código HTTP 400 junto con un mensaje JSON que explique el error, para que la aplicación cliente pueda manejarlo correctamente.
Una vez asegurada esta gestión de errores, podemos centrarnos en la consulta de datos. Supongamos que queremos obtener los nombres de dos equipos específicos. Para ello, podemos hacer algo así:
try {
const team1 = await getClub(req.params.equipo1);
const team2 = await getClub(req.params.equipo2);
res.json({ team1: team1.name, team2: team2.name });
} catch (e) {
res.status(400).json({ error: e.message });
}
Con este código, si todo va bien, devolvemos solo los nombres de los equipos solicitados, evitando enviar información innecesaria que pueda confundir o sobrecargar la respuesta. Es importante ajustar la consulta para que la base de datos nos devuelva únicamente el campo name del club, simplificando así la respuesta.
Además de los nombres, es interesante mostrar la fecha en la que se juega un partido entre esos equipos. Para ello, podemos consultar el resultado asociado y extraer la fecha del encuentro. Si el partido ya se ha disputado, también podemos devolver el marcador final. La lógica sería algo así:
try {
const match = await getMatch(req.params.equipo1, req.params.equipo2);
if (match.score) {
res.json({
date: match.date,
score: {
[req.params.equipo1]: match.score.ft[0],
[req.params.equipo2]: match.score.ft[1]
}
});
} else {
res.json({ date: match.date, message: "El partido se jugará en el futuro" });
}
} catch (e) {
res.status(400).json({ error: e.message });
}
Con este enfoque, si el partido ya tiene un marcador registrado, lo mostramos junto con la fecha. Si no, indicamos que el encuentro está programado para una fecha futura.
También es importante manejar correctamente los casos en los que se solicitan equipos que no existen en la base de datos. Por ejemplo, si pedimos un equipo con un identificador erróneo, debemos asegurarnos de que el error que devolvemos sea claro y útil. Para ello, capturamos el mensaje de error y lo enviamos en la respuesta con un código 400, como en el ejemplo anterior.
Este tipo de manejo robusto de datos y errores nos permite construir APIs claras y confiables para aplicaciones deportivas, donde los usuarios pueden consultar información precisa sobre equipos, fechas y resultados sin sorpresas ni datos confusos. Además, mantener el código modular y bien estructurado facilita futuras ampliaciones, como añadir nuevas temporadas o incluir más detalles en las respuestas.
Por último, es recomendable mantener el código bajo control de versiones, haciendo commits frecuentes para no perder avances y poder retomar o extender funcionalidades en el futuro con facilidad. Así, si en algún momento queremos añadir más ejemplos o funcionalidades, tendremos una base sólida sobre la que trabajar.