Validación de parámetros de entrada

Sesión 3: 3h18m

Implementando un servicio REST

Sesión 3: 2h45m

Enlace de modelo con atributos de origen

• [FromBody]: Cuerpo de solicitud
• [FromForm]: Datos del formulario en el cuerpo de la solicitud
• [FromHeader]: Encabezado de solicitud
• [FromQuery]: Parámetros por Query string
• [FromRoute]: Datos a través de rutas de la solicitud actual
• [FromService]: El servicio inyectado como parámetro de acción.

PUT vs PATCH

• PUT es para actualizaciones completas. 
• Todos los campos de recursos se sobrescriben o se establecen en su valores predeterminados.
•  No se reemplazar el identificador de identidad
• PATCH es para actualizaciones parciales. 
• Permite enviar conjuntos de cambios a través de JsonPatchDocument.
• El cuerpo de la solicitud de un PATCH se describe en RFC 6902 (JSON patch)
• Las solicitudes PATCH deben enviarse con el media type "application/json-patch+json"

Ejemplo Código

2h50m: Implementación CRUD

• Implementar los Handlers en la capa de infraestructura
• Implementar los Casos de Uso en la capa de aplicación (interfaces e implementación)
• Implementamos la infraestructura de persistencia

Diseño de un servicio REST

Sesión 3: 2h31m

Diseño del contrato

• Identificador de recursos
• http://localhost/api/authors
• Método HTTP
• https://datatracker.ietf.org/doc/html/rfc9110 
• Payload (Representación: media types)
• Por convención se usa JSON

Lineamientos para el nombramiento de recursos

• Sustantivos: cosas, no acciones
• api/getauthors
• GET api/authors
• GEt api/authors/{authorId}
• Transmitir significado al elegir sustantivos
• Seguir el principio para la predictibilidad
• api/something/somethingelse/authors
• api/authors
• api/id/authors
• api/authors/{authorId}
• Representar la jerarquía al nombrar recursos
• api/authors/{authorId}/books
• api/authors/{authorId}/books/{bookId}
• Filters, sorting orders, ... no son recurso
• api/authors/orderby/name
• api/authors?orderby=name
• A veces las llamadas al estilo RPC no se asignan fácilmente a nombres de recursos pluralizados
• api/authors/{authorId}/pagetotals
• api/authorpagetotals/{id}
• api/authors/{authorId}/totalamountofpages

Interactuar con recursos a través de métodos HTTP

La importancia de los códigos de estado

• Los código de estado indican al consumidor
• Si la solicitud funcionó o no como se esperaba
• ¿Quién es responsable de una solicitud fallida?
• Ser lo más específico posible
• Los consumidores de API suele ser no humanos
• Ser especialmente específico en lo que respecta a informar quién/qué es responsable de un error.

Formateadores y Negociación de Contenido

• Output formatter
• Se ocupa del tipo de salida. Media type: Accept header
• Input formatter
• Se ocupa del tipo de entrada. Media type: Content-type header

Modelo externo frente al modelo de entidad

• El modelo de entidad representa las filas de la base de datos como objetos
• El modelo externior representa lo que se envía a través del servicio

• La separación de los modelos externos y de entidad conduce a un código más robusto, confiable y evolutivo.

Modelo de madurez de Richardson

Sesión 3: 2h29m

Si queremos saber en que nivel se encuentran nuestras APIs usamos el modelo de madurez de Richardson.

Nivel 0 (Swamp of POX)

• El protocolo HTTP se utiliza para la interacción remota.
• El resto del protocolo no se usa como debería ser.
• Implementaciones de estilo RPC (SOAP, a menudo vistas cuando se usa WCF).

POST (informacion)

http://host/myapi

POST (para crear un autor)

http://localhost/authors

Nivel 1 (Recursos)

• Cada recurso se asigna a un URI
• Los métodos HTTP no se usan como deberían ser
• Resultados en complejidad reducida

POST

http://localhost/api/authors

POST

http://localhost/api/authors/{id}

Nivel 2 (Verbos)

• Se utilizan correctamente los verbos HTTP
• Se utilizan correctamente los códigos de estado
• Remueve las variaciones innecesarias
• Mínimanete deberíamos llegar a este nivel

