Como cada año por estas fechas, tenemos una conferencia de Microsoft para presentar las novedades del lenguaje. Este año, la nueva versión .NET 8
Si quieres una versión rápida, el típico TL;DR, es muy simple, para mi, esta versión es la 6.1.5, pero si quieres saber el motivo, tienes que leer el resto del post.
Índice
1 - Novedades de C# 12
Como cada año, nueva versión de C#, en este caso C# 12, en este blog ya vimos un post con las novedades las cuales bueno, ahi estan, en mi opinión podemos destacar los primary constructors, y el resto de nuevas funcionalidades, meh.
Pero como digo las tienes todas en el post.
Si que es cierto que en la conferencia no las listaron como tal, pero iban dejando caer pildoritas en diferentes sesiones.
La mejor parte de la nueva versión de .NET 8, y en este caso C# 12, son la versión LTS (long term support) lo que significa que tu empresa te va a permitir migrar de versiones anteriores ya que esta, a diferencia de .NET 7 tiene un soporte de largo tiempo por parte de Microsoft.
Ya sabéis que aquí en el blog no vemos F#, no por ello lo vamos a ignorar, tienes una lista de novedades en este post
Por cierto, en el último día, cuando se presentan proyectos cada 20 minutos uno de ellos era de source generators e interceptos, la librería es esta (fashOware) y cuando este el vídeo disponible lo actualizaré aqui, ya que me parece interesante.
2 - Mejoras en rendimiento de .NET 8
Una versión nueva, suele involucrar mejoras en el rendimiento, este año hemos tenido mejoras, y en número han sido muchas pero a la hora de rendimiento en totales, tampoco han destacado mucho, de hecho solo han pasado por encima para decir que una app en net 7 y net 8 tiene las siguientes diferencias:
El gráfico de la izquierda es simplemente una api recibiendo un json y el de la derecha es lo mismo pero alterando la base de datos.
Esta imagen nos deja que la misma app es capaz de procesar un 24% más de llamadas por segundo con la misma memoria y el mismo procesador, lo cual es algo muy gordo. pero al margen de una sesión ya mas avanzada la conferencia, tampoco mencionaron mucho más.
Personalmente, en mi cliente actual tenemos microservicios donde recibimos 60k llamadas por minuto, este cambio, para nosotros es muy importante.
Finalmente en este punto, ya que como digo tampoco hicieron gran cosa (una sesión separada después) mencionaron mejoras en asp net core y net maui, pero como digo, no han sido tan llamativos ya que según han dicho se han centrado más en arreglar bugs.
- Este es el blogpost enorme sobre las mejoras de rendimiento en asp.net core 8
3 - Novedades de Blazor en .NET 8
Como ya dejaron caer el año pasado, Blazor ya no es un framework de front end, ya es definitivamente Full Stack.
Es una de las sesiones que más interés me causaba ya que hace unos meses se hizo un avance de blazor unified. Si es cierto de que en la conferencia entera lo llamaron una única vez blazor unified, pero bueno, no lo llamaban así, pero la idea es la misma.
Si sabemos de Blazor, tenemos disponibles "los formatos" de Blazor Server y blazor Web assembly, ambas versiones tienen sus pros y su contras. Durante la conferencia anunciaron una nueva versión la cual se llama SSR (Static server side rendering)
Y porqué de esta versión?
Lo que pasaba con blazor era que o bien tenías una SPA o necesitabas tener websockets abiertos, lo cual trae sus propios problemas.
Ahora esos problemas simplemente desaparecen, ya podemos tener nuestra web en blazor y que actúe como una web “normal”, y pongo normal entre comillas porque el 99% de las webs de internet son de este tipo, webs donde vamos a leer information y no vamos a interactuar con ella, salvo en los links. Vamos, una web de toda la vida, como este blog.
Y no, esto no se podía hacer en Blazor hasta ahora, de hecho este blog estaba en Blazor y para que pudiera posicionar en google (por el SEO) tenía que meter un hack gordísimo que bueno al final quite la web de blazor por eso.
Por supuesto SSR tampoco es el santo grial y tiene sus pros y sus contras:
Como vemos, con SSR podemos hacer una web estática. Pero lo bueno es que estamos utilizando blazor, y aquí es donde entra la magia. Podemos crear componentes que sean interactivos, simplemente cambiando una línea de código.
En el ejemplo que pusieron tienen una web normal de una tienda y tiene un chat.
La tienda en sí es SSR, pero una vez abres el chat, ese componente es Blazor server y a través de websockets tenemos comunicación en tiempo real, pero únicamente en ese componente mientras está abierto.
Personalmente me encanta. Y recomiendo ver la presentación de steve sanderson que es BRUTAL donde va presentando todos los tipos y mostrando las diferencias, etc.
Habrá que ver cómo se adopta, si se hace, porque cuando hablamos de balzor, no nos estamos centraod en un solo “formato”, ahora tenemos 3, lo cual está bien, pero lo que no está tan bien es que cada uno tiene diferentes formas de manejar la autenticación, http context o incluso los contexto de la base de datos.
Y hasta aquí es todo lo de .NET 8, o bueno que yo considero .NET 8, me refiero a cambios que van ligados a tener esa version, todo lo que viene ahora son programas o librerías que podrían estar en .NET 6 sin ningún problema porque son independientes del lenguaje. Este es el motivo por el que he puesto al principio que es la versión 6.1.5, porque el año pasado ya se sintió como 6.1 en vez de 7, y este año, más de lo mismo.
4 - Cambios en visual studio 2022
Algo que no me esperaba ver para nada son cambios en visual studio, y si es verdad que no es algo enorme, pero es algo que se agradece. Desde la nueva versión (visual studio 2022 v17.8) vamos a tener acceso, si utilizamos open api, a la especificación de la api, directamente en el IDE y en tiempo real. Además nos va a permitir haciendo right click del ratón generar un fichero http para realizar llamadas a dicha API.
Es una funcionalidad que es común en otros IDEs y lenguajes, y que no es tan común de ver en C#, pero bueno está bien tenerla.
Adicionalmente, he de decir que también note que hot reload iba mejor que antes, o bueno que iba bien, como se espera, tengo que ver en mi máquina si va igual, porque a mi me falla mucho.
5 - MAUI en .NET 8
Es posible que pensaras que MAUI está muerto, ¡PERO NO! Solo están arreglando bugs, porque sí, eso ha sido todo (y una breve medición al rendimiento) que han mencionado, incluso con una sección en la sesión principal…
Personalmente, pienso que Avalonia o Uno sigue siendo una mejor alternativa si de verdad quieres hacer algo nativo.
Pero si me preguntas a mi, mi opinión es que el 99% de apps deben ser apps webs con un shell, en este caso MAUI, que les permita correr en escritorio/mobile.
Si slack, que está valuada en 27 mil millones de dólares lo hace, tú también deberías, en el caso de C#, podemos hacer esto con blazor hybrid, es muy sencillo y funciona muy bien.
Ah! Que no se me olvide, igual que tenemos C# Dev kit en visual studio ahora tenemos otro para MAUI…
6 - Inteligencia artificial
AI AI AI!!!!!!!!! No te has enterado aún? Tenemos AI hasta en la sopa hoy en día, y por supuesto .NET adora la inteligencia artificial.
Lo que yo no entiendo es como esto entró en la presentación principal, ya que directamente no presentaron nada. Si que es verdad que a lo largo de la conferencia hubo sesiones sobre historia de IA, explicación de los diferentes modelos, y workshops sobre cómo utilizar estos modelos desde C#, que esa parte pues no está muy bien.
7 - .NET ASPIRE
.NET ha sacado un proyecto/librería que te da out of the box una forma de orquestar diferentes funcionalidades en tus aplicaciones distribuidas, principalmente observabilidad, o librerías como rabbitMQ, postgres o Redis. Básicament una version mas grande de lo que hice en su día en mi proyecto de Distribt. Menuda robadita por la cara que se han pegado ??
#SoyUnVisionario
Obviamente no es lo mismo, pero la idea es similar, y está muy bien, Aspire está pensado para esos proyectos que tenemos un montón de dependencias, aspire se encarga “de todo” de saber cual es el puerto, url, etc. Incluye observabilidad out of the box, lo cual es algo indispensable en los entornos distribuidos, no se puede ir a microservicios sin observabilidad, y con esta funcionalidad, pues ya estaría, por supuesto está pensado para que funcione todo en local.
La principal idea es centralizar gran parte de la información y es algo que la gran mayoría de empresas deberían hacer más a menudo.
En este canal la exploraremos más pronto que tarde. Por ahora te dejo el blogpost de microsoft, el cual es muy completo.
8 - Otros elementos destacados de la netconf 2023
8.1 - Cloud native
Foco donde saben que los clientes tienen los problemas más gordos, observabilidad, y el cómo hacer las cosas bien.
Se han centrado durante la gran parte de presentaciones y workshops en en la observabilidad, por ejemplo grafana viene por defecto en aspire. Y luego las imágenes de los contenedores son más pequeñas, lo cual es muy bueno porque claro, reduce el tamaño, tiempo, dependencias, velocidad de despliegue,
Hemos visto varios workshops sobre Cloud native apps, que incluye azure functions, y por supuesto muy centrados en aspire, royo, cómo usar una aspire app y desplegarla en azure, cosas así, que tienen sentido en una conferencia de microsoft.
Además, otros workshops donde se menciona open telemetry (otra vez observabilidad) y como está implementado en .NET, aquí en el blog ya vimos open telemetry, y si, en el curso de Distribt.
Y sí, las demos y workshops también fueron con prometheus y grafana, igual que la mia :3
8.2 - Native AOT
Native AOT no está finalizado, aunque es una buena mejora. Vamos a ello:
Para los que no sepáis qué es Native AOT (ahead of time compilation) lo voy a intentar resumir muy rapidito, cuando compilas tu app de C#, lo que haces es compilar a IL (intermediate language) y luego cuando haces “publish” lo que pasa es que el IL se compila en código de la plataforma, por ejemplo si corres en una arquitectura de 32bits se compila para esa plataforma, si es para ARM es para esa, etc.
Lo bueno de hacer esto es que puedes eliminar un montón de funcionalidades que no necesitas, bueno no tu, el compilador, lo que hace que el tamañoy el rendimiento mejoren. Por ejemplo la app que mostraron cambio de 102 mb de tamaño a 23mb.
Por cierto, para que tu app pueda ser utilizada como native AOT todas las dependencias tienen que ser compatibles con AOT .
2.3 - Api de identity por defecto en los templates
Uno de los grandes problemas de C# es el como tratan todo el tema de autenticación, que es un desastre, bueno pues en la nueva versión tenemos una opcion para crear en la app que utilicemos nuestros endpoints de auth, completamente out of the box, vamos, que no tenemos que hacer nada.
veremos esta funcionalidad en el blog a lo largo de 2024
