Construyendo y Operando un Monolito Componible Moderno

Rate this content
Bookmark

Todo comenzó con la fisión del monolito en microservicios. Esto estableció límites lógicos y físicos, fusionando las dimensiones de infraestructura y software. Si bien los microservicios simplificaron cómo los equipos desarrollan de forma independiente, agregaron complejidades adicionales en torno al rendimiento, la corrección, la gestión general y, en última instancia, un ciclo de desarrollo más lento. En esta charla, profundizaremos en cómo diseñar e implementar un monolito componible basado en Fastify, la comunicación sin red entre servicios y cómo manejar un desarrollo eficiente entre equipos al implementar un único artefacto en Kubernetes. ¿Suena como magia? ¡Descubramos el truco juntos!

19 min
15 Feb, 2024

Video Summary and Transcription

En esta charla, Luca introduce el concepto del monolito componible moderno y discute los desafíos de los microservicios. Él enfatiza la importancia de desarrollar monolitos modulares e introduce Fastify y la Plataforma de Ejecución como herramientas para este enfoque. La Plataforma de Ejecución simplifica la ejecución de aplicaciones modulares y monolíticas, y la estandarización de interfaces y comunicación es crucial en este contexto. Por último, Luca presenta Meraki como una herramienta basada en interfaz de usuario para construir monolitos componibles e invita a los desarrolladores a unirse a su mercado para revolucionar la experiencia operativa de los microservicios.

Available in English

1. Introducción al Monolito Componible Moderno

Short description:

Hola a todos, soy Luca, cofundador y CEO de Platformatic. Hoy tenemos microservicios, pero ¿hacia dónde nos lleva el futuro? En esta charla, intentaré despertar su curiosidad sobre un nuevo concepto y mostrarles un adelanto de algunos de los materiales que ya hemos construido en Platformatic sobre este tema. Los microservicios unen los límites lógicos con los límites físicos, lo que implica una transformación tecnológica, cultural y de personas. Ofrecen un impulso de rendimiento increíble y una mayor tolerancia a fallos, pero afectan el rendimiento y dificultan la corrección.

Hola a todos, estoy muy emocionado de estar aquí en JS Nation hoy y llevarlos en un viaje, el viaje del monolito componible moderno. Permítanme comenzar presentándome, soy Luca, cofundador y CEO de Platformatic, y junto con mi amigo Matteo Collina y nuestro increíble equipo, tenemos la misión de cambiar completamente el mundo de la construcción de aplicaciones Node.js en la época moderna.

Pueden conectarse conmigo, por favor háganlo en cualquier red social y pueden encontrarme como Luca Maraschi, estoy emocionado de conectarme con ustedes. Pero comencemos con nuestro viaje. Mi abuela Piera siempre me decía que la vida es como una rueda giratoria y en ese momento, créanme, no lo entendía. Pero hoy quiero mostrarles y demostrarles que ella tenía razón. Comencemos.

Como toda historia que hemos escuchado en los últimos años, especialmente en Node, es que una vez hubo un monolito y ahora microservicios. Bueno, hoy, comencemos desde donde dejamos la historia. Hoy tenemos microservicios, pero ¿hacia dónde nos lleva el futuro? En esta charla, intentaré despertar su curiosidad sobre un nuevo concepto, pero especialmente mostrarles un adelanto de algunos de los materiales que ya hemos construido en Platformatic sobre este tema y conectarnos directamente para hacer cualquier pregunta.

Pero comencemos desde donde terminó y se dejó sobre los microservicios. Entonces, los microservicios, unen los límites lógicos con los límites físicos. Y ¿qué significa eso? Básicamente, no solo son una transformación tecnológica, sino también una transformación cultural y una transformación de personas, como decimos en cualquier organización. Siempre que pensamos en Microsoft, pensamos en todos estos hexágonos, ¿verdad? Siendo compuestos entre sí y luego siendo estandarizados en APIs. Porque estamos en la era de las APIs modernas y de la economía de las APIs, como dicen mis amigos de Kong. Y estoy de acuerdo con ellos.

