{"id":248001,"date":"2023-09-01T19:36:53","date_gmt":"2023-09-01T19:36:53","guid":{"rendered":"https:\/\/distillery.com\/simba-js-la-forma-mas-sencilla-de-poner-en-marcha-sus-api-de-ts\/"},"modified":"2023-11-15T15:02:18","modified_gmt":"2023-11-15T15:02:18","slug":"simba-js-la-forma-mas-sencilla-de-poner-en-marcha-sus-api-de-ts","status":"publish","type":"post","link":"https:\/\/distillery.com\/es\/blog\/simba-js-la-forma-mas-sencilla-de-poner-en-marcha-sus-api-de-ts\/","title":{"rendered":"Simba.js: la forma m\u00e1s f\u00e1cil de poner en marcha tus APIs de TypeScript"},"content":{"rendered":"

Esta es la primera parte de una serie de entradas en las que tratar\u00e9 ideas generales relacionadas con Simba.js<\/strong>. Abarcan sus escenarios de utilizaci\u00f3n, aplicaciones potenciales, consideraciones asociadas, recomendaciones, etc.<\/span> \u00bfOtra biblioteca\/marco JS? <\/span><\/p>\n

Respuesta corta: s\u00ed. Respuesta larga, bueno…<\/span><\/p>\n

\"\"<\/p>\n

Si eres como yo, puede que est\u00e9s realmente molesto cada vez que quieres iniciar una nueva API JS\/TS. La mayor\u00eda de las veces, tienes que configurar las mismas cosas una y otra vez, creando un tsconfig.json, .eslintrc, LICENSE, jest.config.js\/ts, Dockerfile, y muchos m\u00e1s dependiendo de lo complejo que sea tu proyecto. <\/span><\/p>\n

All\u00e1 por 2021, cuando acababa de empezar a programar (ten\u00eda un a\u00f1o de experiencia m\u00e1s o menos), decid\u00ed que no quer\u00eda volver a hacer eso, as\u00ed que cre\u00e9 una herramienta CLI para ayudarme a hacer todos los archivos configs y evitar el estr\u00e9s de crearlos manualmente una y otra vez. Esa herramienta era muy \u00fatil los d\u00edas que no ten\u00eda que crear nada manualmente, pero no me bastaba. \u00bfPor qu\u00e9? Porque cuando creas una API (al menos una API RESTFul) la mayor\u00eda de las cosas que haces suelen ser las mismas.<\/span><\/p>\n

Usted tiene que configurar su servidor, a continuaci\u00f3n, su base de datos, a continuaci\u00f3n, a\u00f1adir algunas cosas en el medio para manejar su l\u00f3gica de negocio – vamos a llamarlo “servicios” – y, finalmente, a\u00f1adir algunas rutas – “controladores” – para exponer su l\u00f3gica de negocio a trav\u00e9s de algunos puntos finales. Una vez que llegues a ese punto, probablemente necesites a\u00f1adir alg\u00fan tipo de validaci\u00f3n entre la petici\u00f3n que recibes y la l\u00f3gica que tienes en tus controladores, as\u00ed que puede que acabes a\u00f1adiendo algunos esquemas para validar si la petici\u00f3n que envi\u00f3 un usuario era correcta, etc. <\/span><\/p>\n

Como puedes ver, crear una API RESTFul JS\/TS suele ser un proceso muy repetitivo. As\u00ed que empec\u00e9 a trabajar para crear algo que evitara este proceso. <\/span><\/p>\n

Me inspir\u00e9 en muchos sitios. Durante ese tiempo, sol\u00edamos construir SPA con <\/span>CRA <\/span><\/a>, y fue divertido. CRA te daba la mayor\u00eda de las herramientas que necesitabas para empezar a crear tu propia aplicaci\u00f3n, pero eso era para el frontend. \u00bfY el backend? Recuerdo que no ten\u00edamos algo como CRA, pero ten\u00edamos marcos completos populares como <\/span>NestJS<\/span><\/a> o <\/span>SailsJS<\/span><\/a>,<\/span> as\u00ed como frameworks populares muy comentados (o no) como <\/span>Express<\/span><\/a>, <\/span>koa<\/span><\/a> o <\/span>Fastify<\/span><\/a><\/p>\n

As\u00ed es como me vino a la cabeza la idea de Simba.js<\/strong> (a\u00fan no ten\u00eda el nombre). Quer\u00eda una herramienta que me diera un punto de partida, as\u00ed que ten\u00eda que escribir consultas, controladores o servicios a mano, pero s\u00f3lo ten\u00eda que seguir el esqueleto para que funcionara. Necesitaba algo que no pareciera magia (lo siento, Nest) en lo que s\u00f3lo tienes que importar algo y ya est\u00e1, pero tampoco quer\u00eda reinventar la rueda. <\/span><\/p>\n

Estaba listo, constru\u00ed una herramienta CLI que me permit\u00eda, con unas pocas pulsaciones de teclas, crear un peque\u00f1o boilerplate con toda la configuraci\u00f3n hecha y una API RESTFul completamente funcional, pero faltaba el nombre, y entonces me vino la idea a la cabeza. Le puse a mi framework\/biblioteca el nombre de mi gato, Simba, la criatura m\u00e1s perezosa que he conocido. Pero as\u00ed es. \u00bfPor qu\u00e9? Porque no quiero volver a crear una API RESTFul desde cero.<\/span><\/p>\n

\"\"<\/p>\n

El objetivo de Simba.js es estandarizar la forma de crear API RESTFul. De hecho, ese era el objetivo. Hoy en d\u00eda, tambi\u00e9n quiero estandarizar la forma en que construimos API GraphQL. Digamos que Simba.js pretende convertirse en la forma est\u00e1ndar de crear APIs de TS. <\/span><\/p>\n

Por supuesto, Simba.js es muy criticable. Eleg\u00ed los frameworks de backend que me gustaban (y tambi\u00e9n muy populares): Express y Fastify, y tambi\u00e9n las herramientas que me gustaban en ese momento, que eran Joi y Mongoose (actualmente no soportadas) y algunas otras. Tambi\u00e9n eleg\u00ed el <\/span> eslint<\/span> <\/a> y prettier<\/a><\/span>\u00a0config que me gustaba, el marco de pruebas, etc.<\/span> Eleg\u00ed estas herramientas bas\u00e1ndome en mi propia experiencia porque funcionan muy bien juntas y era f\u00e1cil combinarlas de forma reutilizable. Tambi\u00e9n creo que este es un excelente punto de partida. Una vez que Simba.js te proporciona el boilerplate, es bastante f\u00e1cil manipularlo y escalar la aplicaci\u00f3n en funci\u00f3n de tus necesidades. Adem\u00e1s, Simba.js te ofrece muchas herramientas para que puedas construir tu propia API. Puedes elegir: <\/span><\/p>\n