🚌servicios FTW 💪🏼

README.md

🚌servicios FTW 💪🏼

🗣 @durancristhian 🏢 @acamica_com

3 temas principales 🤓

• 🚌servicios como arquitectura
• 🚌servicio como componente
• implementación en Node.js

🚌servicios como arquitectura

• Manera particular de desarrollar aplicaciones (Patrón)
• Colección de servicios independientes
• Implementan una pequeña porción de tu lógica de negocio
• No hay una definición precisa, pero si hay características comunes

🚌servicios como unidad

• Uno o pocos endpoints que atacan una parte de tu app
• Puede comunicarse con otros y compartir recursos (como una base de datos)

Hablame de un caso real

[http://meetupjs.com.ar/calendario.html](Calendario de eventos)

                                 ===> SPREADSHEET_API

meetupjs.com.ar ===> CALENDAR_API ===> EVENTBRITE_API ===> MEETUP_API

¿Por qué creo que esto está bueno? ✅

• Siempre hay partes que se pueden desacoplar
• Solución enfocada en resolver tu problema
• Favorece la exploración de nuevos rumbos (paquetes, versión de Node, settings)
• Tu app deja de ser un monolito para ser una composición de servicios
• No estás atado a 1 stack 👌🏼
• Backend al toque, 🐕

¿Por qué creo que esto NO está bueno? ❌

• Es difícil conocer el estado de tu app, porque cada servicio tiene su versión
• Si compartís la base de datos más vale que sepas lo que estás haciendo 😂😂😂😂😂
• Al no haber reglas precisas sobre que es y que no es tenés la chance de agregar mucho ruido ⚠️
• La estrategia de comunicación siempre la tenés que definir vos (and good luck with that)
• Redundancia de cosas simples (errores, estándares, etc.)

Escribamos uno 😎

Usemos micro y now para construir un ejemplo simple

Un poco más? 🤓

• https://github.com/mfornos/awesome-microservices
• https://github.com/zeit/awesome-zeit
• https://github.com/amio/awesome-micro
• https://github.com/meetupjs-ar/calendar-bot
• https://github.com/meetupjs-ar/