Este artículo pretende servir de introducción conceptual a ASP.NET Core, con una pequeña focalización en el request pipeline entre el servidor web http y la aplicación ASP.NET Core.
- ASP.NET Core es un framework open-source. Podéis encontrar el código fuente en GitHub.
- ASP.NET Core es cross-platform. Las aplicaciones ASP.NET Core se pueden desarrollar y ejecutar en entornos Windows, Mac y Linux.
- ASP.NET Core está diseñado para desarrollar aplicaciones modernas conectadas a Internet. Permite ser desplegado tanto en Cloud como en on-premise, y soporta .NET Core y .NET framework.
- ASP.NET Core es un rediseño simplificado de ASP.NET. Este nuevo framework se ha modularizado en pequeños servicios/funcionalidades encapsuladas en paquetes NuGet. De esta forma, se nos ofrece mucha flexibilidad a la hora de construir nuestras aplicaciones, ya que podemos añadir únicamente los servicios/funcionalidades que vayamos a necesitar.
Reduciéndolo conceptualmente al mínimo, podemos decir que ASP.NET Core es simplemente una aplicación de consola, un ejecutable .exe que crea un servidor web http en el método Main.
Al crear un nuevo proyecto en Visual Studio con la plantilla para aplicaciones web ASP.NET Core (.NET Framework), se nos genera la siguiente solución:
Si entramos a ver la clase Program.cs:
Vemos que Visual Studio automáticamente nos ha generado las pocas líneas necesarias para crear el servidor web http, configurar algunas características del servidor y ‘levantarlo’.
En primer lugar, vemos que el host de la aplicación se crea a partir de la clase WebHostBuilder siguiendo el patrón builder que, a grosso modo, consiste en centralizar en un único punto la instancia de un objeto complejo y la configuración de sus características.
Con el host creado, vemos la definición del servidor que se implementará. Por defecto se utiliza Kestrel, y será la que veamos. A saber que Kestrel es un servidor HTTP cross-platform basado en libuv, que es una librería de operaciones I/O asíncronas.
Si nuestra aplicación web va a dar servicio únicamente a redes internas, podemos exponer el servidor HTTP Kestrel tal que así:
Si, por el contrario, nuestra aplicación web va a dar servicio en Internet, se recomienda utilizar un reverse proxy server entre nuestro servidor e Internet, ya que, al ser relativamente nuevo, no cuenta con todas las medidas de seguridad necesarias, aunque incluye las medidas de seguridad básicas.
De esta forma, nos quedaría así:
El método UseStartup especifica la clase de inicio de la aplicación. Por defecto, vemos que se especifica la clase Startup, la cual nos ha creado el VisualStudio automáticamente al crear el proyecto.
La clase Startup.cs configura el request pipeline que manejará todas las peticiones entre el servidor y la aplicación. La clase de inicio tiene que tener un método llamado Configure que será invocado al iniciarse la aplicación y será donde se configure el pipeline.
El request pipeline es una secuencia de componentes de software que se van a ir ejecutando sobre la request y sobre la response de manera secuencial. Cada uno de estos componentes recibe el nombre de middleware y cada uno de ellos es responsable de continuar con la secuencia del pipeline o cortarla. Por este motivo es muy importante el orden en el que configuremos los componentes del pipeline. Por ejemplo, podemos añadir un componente middleware que se encargue de autenticar la request y, en función del resultado de la autenticación, pasar al siguiente componente middleware o cortar en ese punto la ejecución y devolver un error 401: Unauthorized.
El flujo de ejecución que lleva el pipeline es el siguiente:
Los componentes middleware que configuremos en el pipeline pueden ser los ofrecidos por el framework o ser componentes creados por nosotros mismos.
Los siguientes componentes middleware son ofrecidos por el framework:
- Authentication
- CORS
- Response Caching
- Response Compression
- Routing
- Session
- Static Files
- URL Rewriting
Crear un custom middleware es algo muy sencillo. Simplemente tenemos que crear una clase pública que reciba en el constructor un objeto RequestDelegate que nos permita invocar al siguiente componente del pipeline y exponer un método público y asíncrono llamado Invoke que reciba el contexto de la petición para que nos puedan llamar desde el pipeline.
Un ejemplo de custom middleware podría ser el que se expone a continuación:
Nos puede resultar útil crear nuestros propios componentes cuando necesitemos añadir cierta funcionalidad, cambiar el comportamiento de alguno de los componentes que nos ofrece el framework, o necesitemos hacer algo que ningún componente nos ofrece.
Si queréis comentarnos lo que sea podéis hacerlo en info@kabel.es.
También podéis seguirnos en Twitter y LinkedIn.