GET

http://host/api/authors

200 OK (authors)

POST (representación de author)

http://localhost/api/authors

201 Created (author)

Nivel 3 (Hypermedia)

• La API tiene soporte de Hypermedia as the Engine of Application State (HATEOAS)
• Autodocumentación

GET

http://host/api/authors

200 Ok (authors + links que controlan el estado de la aplicación)

Registro de Excepciones

El registro de excepciones es una práctica esencial para el mantenimiento y la estabilidad de cualquier aplicación. Permite capturar, analizar y almacenar información sobre fallos en tiempo real, facilitando la resolución de problemas tanto en entornos de desarrollo como en producción. En este capítulo, exploraremos las mejores prácticas para registrar excepciones y errores en aplicaciones .NET, el uso de herramientas de logging, y cómo aprovechar los registros para mejorar la calidad del software.

¿Por Qué es Importante Registrar Excepciones?

El registro de excepciones ofrece múltiples beneficios:

• Resolución Rápida de Problemas: Los registros detallados permiten identificar la causa raíz de un error rápidamente.
• Monitoreo en Producción: Proporciona visibilidad de lo que está ocurriendo en la aplicación en tiempo real.
• Historial de Errores: Ayuda a identificar patrones recurrentes y áreas problemáticas del código.
• Mejora Continua: Proporciona datos para optimizar el rendimiento y la estabilidad del software.

Qué Registrar en una Excepción

Un registro efectivo debe incluir información detallada que ayude a los desarrolladores a diagnosticar el problema. Esto incluye:

• Mensaje de Excepción: Describe brevemente el error.
• Traza de Pila (Stack Trace): Indica dónde ocurrió la excepción en el código.
• InnerException: Si existe, proporciona el contexto de una excepción encadenada.
• Datos del Contexto: Variables relevantes, el usuario afectado, o el estado de la aplicación en el momento del error.
• Fecha y Hora: Momento exacto en que ocurrió el error, útil para análisis temporal.

Herramientas de Logging en .NET

El ecosistema .NET incluye herramientas avanzadas para registrar excepciones y errores. Aquí están las más utilizadas:

• Serilog: Serilog es una herramienta flexible y moderna que permite estructurar registros y enviarlos a múltiples destinos, como archivos, bases de datos o servicios en la nube.
• NLog: NLog es una librería ligera que permite registrar excepciones en diversos formatos y destinos. Es ideal para aplicaciones de alto rendimiento.
• Elmah: Elmah (Error Logging Modules and Handlers) está diseñado específicamente para aplicaciones ASP.NET y facilita el registro automático de excepciones no gestionadas.
• Application Insights: Es una herramienta de monitoreo en la nube de Microsoft Azure que permite registrar excepciones y métricas de rendimiento.

Ejemplo con Serilog

Mejores Prácticas en el Registro de Excepciones

• Registrar Solo Información Relevante: Evita inundar los registros con datos irrelevantes. Concéntrate en detalles importantes como el mensaje de la excepción, la traza de pila y datos contextuales.

• Usar Niveles de Severidad: Clasifica los registros en categorías como:

• Debug: Información para diagnóstico en desarrollo.
• Information: Eventos informativos.
• Warning: Potenciales problemas.
• Error: Problemas que afectan el flujo normal de la aplicación.
• Critical: Errores graves que requieren intervención inmediata.

• Evitar Información Sensible: Nunca registres datos confidenciales, como contraseñas, números de tarjetas de crédito o información personal.

• Centralizar el Logging: Configura un sistema centralizado que registre excepciones de toda la aplicación en un único repositorio, como un servidor de logs o un servicio en la nube.

• Registrar Excepciones No Manejadas: Configura manejadores globales para capturar excepciones no gestionadas:

Patrones Avanzados de Logging

Los patrones avanzados de logging ofrecen formas estructuradas y eficientes de gestionar los registros de excepciones y errores en aplicaciones complejas. Estos patrones ayudan a mantener un sistema de registro escalable, centralizado y resiliente. A continuación, se presentan algunos patrones clave que puedes aplicar en tus proyectos.

Patrón Decorator: El patrón Decorator se utiliza para extender o modificar el comportamiento de un sistema de logging sin alterar su código base. Esto es especialmente útil si deseas agregar funcionalidades, como el envío de notificaciones automáticas para errores críticos, sobre una solución de logging ya existente. Como ventaja, la funcionalidad adicional (como notificaciones) se agrega sin modificar la implementación original del sistema de logging. Ejemplo: Logging con Notificaciones de Errores Críticos

 

Fallback Logging: El patrón Fallback Logging asegura que el sistema de registro sea resiliente en caso de fallos en el destino principal de los logs. Si, por ejemplo, un servicio en la nube no está disponible, los registros se redirigen a un sistema alternativo, como archivos locales. Ejemplo: Alternativa Local a un Servicio de Logging 

 

Patrón Centralizado: El patrón Centralizado se utiliza para consolidar todos los registros de una aplicación en un único sistema o servidor, lo que facilita el monitoreo, la consulta y el análisis. Este patrón es especialmente útil en aplicaciones distribuidas o en microservicios. Ventaja: Centralizar los logs facilita la búsqueda y análisis de errores mediante herramientas como Kibana, Application Insights o Splunk. Ejemplo: Implementación con Serilog y ElasticSearch. 

 

Logging Estructurado: El logging estructurado consiste en registrar datos como objetos en lugar de simples cadenas de texto. Esto permite que los logs sean fácilmente consultables y procesables por herramientas de análisis. Ventaja: Los datos estructurados permiten correlacionar registros y analizarlos más fácilmente en sistemas de búsqueda. Ejemplo con Logging Estructurado en Serilog. 

Conclusión

El registro de excepciones es una herramienta poderosa para monitorear, diagnosticar y solucionar problemas en aplicaciones .NET. Al implementar herramientas como Serilog, NLog o Application Insights y seguir buenas prácticas de logging, puedes garantizar que los errores se gestionen de manera eficiente y que las aplicaciones sean más estables y confiables. El logging no solo ayuda a resolver problemas, sino que también es clave para la mejora continua del software.

Introducción a REST

Sesión 3: 2h1m

REST necesita restricciones

Interfaz uniforme: Todos los recursos del servidor tienen un nombre en forma de URL o hipervínculo.

• Identificación de recursos
• Un recurso está separado conceptualmente de la representación.
• Media Types de representación: application/json, application/xml, custom...
• Manipulación de los recursos a tavés de las representaciones
• La representación + metadatos deben ser suficientes para modificar o eliminar el recurso.
• Mensaje autodescriptivo
• Cada mensaje debe incluir información suficiente para describir cómo procesar el mensaje.
• Hypermedia as the Engine of Application State (HATEOAS)
• Hypermedia es una generalización de Hypertext (links)
• Indica como consumir y utilizar la API
• Permite la autodocumentación de la API
• REST ya te indica que autodocumentes la forma en que debes consumir los servicios. No indica utilizar OpenAPI para documentar servicios. Usamos OpenAPI porque no llegamos a implementar HATEOAS. Una forma de suplir la documentación de REST es usar OpenAPI y Swagger.

Cliente-Servidor: La aplicación se tiene que separar en dos componentes; el cliente y el servidor. Cliente y servidor pueden evolucionar por separado.

Statetlessness: El estado está contenido dentro de la solicitud. 

Sistema en capas: El cliente no puede determinar a que capa está conectada.

Cacheable: Cada mensaje de respuesta debe indicar explícitamente si se puede almacenar en caché o no. 

Código bajo demanda (opcional): El servidor puede extender la funcionalidad del cliente. La aplicación cliente puede recibir código del servidor. Ejemplo: El sevidor generar código JavaScript y se lo envía al cliente para su ejecución.

IMPORTANTE: Un sistema solo se considera RESTful cuando se adhiere a todas las restricciones requeridas. La mayoría de las API "RESTful" no son realmente RESTful, pero por eso no los hace malos APIs, siempre y cuando se entienda las posibles compensaciones.

¿Cuál es la diferencia entre una API y un servicio en el ámbito web?

• El API es solamente una interfaz
• La API consume un Sevicio (quien hace realmente el trabajo).

Estrategias de uso y características avanzadas de EF Core

Sesión 3: 1h28m30s

Por convención o por sus propias reglas

• Use convenciones cuando sus necesidades sean justas y comunes
• Personaliza para satisfacer tus necesidades

Aplicando Mappings

Aprovechar procedimientos almacenados

• Uso para consultas y comandos
• Ejecutar con parámetros

Inyección de Dependencias

Sesión 2: 1h34m

Desarrollando y desplegando pruebas de concepto (Poc)

Integración de Routes, Verbs y HTTP Status Codes

Routing

Valores retornables de un Minimal API

• String
• Cualquier tipo, pero se genera una cadena
• IResult-based types: Results.X, TypeResults.X
• Los Minimal API no pueden devolver binario. Para este caso se tendría que usar un protocolo como gRPC.

Código de estados HTTP más comunes

Application/WebApplicationBuilder y Routing

Sesión 2: 1h10m

Routing

• El proceso de hacer coincidir un método HTTP y URI con un controlador de ruta específico.
• app.MapAction methods
• Donde Action = El método HTTP
• IEndpointRouteBuilder
• Conceptos de Routing
• Método Route builder de IEndpointRoute Builder
• Plantillas o patrones de rutas
• Parámetros de rutas
• Restricciones de rutas
• Parámetros Binding Sources
• Routes Values [FromRoute]
• Query string [FromQuery]
• Header [FromHeader]
• Body (as JSON) [FromBody]
• Services provider by DI [FromServices]
• Custom

Arquitectura de Minimal APIs

Sesión 2: 50m

Opciones para estructurar Minimal APIs

• Usar métodos en lugar de controladores
• Separación de métodos de controlador en clases (Handlers)
• Extension IEndpointRouteBuilder
• Librería de terceros

Looks Good to Me: Constructive code reviews - Adrienne Braganza

 

Why API-First Matters in an AI-Driven World

 Source: https://thenewstack.io/why-api-first-matters-in-an-ai-driven-world/

Mapping y Querys en EF Core

Sesión 2: 4h47m

Traducción de tipo .NET a tipo de datos

 De clases a tablas. 

DbContext de EF Core es fundamental para toda persistencia

• Controla qué clases se asignan a la base de datos
• Siempre es necesario crear una clase que herede de DbContext
• Controla todas las interacciones con la base de datos
• Controla cómo se asignan esas clases a la abse de datos
• El mapeo de campos se encuentra dentro del Contexto

Entidades y el DbContext

• Objetos en memoria (In-Memory)
• Entidades: Objetos en memoria con propiedades clave (identidad) de los cuales el DbContext es consciente.
• DbContext: Contiene objetos EntityEntry con punteros de referencia a objetos en memoria.

Flujo de trabajo de seguimiento y guardado

EF Core Flujo de Migraciones

• Versionar los cambios de la estructura de datos

• Dabasase Migration: Evolución del esquema de la base de datos para que coincida con los cambios en el modelo descrito por el código.
• EF Core Migrations API
• Inspeccionar el modelo de datos.
• Comparar el estado del modelo de datos después de la migración anterior.
• Crear Script SQL (y ejecutar, si lo desea) para actualizar el esquema de la base de datos.
• Utilizando migraciones
• Update-Database (Para ambientes de desarrollo)
• Lee el archivo de migración
• Genera el SQL en memoria
• Crea la base de datos si fuese necesario
• Ejecuta el SQL en la base de datos
• Script-Migration (Para ambientes de producción)
• Lee el archivo de migración
• Genera el SQL
• Por defecto lo muestra en el editor SQL
• Usa parámetros para definir la salida del archivo

• Recomendación de migraciones

• Ingeniería inversa: Generar entidades a partir de base de datos.}
• Scaffold Ingeniería Inversa
• Operación única para crear clases de "stake in the ground" y DbContext
• A través de la herramienta de línea de comandos con una variedad de opciones
• EF Core Power Tools impulsado por la comunidad

• Beneficios de EF Core Migrations
• Determina el esquema con la misma lógica utilizada para describir el modelo de datos y las asignaciones.
• Los archivos de migración pasan a formar parte del control de código fuente.
• Crear paquetes de migración "compatibles con DevOps" para la implementación/ejecución
• Genere scripts SQL e incorpórelos a su propio proceso.

RECOMENDACIÓN: Para gestionar los cambios de la estructura de datos hay que usar migraciones en vez de archivos de Scripts.

Ejemplo Código Migraciones

Sesión 3: 42m30s

• A partir de mi código voy a crear mi BD.
• Generar migraciones: add-migration Init -o Infrastructure/Persistence/Migrations
• Ejecutar migracion (en ambientes de desarrollo): Update-Database 
• 1h01m: Datos semilla
• 1h21m: Repositorios
• 1h34m: Capa de aplicación

LINQ

Sesión 3: 1h26m

Consulta integrada de lenguaje (Language Integrated Query). Una característica de .NET desde hace mucho tiempo con una extensión EF Core que, con la ayuda del proveedor de base de datos correspondiente, transforma esas consultas LINQ en consultas SQL.

EF Core's LINQ Query Workflow

LINQ to Entities, algunos métodos

Entity Framework Core - Modelado de datos

Sesión 2: 4h22m

Abastraernos de la tecnología de datos.

Manejo de tareas de acceso a datos

• Abstracción de la BD a nivel de objetos
• Seguimiento de cambios
• Database schema migrator
• Transform LINQ queries to SQL

Consultas con EF Core

• Porque usar el lenguaje de consulta LINQ integrado. LINQ es para realizar consultas de objetos en memoria. Puedo usar LINQ sin EF Core.
• Escribir consultas en clases .NET
• IntelliSense para simplificar la codificación
• EF Core materializa objetos a partir de resultados de consulta

Evolución histórica

Proveedores de bases de datos creados por Microsoft

3rd Party y proveedores de BD de código abierto

https://learn.microsoft.com/en-us/ef/core/providers/?tabs=dotnet-core-cli

ORM Típico vs ORM Avanzado (EF Core)

Un ORM Tipico mapea tablas y entidades

Un ORM avanzado como EF Core tiene un mapeo inteligente y flexible

• Múlples campos de una tabla a una clase o varias clases
• Múltiples clases a una sola tabla

Base de datos relacional

Sesión 2: 4h6m

¿Qué es una base de datos?

• Una colección de datos almacenados en formato electrónico.
• Usualmente diseñado para hacer que la lectura y actualización de datos sea rápida y fácil.
• Algo así como una guía telefónica, mucho más rápido de consultar, y mucho más fácil de corregir y agregar.

Términos Clave

• Query: Instrucciones para recuperar datos específicos de la base de datos.

• Index: Una estructura de datos especial que ayuda a acelerar la selección, consultas, al igual que un índice de un libro.
• Clustered: Es parte de la tabla, define el orden físico.
• Nonclustered: Son estructuras adicionales de la tabla.

• Almacenamiento físico: SQL Server almacena sus bases de datos en disco, en hasta tres diferentes tipos de archivos. El archivo de log es importante porque permite regenerar los datos. Es importante que el Log esté activado en producción.

• RDBMS: Sistema de gestión de base de datos relacional (por ejemplo, SQL Server) - una colección de software que gestiona el acceso a la base de datos.

• Data Manipulation Language (DML): El lenguaje de consulta utilizado para consultar y actualizar datos en la base de datos. SQL Server utiliza Transact-SQL (T-SQL), que una variante del lenguaje general "SQL".
• Data Definition Language (DDL): Utilizado para manipular el esquema de una base de datos. Creando tablas, modificando índices, etc. Los estándares ANSI cubren muy poco DDL, aunque la mayoría de proveedores de bases de datos han convergido en convenciones similares.
• Stored Procedures: Son básicamente "archivos por lotes" o "scripts" que indican como ejecutar un conjunto dado de comandos en un orden específico. Se ejecutan en el servidor, lo que puede reducir el procesamiento.  
• Normalización: El propósito de la normalización es reducir el almacenamiento de datos y para reducir la redundancia de datos asegurándose de que cualquier pieza dad de datos se almacena una sola vez. Son 5 técnicas involucradas en la normalización completa del diseño de una base de datos.

Almacenamiento de información

Sesión 2: 3h46m

Se refiere a la capacidad y métodos que una aplicación de software utiliza para guardar, mantener y recuperar información o datos. Este almacenamiento puede ser temporal (como en la memoria caché)  o permanente (como una base de datos).

Teorema de CAP

Útil para la selección de un motor de BD:

• Si prima la consistencia y la disponibilidad, entonces usaremos las BD relacionales. Consistencia implica que todo los clientes vean la misma información. La disponibilidad implica que el sistema puede seguir funcionando a pesar que falla un nodo: SQL Server, Oracle, MySQL, PostgreSQL
• Donde prima la consistencia y la tolerancia a la distribución de datos: redis, mongoDB.
• Donde prima la alta disponibilidad y la tolerancia a la distribución de datos: Cassandra, amazon DynamoDB, etc.

NoSQL

• El término "NoSQL" puede ser un poco confuso porque no se refiere necesariamente a la falta de SQL (Structured Query Language). En cambio, NoSQL originalmente significaba "No SQL" pero ha evolucionado para significar "Not Only SQL". Esto significa queestas bases de datos no se limitan a la estructura tabular y al lenguaje de consulta SQL utilizados en las bases de datos relacionales, pero pueden usarlos si es necesario.
• Las bases de datos NoSQL fueron creadas en respuestas a las limitaciones de las bases de datos relacionales, especialmente para manejar conjuntos de datos grandes, distribuidos y semi-estructurados.
• Los sistemas NoSQL generalmente no requieren un esquema fijo como las bases de datos SQL, son más fáciles de escalaren forma horizontal, y fueron diseñados para operaciones simples en un gran número de rgistros.

Tipos de Base de Datos NoSQL

• Clave-Valor: Vincula una clave dada a un registro de cualquier tipo.
• Documental: Se basan en el concepto detrás de clave-valor, extendiéndolo para admitir objetos complejos de varias capas denominados documentos.
• Columnar: Puede pensar en las filas como claves en un almacén clave-valor y las columnas como el valor.
• Grafos: Enfoque hacia la relación entre entidades. Las entidades, como los usuarios, están representados por nodos, mientras que las conexiones entre entidades dictan cómo se relacionan.

Instalando y configurando entorno

Sesión 2: 3h4m

Creación de la solución y proyectos de la arquitectura propuesta

• Crear solución en blanco.
• Crear carpetas en solución. Las carpetas que se generan a nivel de solución son virtuales.
• Crear carpetas físicas las cuales estarán mapeadas a las carpetas virtuales de la solución de Visual Studio.
• Crear proyectos dentro de Visual Studio (web api, librerías, etc.)
• Contenerizar servicios
• Agregar Dockerfile: Permite la generación de la imagen
• Generar orquestardor de contenedores local: Docker Compose. Esto se aplica sobre cada uno de los proyectos.
• Definir nombres de contenedores
• Definir puertos específicos para acceder a los contenedores
• Crear red
• Ejecutar docker compose: docker compose up -d
• Recompilar: docker compose build
• Testear acceso a contenedores: http://localhost:8082/weatherforecast
• Crear BD SQL Server. Para conectarme a la BD contenerizada:
• Server type: Database Engine
• Server name: .,1434
• Login: sa
• Password: ******
• En la medida de lo posible el ambiente de desarrollo tiene que ser contenerizado. Para temas de desarrollo es recomendable contenerizar la base de datos. Para escenarios de producción de alta criticidad y/o performance se recomienda usar la base de datos en un fierro dedicado.

Diseñando y modelando Minimal APIs

 Sesón 2: 2h24m50s

Arquitectura de Aplicación

IdP: Proveedor de identidad

Backend

• Domain: Lógica de negocio. Se puede aplicar DDD.
• Library.service
• Application: orquestador de capa de dominio e infraestructura
• Services
• Validators
• Domain: Lógica de negocio pura
• Services
• Entities
• Infrastructure
• Data
• DTOs
• HTTP
• Mapper
• Security
• Domain Service 01 (Por ejemplo, Productos.service)
• Domain Service 02 (Por ejemplo, Pedidos.service)
• Domain Service 03
• Infrastructure: Componentes de soporte
•  Security.service
• Application
• Domain
• Infrastructure
• Data
• Mapper
• DTOs
• Security
• HTTP
• Infrastructure Service 01
• Infrastructure Service 02
• Infrastructure Service 03

Minimal APIs vs Controller APIs (Classic)

Sesión 2: 39m50s

• La recomendación es que en nuevos desarrollos usar Minimal APIs
• Para negociación de contenido usar Controller APIs. En futuras Minimal APIs seguramente soportará esta característica.

Controller APIs

La inyección es por el contructor

Minimal APIs

En Minimal API para tener un solo endpoint solo necesitamos lo siguiente:

La inyección de dependencia es a través los parámetros de las funciones lambda.

Endpoints Filters

• Ejecutar código antes y depués del controlador
• Puede inspeccionar y cambiar parámetros
• Útil para preocupaciones transversales
• Inicio sesión
• Validación

Route Groups

TypedResults

ASP.NET Core novedades y mejoras

Sesión 1: 3h52m30s

Arquitectura de ASP.NET Core

Lo que antes necesiba para hacer mi aplicación en ASP.NET (consumo de recursos, muy pesado)

OWIN es una especificación. Su implementación fue Katana lo cual evolucionó a ASP.NET Core.

La arquitectura completa de ASP.NET Core es la siguiente:

Un Middleware es componente que está entre el cliente y el endpoint. Captura, modifica el request y el response. En el viejo ASP.NET se tienen los Handlers. Un Middleware es para todas las solicitudes mientras que un Filter es para un endpoint en específico.

ASP.NET Core MVC es tecnología de servidor que implementa el patrón MVC el cual genera un salida  HTML. Tiene un antipatrón porque no se debe generar código cliente en el servidor. Ese antipatrón se conoce como "Mixing of Concerns" o "Server-Side Rendering of Client-Side Code".  Es menos escalable porque todo el procesamiento se hace en el lado del servidor. Aunque tiene algunas ventajas: Puede hacer encriptamiento. No se recomiendo mucho su uso a menos que esté justificado. Una de las justificaciones es la seguridad.

ASP.NET Core API & Minimal APIs: 

¿Hay alguna manera de que el navegador pueda ejecutar C#, Python, Java, etc? Sí, la tecnología Web Assembly, un estándar que nos permite generar compiladores que permiten ejecutar codigo C#, Python, Java, etc. con ciertas limitaciones. En el caso de Microsoft se llama Blazor Web Assembly el cual permite ejecutar código C# en el navegador.

¿Cómo puede hacer para que el servidor le envíe un mensaje al cliente? Websocket, Server-Sent Events (SSE), Long Pooling. Para que estos protocolos el servidor y el cliente deben aceptar el protocolo. SignalR es un framework que automatiza Websocket, SSE y Long Pooling.

gRPC es un protocolo de Google que permite la comunicación en binario. Los navegadores web todavía no tienen la serialización de binario. gRPC se utiliza normalmente cuando se quiere comunicar 2 servicios. La comunicación binaria es mucho más rápida.

Mejoras principales en ASP.NET 8

• Mejoras de rendimiento
• Adiciones a Blazor y Minimal APIs
• Cambios en el servidor y en el runtime

Nuevas características de ASP.NET Core 7

• HTTP/2 WebSockets
• HTTP/3
• Output caching
• Rate limiting: restringir la cantidad de peticiones por algún tipo de regla para evitar ataques de denegación de servicio.
• Request decompression

Nuevas características de ASP.NET Core 8

• Rout short-circuiting
• Ekeyd service registration
• Soporte nuevas métricas
• Mejora de los background services
• .http files en Visual Studio
• Cambios en Identity
• HTTP/3 por defecto
• Native OAT (compilación nativa)
• Form binding en Mnimal APIs
• Depuración mejorada

Route Short-cicuit

NET Compilation Workflows

Output Caching