Estamos en medio de la economía de las APIs. Y por un lado, hemos sido extremadamente capaces y motivados por cambiar el mundo de las APIs. Sin embargo, nos hemos estancado un poco en cómo construimos la lógica que respalda todas estas APIs. El núcleo del negocio de todos. Y así, los microservicios por un lado ofrecieron un impulso de rendimiento increíble, ¿verdad? Porque podemos escalar de forma independiente, pensamos en partículas micro de la lógica empresarial de una manera mucho más aislada, ¿verdad? Se volvieron más tolerantes a fallos porque no tenemos estas transacciones enormes que están unificadas en un solo conjunto de lógica empresarial, sino que se distribuyen en varios nodos. Y si un nodo se cae, podemos restaurarlo porque nos dijeron que deben ser sin estado. Así que comenzamos a crear estos límites de abstracción. Creamos esta fachada que nos permite intercambiar las diferentes implementaciones del servicio sin interrumpir a los clientes, ¿verdad? Y esto suena extremadamente emocionante y positivo. Sin embargo, en toda buena historia hay un sin embargo, ya saben, ¿verdad? Esto realmente afectó el rendimiento porque ahora tienes muchos servicios que imaginemos en Kubernetes o en cualquier otro sistema, básicamente se distribuyen en varios nodos y estos nodos necesitan comunicarse. Y cómo se comunican se llama red, ¿verdad? Por otro lado, la corrección se volvió mucho más difícil. Es un sistema distribuido. Es muy difícil gestionar un estado consistente en todos estos servicios diferentes. Y especialmente cuando digo estado, me refiero a estado lógico y estado físico. ¿Está todo igualmente distribuido? ¿Todo se está desarrollando de la misma manera? Y guarden este concepto para más adelante.

2. Desafíos de los Microservicios y el Momento Eureka

Short description:

Se vuelven extremadamente difíciles de gestionar porque son como un sistema distribuido. Impacta directamente a los desarrolladores, ralentizando el ciclo de desarrollo y generando frustraciones. Acoplamos nuestra lógica de aplicación a la estructura de red, lo que dificulta desenredarla. La solución es mirar hacia atrás al monolito componible, un concepto no nuevo pero respaldado por Google en un documento técnico.

Se vuelven extremadamente difíciles de gestionar porque acabamos de decirlo, ¿verdad? Son como un sistema distribuido. Todos se desarrollan, implementan y gestionan de forma independiente, ¿verdad? Esto causa un gran bloqueo en las APIs, ¿verdad? Porque como dijimos antes, las APIs son la agregación de todos estos microservicios. Al final del día, esto impacta directamente a los desarrolladores. Ralentiza el ciclo de desarrollo y añade frustraciones porque hay más barreras que superar antes de que podamos llevar nuestros microservicios a producción.

Pero diría aún más, acoplamos nuestra lógica de aplicación, nuestras aplicaciones, a la estructura de red con una taxonomía de red, y esto se vuelve extremadamente difícil de desenredar. También complica mucho la versión porque los binarios de la aplicación se lanzan de forma independiente. Cada microservicio tiene su propio ciclo de vida. ¿Alguna vez te has preguntado qué versión debería tener este servicio? Esa es una muy buena pregunta. Pero hubo un momento de revelación. Hubo un momento en el que dijimos, hmm, vimos la luz. Y ese fue el momento del monolito componible.

Entonces, ¿cuál es la solución a todos estos problemas? Bueno, probablemente sea mirar hacia atrás y ver dónde comenzamos, ¿verdad? Todos comenzamos criticando y diciendo que el monolito representaba a Java y .NET, ¿verdad? Y al final, si todos recuerdan, esas tecnologías se implementaban como un paquete que se transfería mediante SFTP a un servidor de aplicaciones. Y funcionaba, ¿verdad? Pero lo que realmente no encajaba era el modelo de desarrollo, cómo se creaba este paquete. Este no es un concepto nuevo, ¿verdad? Y no soy el primero. No estamos locos al hablar de este monolito componible. Pero Google escribió un documento técnico diciendo que el futuro del desarrollo moderno en la nube está con un monolito componible. Este es el documento técnico. Recomiendo encarecidamente que lo descarguen y lo lean. Es un documento fenomenal. Personalmente, creo que ofrece una visión fenomenal de las formas modernas de interpretar el desarrollo de software.

