Creación de Microservicios para Bases de Datos con Node.js
Resumen
¿Cómo crear un microservicio para la base de datos?
¡Explora el mundo de los microservicios y descubre cómo estructurar tus aplicaciones de forma eficiente y modular! Un microservicio puede mejorar la flexibilidad de tu sistema, permitiéndote manejar diferentes aplicaciones que interactúan con la misma base de datos desde distintos lenguajes de programación como Python. Aprenderás a crear un sistema de clasificación usando Machine Learning para recopilar y actualizar datos en tiempo real.
¿Cómo crear una estructura para el microservicio?
Para comenzar, asegúrate de que tu aplicación esté lista para la modularización. Empieza creando una nueva carpeta para el microservicio de base de datos, llamémosla mysql. En esta carpeta, crea un archivo index.js donde definirás tu API y establecerás cómo se comunicará. A continuación, se muestra un ejemplo de cómo podrías hacerlo usando Express en Node.js:
const express =require('express');const bodyParser =require('body-parser');const config =require('../config');const app =express();app.use(bodyParser.json());app.listen(config.mysqlService.port,()=>{console.log(`Servicio MySQL escuchando en el puerto ${config.mysqlService.port}`);});
¿Cómo definir las rutas y funciones necesarias?
Para manejar las operaciones de base de datos, necesitarás definir rutas específicas que correspondan a las acciones que deseas realizar, como listar, obtener, insertar y actualizar registros. A continuación, se muestra cómo podrías definir estas rutas:
const router =require('express').Router();router.get('/:table', list);router.get('/:table/:id', get);router.post('/:table', insert);router.put('/:table/:id', update);functionlist(req, res, next){const data =await store.list(req.params.table); res.json(data);}functionget(req, res, next){const data =await store.get(req.params.table, req.params.id); res.json(data);}functioninsert(req, res, next){const data =await store.insert(req.params.table, req.body); res.json(data);}functionupdate(req, res, next){const data =await store.update(req.params.table, req.params.id, req.body); res.json(data);}module.exports= router;
¿Cómo probar el microservicio?
La mejor forma de asegurarte de que tu nuevo microservicio funciona correctamente es probándolo. Puedes usar herramientas como Postman o cURL para enviar solicitudes HTTP a tu microservicio y ver si responde de la forma esperada. A continuación, se muestra cómo podrías realizar una prueba simple:
curl http://localhost:3001/user
Este comando debería devolver la lista de usuarios en la base de datos. Si no, asegúrate de que las rutas y el almacen (store) estén correctamente configurados.
Una recomendación para tu arquitectura de microservicios
En una arquitectura de microservicios eficiente, no todos los servicios deben estar expuestos al público. Considera mantener este servicio de base de datos como un servicio interno donde solo las aplicaciones necesarias tengan acceso directo. Esto mejora la seguridad y la integridad de los datos.
Los microservicios bien diseñados y estructurados son una parte vital de aplicaciones escalables y flexibles. ¡Sigue explorando y mejorando tu arquitectura para lograr un sistema más robusto y eficiente!
Un microservicio es una pequeña aplicación que se encarga de una parte de un software más complejo de manera aislada, y se comunica con el resto del software mediante diferentes métodos: peticiones HTTP, o algún sistema de colas. micro.js es una librería muy pequeña (alrededor de 100 líneas de código) de JavaScript, que nos permite usar Node.js para crear fácilmente microservicios que funcionen sobre el protocolo HTTP, y haciendo uso de Async/Await y todas las características que se incluyeron en ECMAScript 2015 para facilitarnos el programarlos.
:thumbsup:
Gran aporte, me lo llevaré a mis apuntes :D
Una barbaridad lo que se aprende en cada curso con el profe Carlos
Sí, son de los cursos con los que más aprendo. Uno de estos son como 2-3 cursos de otros profesores.
Primera vez que veo los Microservicios lo que vi lo entendi, seguimos.!!
de verdad que claro me esta quedando esto de los microservicios
I N C R E I B L E !!!!! :o
En un caso real, si necesitamos desarrollar microservicios, es recomendable crear los microservicios dentro de un mismo proyecto de código o lo mejor seria separarlos y que cada microservicio sea un proyecto/repositorio separado.?
Cada opción tiene sus ventajas y desventajas, todo depende de muchos factores: del proyecto, de la forma de trabajar del equipo, de las restricciones del cliente etc.
Aquí las ventajas de cada uno:
Ventajas múltiples repositorios
Un CodeBase más pequeño.
CI/CD más sencillos de integrar.
Ownership claro.
Ventajas un sólo repositorio
Fácil de depurar y de encontrar errores.
Fácil integración de los diferentes equipos.
Facilidad para compartir y reutilizar código en común.
Entre muchas otras.
wooo creo que esto es complicado, más porque el profe no esta usando un metodología estructurada de trabajo como lo es MVC. Se que ese modelo no aplicaría para APIs pero creo que es complicado seguirle el hilo he ir entendiendo todo!
MVC es un patrón de diseño de arquitectura, como lo es la arquitectura a base de componentes, como lo es la arquitectura basada en micro-servicios.
Puedes aplicar MVC en tus micro-servicios, no son patrones de diseño que se estorban.
Algo me dice que aquí se pueden hacer ataques de inyección de SQL y que deberíamos validar los datos antes de guardarlos en la base de datos.
Separando la base de datos a un microservicio
Creamos ./mysql/index.js:
const express =require("express");const app =express();const config =require('../config')const router =require('./network')app.use(express.urlencoded({extended:true}))app.use(express.json())//* RUTASapp.use('/', router)app.listen(config.mysqlService.port,()=>{console.log(`Servidor MySQL escuchando en el puerto ${config.mysqlService.port}`);})
Ahora si hacemos GET https://localhost:3001/post o GET https://localhost:3001/user obtendremos la información de la base de datos.
Cada microservicio no deberia tener su propia conexion a la base de datos ?
Al contrario, se menciona que el microservicio de posts todavía sigue utilizando la base de datos en la que ya estaba trabajando la API principal.
Tengo una duda , esta bien visto o es buena practica tener mi server en node con ES6 y tener babel para transpilar y luego levantar el server que transpila babel ?? o es considerada buena practica escribir ES5 para node siempre y levantar desde ahi
Yo prefiero escribir en ES6 y transpilar, Babel hace un muy buen trabajo y no te dá prácticamente ninguna desventaja en performance. Mientras que ES6 te da ventaja en legibilidad del código, algo muy importante a la hora de debuggear :D
Entonces esto viene a ser como una envoltura de una api para de cierto modo poder homologar un servicio y cumplir con un tipo de manifiesto en caso que en vez de mysql digamos uso postgress ?
Sí, al separar los servicios en microservicios, se puede utilizar diferentes bases de datos como MySQL o PostgreSQL para cada servicio, cumpliendo con los requisitos específicos de cada uno.
Pregunta: ¿No se supone que cada Microservicio tiene que ser independiente? Pues aquí si se cae el Microservicio de la Base de Datos se cae todo el Sistema. ¿O estoy mal?
Estás en lo correcto. En este caso, si el microservicio de la base de datos se cae, todo el sistema se verá afectado. Esto no cumple con el principio de independencia de los microservicios.
Mi pregunta radica en el rendimiento.
A la hora de hacer opetaciones muy pesadas como la creacion de una gran cantidad de el elementos que estan relacionados con otras tablas.
No estamos añadiendo una capa de complejidad atraves de http que aumentara los costes de transferencia de informacion que adicionalmente los drivers de la base de datos ya manejan muy bien ?
Te sale preocuparte por performance cuando estás escalando miles de millones de datos; si estás escalando miles de millones de datos ¿Por qué chucha tienes un endpoint que te tira una consulta, una query, llámalo como quieras; para la que la BD no está preparada?
Si tienes un problema de rendimiento por X o Y el problema no radica en el código (Al 100%), radica (En buena medida) en la razón detrás de ese downgrade en el performance de tu aplicación.
Ejemplo, tienes un app que te permite subir y gestionar archivos; si subes 7 archivos de 7 GB eso tarda un buen rato dependiendo del wifi ¿Verdad? El usuario en ese caso tiene 2 cosas a tomar en cuenta ¿Por qué está subiendo un archivo que pesa más que el instalador de Windows? Eso se podría resolver con restricciones en los términos y condiciones; si tiene que a huevo subir un archivo tan pesado, lo que nosotros en frontend hacemos y mandar eso a un proceso secundaría que cuando termina notifica, el backend de manera similar debe poder hacer eso así no se percibe un gran problema en la carga; en la parte de lectura mucho de eso se solventa con paginadores y demás, en general soltar grandes paredes de texto, imágenes, etc. De una consulta larguísima a la BD no se hace, no lo hace Facebook, ni Instagram, ni siquiera Drive, tampoco Google, nadie lee eso, más de 2 o 3 cosas en la pantalla por vez es engorroso, por lo que las consultas son más atómicas, eso baja la latencia; inclusive puedes ver eso en el mismo Platzi, acá solo se te carga 1 video y ya; no necesitas tenerlos todos al tiempo y así aplica para casi todo
Me gusta los cursos donde los profesores tienen errores y muestran donde estuvo ese error y como lo solucionan, algunos solo hacen el corte y dicen que tuvieron un error y ya lo corrigieron. Deberian hacerlo mostrando como solucionan sus propios errores.
Es implementación es interesante, pero por favor el naming ya no se entiende nada; hay demasiadas cosas llamadas "network" :cr
Algo que me gustaría agregar a esta clase es que los errores del network.js de mysql deberían ser manejados, aún no comprendo bien para que sirve la función next así que mi código quedó así: