Como ustedes han de saber, .NET5 fue liberado oficialmente el 10 de noviembre de 2020 junto con el C#9 y F#5, pero estoy jugando con él desde antes.
Cuando no estoy en la cocina, montando bici o compartiendo con mi familia, estoy programando para mantener mis habilidades como desarrollador afinadas.
En uno de esos ejercicios quise ver como sería escribir un microservicio y tratar de hacerlo lo más sencillo y pequeño, además apalancando las nuevas características presentadas por C# 9, como por ejemplo los Top Level Statements, con los cuales ya no es necesario empaquetar el cuerpo de tu programa en un método Main para su ejecución.
Ahora, hablemos de esa definición de microservicio y de cómo probablemente no se alinea con lo que ya conoces:
“Se trata de un servicio pequeño con una responsabilidad definida, que se ejecuta en su propio proceso, con su propia persistencia y que para comunicarse usa mecanismos ligeros como http”
(Le tomé un poco prestado a Martin Fowler).
Para este ejercicio podríamos decir que se trata más de una plantilla para crear microservicios que de un microservicio per se.
Cuando les menciono que quería ver cuáldo sería el resultado, lo hice teniendo en mente que generalmente al crear un proyecto o solución con VisualStudio o con la interfaz de línea de comandos de dotnet, el proceso de andamiaje ó scaffolding propio de la herramienta, genera muchos archivos con mucho código que buscan dar más estructura a la solución y a veces terminamos con muchos elementos que no siempre son necesarios.
Entrando en materia
Dotnet ya viene con algunas plantillas para crear diferentes tipos de soluciones, yo voy a usar la plantilla de aplicación de consola (console) y añadiré lo que necesitemos. Entonces…
dotnet new console — n MicroMini
Ahora, debo cambiar el tipo de proyecto para que se trate como una api, entonces modificamos la entrada <Project> en el archivo .csproj del proyecto, cambiando el sdk de Microsoft.NET.Sdk a Microsoft.NET.Sdk.Web
Paso siguiente debemos modificar el archivo Program.cs para inicializar la api, el cual empieza de la siguiente forma:
Necesitamos inicializar un IHostBuilder para hacer arrancar la webapi
Entonces, haciendo uso de top level statements nos deshacemos del método Main y vamos a simplificar la creación del IHostBuilder. Luego cableamos la api con webBuilder.Configure para añadir enrutamiento a nuestro micro y suscribimos 3 endpoints via route.Map como sigue:
- GET “/” : un get básico que retorna un mensaje sencillo.
- GET “/api/sample/{a:int}/{b:int} : un get que recibe datos en el path: cabe anotar que netcore valida el tipo de datos suscrito en ese path (cuando lo ejecutes trata de pasar en vez de int, un string o un double y mira que pasa).
- POST “/api/sample”, un POST en donde capturamos la data del body y la retornamos tal cual.
Adicionalmente añadimos soporte para logging (ConfigureLogging) volcando los logs a la consola y establecemos el nivel minimo de logging a Debug.
Si te das cuenta obtener los datos del path o del body no es tan sencillo como en un proyecto webapi, pero se trataba de hacerlo pequeño y si somos honestos, tampoco es que sea tan difícil.
Solo resta ejecutar el micro con:
dotnet run
Esta es mi plantilla de microservicios, de nuevo no se trata de levantar polémica alrededor de si es un micro o no, para mí lo es atendiendo a una responsabilidad única, siendo pequeño. Escucho tu opinión, déjame leerte. El proyecto aquí https://github.com/cheoalfredo/Micro-mini.