3. Puntos Clave en el Desarrollo de Monolitos Modulares

Short description:

El primer punto es escribir aplicaciones monolíticas que estén modularizadas en componentes. El segundo punto es aprovechar un tiempo de ejecución que pueda asignar componentes lógicos a recursos físicos. Implementar aplicaciones de forma atómica, lo que permite una versión y consumo más fácil. Esto abre muchas puertas y ya existen frameworks en el ecosistema Node.

Permítanme elegir tres puntos importantes de toda esta historia. Bueno, el primero es básicamente escribir aplicaciones monolíticas que estén modularizadas en componentes. Así que aprendemos el concepto de componentes, ¿verdad? Desde el frontend, si piensas en React, y esto fue fenomenal porque cada componente tiene su propia lógica, su propio alcance. Pero todos se agruparon en un solo despliegue. Y eso fue el sitio web, ¿verdad?

El otro punto es aprovechar un runtime que básicamente pueda asignar dinámica y automáticamente componentes lógicos a recursos físicos, lo que significa básicamente tomar este monolito, este monolito componible basado en componentes, y asignar recursos a cada componente para que estos componentes puedan ejecutarse como si fueran independientes. Pero implementar aplicaciones de forma atómica, sin despliegues independientes. Un solo despliegue monolítico, un gran paquete. Porque esto realmente conducirá a una forma mucho más fácil de versionar y consumir esta versión. Creo que esto abre muchas, muchas puertas, ¿verdad? Y si piensas en Node, en el ecosistema Node, ya existen frameworks.

4. Fastify y el tiempo de ejecución de Platformatic

Short description:

Fastify es la solución elegante para desarrollar aplicaciones de esta nueva manera. Platformatic ha construido un tiempo de ejecución, de código abierto durante los últimos seis meses, que permite ejecutar componentes independientes como una sola pieza. Se recomienda probar el tiempo de ejecución de Platformatic.

Y no menciono Fastify solo porque me encante Fastify, sino porque creo que representa de manera elegante la solución, probablemente la única solución, para esta nueva forma de desarrollar aplicaciones. No se puede hacer con Express. Se puede hacer, pero es feo. Y muchos otros frameworks lo intentaron, pero Fastify logró unir todos estos conceptos de manera elegante. En Platformatic, amamos claramente Fastify, y dijimos que necesitábamos construir un tiempo de ejecución que hiciera exactamente lo que Google sugería, tomar todos estos componentes independientes y ejecutarlos como si fueran una sola pieza. Pero digamos que lo intentamos varias veces, solo para usar una declaración provocativa. Y así construimos el tiempo de ejecución de Platformatic y ya está disponible como código abierto desde hace seis meses. Así que por favor, úsalo.

5. Solving Complexity with Platformatic Runtime

Short description:

El tiempo de ejecución de Platformatic simplifica la complejidad de ejecutar aplicaciones modulares y monolíticas. Fastify está diseñado en torno al concepto de complementos y rutas, lo que permite crear un monolito componible bien estructurado. Platformatic lleva este enfoque aún más lejos, proporcionando una solución fácil de usar. npm i platformatic para comenzar.

Y lo que estamos tratando de resolver con el tiempo de ejecución de Platformatic es la complejidad de ejecutar aplicaciones modulares y monolíticas, donde cada módulo representa una única característica desplegada bajo un solo paquete, desarrollada de forma independiente por muchas personas, como pueden ser 10 equipos que desarrollan esta cosa, pero al final va a un solo contenedor. Y el tiempo de ejecución de Platformatic te ofrece la interfaz HTTP y el punto de entrada a todo esto, además de la gestión de ejecutar todos estos componentes como hilos independientes. Así que cuando damos la bienvenida a los monolitos modulares y vemos cómo podemos hacerlo en Node, mencioné hace un minuto a Fastify. Fastify fue diseñado en torno a este concepto. Complementos, rutas, puedes agrupar tu complemento que contiene rutas y luego puedes tomar una sola aplicación Fastify que utiliza todos estos complementos independientes. Y la determinación en nuestro trato, por ejemplo, es capaz de cargar de manera determinista todos estos complementos, lo que te permite crear este monolito componible muy bien organizado y estructurado.

Y como mencioné, Fastify es nuestro marco HTTP, tienes todos estos complementos que pueden ser paquetes npm o simplemente archivos individuales en un solo proyecto, realmente no importa. Pero esta es una especie de vista macroscópica de cómo puedes lograrlo. Así que la solución ya está ahí. En verdad, hay que decir que en Platformatic llevamos este enfoque al siguiente paso lógico, te recomiendo encarecidamente que vayas y compruebes Platformatic, muy fácil de hacer, npm i platformatic y tendrás todo listo para usar en tu

6. Standardizing Interfaces and Communication

Short description:

Los módulos en un sistema monolítico modular necesitan comunicarse entre sí a través de interfaces débilmente referenciadas y débilmente acopladas. TypeScript no es la solución recomendada. El RFC 9110 explica cómo la división semántica entre los protocolos HTTP 1 y 2 hace que el enlace sea débilmente acoplado. El cofundador Matteo habla sobre cómo lograr un rendimiento entre módulos utilizando HTTP sin red en una charla en NodeConf EU. Los módulos en nuestro tiempo de ejecución de Platformatic se comunican a través de HTTP sin utilizar ninguna red.

máquina. Pero el problema principal de un sistema monolítico modular es estandarizar las interfaces entre los módulos, ¿verdad? Porque ahora tengo todos estos módulos, pero ¿cómo se comunican entre sí? No puedes referenciarlos fuertemente o de lo contrario se enredarán. Así que necesitan ser débilmente referenciados, débilmente acoplados. Pero, ¿qué tipo de interfaz usar?

Bueno, muchos podrían decir que usen TypeScript, pero esa no es realmente la respuesta en mi propia opinión. Así que si miras el RFC 9110, básicamente relacionado con HTTP, hay una pieza muy interesante que dice que la diferencia entre la división semántica entre los protocolos HTTP 1 y 2 se hace para hacer que el enlace sea débilmente acoplado y solo un detalle de implementación. Y eso es realmente interesante porque aquí voy a referenciar a mi querido amigo y cofundador Matteo. Él tuvo esta brillante charla y va a responder a la pregunta de cómo logramos ese rendimiento increíble entre todos estos módulos. Y habló en NodeConf EU el año pasado sobre HTTP sin red y responde a ese tipo de rompecabezas del RFC que acabo de publicar en la diapositiva anterior. Recomiendo encarecidamente ver este video. Y lo que va a revelar básicamente es el secreto detrás de nuestro tiempo de ejecución de Platformatic. ¿Cómo hacemos que todos estos módulos se comuniquen entre sí? Bueno, estos módulos en realidad están débilmente acoplados entre sí y se comunican a través de HTTP pero sin utilizar ninguna red.

7. Building Composable Monoliths with Meraki

Short description:

LEGO nos inspiró a construir nuestros bloques apilables, permitiendo la creatividad y la capacidad de componer bloques existentes y nuevos. Meraki, una aplicación de Electron, proporciona una experiencia guiada por interfaz de usuario para construir monolitos componibles. Permite a los desarrolladores publicar sus propias visiones sobre cómo se deben construir las cosas y ofrece una experiencia guiada por asistente para un desarrollo más fácil y entretenido. Meraki agrupa las composiciones para su distribución en nuestro tiempo de ejecución, que puede ejecutar bloques como componentes independientes. Únete a nuestro mercado y revoluciona la experiencia operativa de los microservicios con monolitos componibles.

Echa un vistazo a la charla. Y eso fue una gran transición hacia el siguiente paso en la interfaz y la composabilidad. Bueno, si eliminamos el detalle de implementación sobre cómo hacemos que todos estos módulos se comuniquen entre sí, si encontramos el cableado, necesitábamos encontrar una forma de hacerlos realmente componibles. Y cuando pienso en la composabilidad, me viene a la mente una de mis pasiones. LEGO. Puedes ver algunos aquí. Me encanta LEGO. Este es uno pequeño. Tengo muchos LEGO. Uno está justo detrás y al lado de mi guitarra. Y lo que es hermoso de LEGO y nos inspiró mucho es cómo se componen estos bloques entre sí. Así que la gente piensa que LEGO es solo un ladrillo de 4x2, pero en realidad LEGO patentó la forma en que se enganchan. Esa es esta forma geométrica de conectar estos cuatro puntos o dos puntos con el punto central más grande. Una forma fenomenal. Nos inspiramos mucho para construir nuestros bloques apilables, porque dijimos que construir aplicaciones modernas debería ser como construir un conjunto de LEGO. Debería permitir la creatividad al tiempo que brinda la estructura para construir nuevos bloques, pero también componer bloques existentes con nuevos bloques o bloques existentes con bloques existentes. Y así construimos Meraki. Meraki significa creatividad en griego, y para nosotros era extremadamente importante volver a habilitar la creatividad, pero también recuperar la facilidad de construir algo de lo que estamos apasionados y de lo que podemos estar orgullosos. Entonces, Meraki es una aplicación de Electron que brinda una experiencia guiada por interfaz de usuario para construir monolitos componibles. Y aquí puedes ver algunos conceptos interesantes como, por ejemplo, el servicio platformatic que es una de nuestras plantillas base de bloques apilables, y puedes agregar cualquier complemento que desees encima. Muchas empresas ya están utilizando este enfoque porque creen que es el futuro de las prácticas de escalado y desarrollo en su organización. La forma en que realmente interpretamos esto es que ¿por qué no habilitamos, como Brickset en LEGO, por qué no creamos un entorno donde las personas puedan publicar su propia visión de cómo se deben construir las cosas? Dar un inicio fácil a los consumidores, a otros desarrolladores para construir aplicaciones utilizando sus propias mejores prácticas. Y así creamos un mercado donde todos pueden construir estas plantillas, complementos y las personas pueden usarlas con un solo clic en su propia aplicación. La experiencia que imaginamos fue puramente guiada por asistente porque creemos que simplemente usando, ya sabes, nuestra experiencia de clics podría hacer que sea mucho más fácil y entretenido y realmente divertido construir estos monolitos componibles. También resolviendo algunas de las complejidades, como por ejemplo, el eterno problema de construir configuraciones o tener algunos valores predeterminados. Y al final del día, lo que imaginamos es que Meraki fue capaz de crear esa composición, esa experiencia de construcción, y luego agruparlos para su distribución en nuestro tiempo de ejecución. Porque como recordarás, nuestro tiempo de ejecución es capaz de tomar los bloques apilables, estas aplicaciones platformatic y ejecutarlas como si fueran componentes independientes. Puedes encontrar Meraki en nuestro GitHub. Es de código abierto. Si quieres agregar una nueva función, por favor envíanos una solicitud de extracción. Y sin más palabras, te invito a descargarlo, está disponible ahora y úsalo y únete a nuestro mercado y únete a esta revolución del monolito componible que creemos que va a cambiar la experiencia operativa de los microservicios, especialmente en Node.js. Te invito a explorar Platformatic y claramente Fastify y especialmente a conectarte con nosotros. Y estaré encantado de responder cualquier pregunta que tengas y de explicar aún más por qué nuestro enfoque y el enfoque del monolito componible es el futuro de una experiencia de desarrollo y una experiencia operativa más ágil en el ecosistema de Node.js, especialmente en el ámbito empresarial. ¡Ciao!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

DevOps.js Conf 2021DevOps.js Conf 2021
33 min
How to Build CI/CD Pipelines for a Microservices Application
Top Content
Microservices present many advantages for running modern software, but they also bring new challenges for both Deployment and Operational tasks. This session will discuss advantages and challenges of microservices and review the best practices of developing a microservice-based architecture.We will discuss how container orchestration using Kubernetes or Red Hat OpenShift can help us and bring it all together with an example of Continuous Integration and Continuous Delivery (CI/CD) pipelines on top of OpenShift.
JSNation Live 2021JSNation Live 2021
21 min
Micro-scopes – How to Build a Modular Modern App in a Bundled World
In this talk we will explore the great benefits of breaking a big modern app to meaningful, independent pieces – each can be built, deployed and loaded separately. We will discuss best practices and gotchas when trying to apply this microservice-like pattern to the chaotic world of the browser, and we'll see how building the right pieces guarantees a brighter future for your apps. Let's dive into Neverendering story of modern front-end architecture.
Node Congress 2024Node Congress 2024
24 min
Optimizing Microservice Architecture for High Performance and Resilience
- Delve into the intricacies of optimizing microservice architecture for achieving high performance and resilience.- Explore the challenges related to performance bottlenecks and resilience in microservices-based systems.- Deep dive into the strategies for enhancing performance, such as efficient communication protocols, asynchronous messaging, and load balancing, while also discussing techniques for building resilience, including circuit breakers, fault tolerance, and chaos engineering.- Explore relevant tooling and technologies, such as service mesh and container orchestration, and offer insightful case studies and lessons learned from real-world implementations.- Emphasize the importance of continuous improvement and adaptation in microservices environments, alongside reflections on the future trajectory of microservices architecture.

Workshops on related topic

Node Congress 2023Node Congress 2023
119 min
Decomposing Monolith NestJS API into GRPC Microservices
Workshop
The workshop focuses on concepts, algorithms, and practices to decompose a monolithic application into GRPC microservices. It overviews architecture principles, design patterns, and technologies used to build microservices. It covers the theory of the GRPC framework and protocol buffers mechanism, as well as techniques and specifics of building isolated TypeScript services in the Node.js stack. The workshop includes a live use case demo of decomposing an API application into a set of microservices. It fits the best architects, tech leads, and developers who want to learn microservices patterns.
Level: AdvancedPatterns: DDD, MicroservicesTechnologies: GRPC, Protocol Buffers, Node.js, TypeScript, NestJS, Express.js, PostgreSQL, TurborepoExample structure: monorepo configuration, packages configuration, common utilities, demo servicePractical exercise: refactor monolith app
Node Congress 2023Node Congress 2023
102 min
Decoupling in Practice
WorkshopFree
Deploying decoupled and microservice applications isn't just a problem to be solved on migration day. Moving forward with these architectures depends completely on what your team's workflow experience will look like day-to-day post-migration.
The hardest part of this can often be the number of vendors involved. Some targets are best suited for specific frontend frameworks, while others are more so for CMSs and custom APIs. Unfortunately their assumptions, workflows, APIs, and notions of security can be quite different. While there are certain advantages to relying on a strict contract between apps – where backend and frontend teams work is limited to a single vendor – this isn't always realistic. This could be because you're still experimenting, or simply the size of your organization doesn't allow for this kind of specialization just yet.
In this workshop, you'll have a chance to explore a different, single vendor approach to microservices using Strapi and Next.js as an example. You'll deploy each app individually, establishing a workflow from the start that simplifies customization, introducing new features, investigating performance issues, and even framework interchangeability from the start.
Structure:- Getting started- Overview of Strapi- Overview of Platform.sh workflow- Deploying the project- Switching services- Adding the frontend
Prerequisites:- A Platform.sh trial account created- The Platform.sh CLI installed
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.
JSNation 2023JSNation 2023
117 min
How to Convert Crypto Currencies With GRPC Microservices in Node.js
Workshop
The workshop overviews key architecture principles, design patterns, and technologies used to build microservices in the Node.js stack. It covers the theory of the GRPC framework and protocol buffers mechanism, as well as techniques and specifics of building isolated services using the monorepo approach with lerna and yarn workspaces, TypeScript. The workshop includes a live practical assignment to create a currency converter application that follows microservices paradigms. It fits the best developers who want to learn and practice GRPC microservices pattern with the Node.js platform.
Prerequistes:- Good understanding of JavaScript or TypeScript- Experience with Node.js and writing Backend applications- Preinstall Node.js, npm- Preinstall Protocol Buffer Compiler- We prefer to use VSCode for a better experience with JavaScript and TypeScript (other IDEs are also ok)
Node Congress 2022Node Congress 2022
162 min
How to Convert Crypto Currencies with Microservices in Node.js and GRPC
Workshop
The workshop overviews key architecture principles, design patterns, and technologies used to build microservices in the Node.js stack. It covers the theory of the GRPC framework and protocol buffers mechanism, as well as techniques and specifics of building isolated services using the monorepo approach with lerna and yarn workspaces, TypeScript. The workshop includes a live practical assignment to create a currency converter application that follows microservices paradigms. The "Microservices in Node.js with GRPC" workshop fits the best developers who want to learn and practice GRPC microservices pattern with the Node.js platform.