Nuestra empresa lleva más de 12 años desarrollando software. Y alrededor de la mitad de nuestros proyectos son sistemas distribuidos multihilo de alta carga. Por lo tanto, nuestros desarrolladores utilizan las tecnologías más avanzadas y los últimos frameworks en el proceso
En este artículo, nos centraremos en dos frameworks recientes, mencionados en Play, y en ASP.NET Web API.
Marco de trabajo Play
Últimamente se ha prestado mucha atención a Play Framework 2.x. Ya han pasado tres años desde que Redwerk implementó por primera vez Play para Java. Al tener una amplia experiencia con Play, intentaremos presentarle una breve pero completa visión general de todas las ventajas de este framework
Los desarrolladores de Play describen su framework con una frase: “El framework web de alta velocidad para Java y Scala”. En la actualidad, este marco se considera como una pila completa y consta de varias “capas”.
Herramientas para el despliegue y la gestión de dependencias
Al igual que Django, Ruby on Rails y otros frameworks multifuncionales, Play viene con un conjunto de utilidades reunidas en TypeSafe Activator, un servicio para la gestión y creación de aplicaciones Reactivas. Activator incluye una sencilla herramienta de construcción, una interfaz gráfica de usuario de inicio rápido y un catálogo de plantillas de aplicaciones ya hechas.
Sus principales características son
- Compilación incremental
- Sistema de documentación de código incorporado
- Sistema de plantillas y plugins
- Servidor web incorporado para el desarrollo
- Amplia funcionalidad de depuración
- Excelente marco para la creación de pruebas unitarias Specs2
- Soporte completo de desarrollo de servicios RESTful
- Sistema de gestión de dependencias de código
- Integración con los principales IDE
También queremos destacar la posibilidad de establecer la actualización automática de los plugins elegidos en la versión de configuración de Activator y Scala, así como la gran variedad de plugins disponibles. Tanto Scala como Play trabajan en la plataforma Java, por lo que todas las dependencias externas se extraen de un repositorio estándar de Maven. Por supuesto, también puede añadir repositorios personalizados
Servidor HTTP Netty
Los desarrolladores de Play ya no utilizan el modelo JEE junto con los servlets, sino que optan por Netty, que es un servidor de red NIO avanzado. Como resultado, Play representa una capa web que no almacena ni comparte el estado (stateless web tier), lo que es muy importante para los servicios web multihilo de alta carga. Además, el marco soporta las últimas tecnologías como la E/S sin bloqueo y el soporte de comunicación en tiempo real (Websockets, EventSource, Comet). Además, Play proporciona unas opciones de configuración muy flexibles que incluyen pools de hilos: un número de trabajadores y factores de paralelismo.
También queremos señalar que Play representa un conjunto completo de herramientas para la creación de aplicaciones reactivas utilizando Akka Framework que está construido sobre el concepto de hilos verdes y tiene las nociones de Actor y Futuro en su núcleo. Por ello, se dedica todo un capítulo de la documentación al método de desarrollo de código sin bloqueo. Hay descripciones de los principales casos de bloqueo de código como la BD, la solicitud de API de terceros, el trabajo con archivos y las operaciones intensivas de la CPU. Esto se hace para ayudar a los desarrolladores a minimizar el uso de código bloqueante en sus proyectos.
Modelo de datos
OOB Play tiene un marco ORM incorporado, EBean. Lo hemos utilizado en nuestros proyectos varias veces y hemos quedado muy satisfechos con los resultados. Es mucho más fácil que JPA y sus realizaciones como Hibernate tanto en el aprendizaje como en el desarrollo. Además, Play viene con el mecanismo incorporado de migración de esquema de BD “Evolutions” que resultó ser una solución fantástica. En una aplicación, supervisa automáticamente la carpeta conf/evolutions/ en lo que respecta a los nuevos scripts del esquema de actualización-desactualización de la BD (archivos *.sql). Cuando se detecta una nueva evolución, el marco de trabajo pregunta al desarrollador si se debe enrollar una nueva evolución o no. Para que el script de evolución funcione, el desarrollador sólo tiene que hacer clic en “Aplicar script”. Todo lo anterior garantiza la validez de los datos y la correspondencia entre el código y el modelo de datos. Es primordial, ya que el desarrollo moderno se realiza normalmente en varias ramas, y hay que cambiar entre ellas muy a menudo.
Tenga en cuenta que, gracias a la estructura de módulos, puede utilizar fácilmente marcos ORM externos, como Slick, que es la biblioteca de bases de datos más recomendada para Scala. Slick es un marco fantástico, ya que en lugar de peticiones HSQL o toneladas de anotaciones para trabajar con DB. Utiliza código nativo de Scala. Así, una selección de la DB con filtros es similar al código que trabaja con una colección simple como List o Map. Más detalles sobre slick se pueden encontrar en su documentación oficial aquí
Play Web API
Cuando empezamos a utilizar Play Web API, esperábamos ver una gran variedad de filtros, toneladas de anotaciones, enrutamiento complejo, configuraciones XML y excepciones con muchas líneas innecesarias como en Spring Framework. Pero para nuestra alegría, todo era diferente. Deje atrás todas sus preocupaciones, ya que todo eso forma parte del pasado.
Lo primero es lo primero: Play Framework 2.x está escrito en el lenguaje de programación Scala, lo que ya es un gran paso. Basta con echar un vistazo a la extensa lista de empresas que utilizan Scala en el entorno de producción.
El núcleo de Play está construido sobre otros dos frameworks de vanguardia: Akka actors y Netty network stack. Ambos se ciñen al estilo de desarrollo funcional y a técnicas punteras como la inmutabilidad del estado, los bucles de eventos, el paso de mensajes, la composición de comportamientos y las funciones de primera clase. Por ello, Play es uno de los frameworks más progresistas gracias a sus características y velocidad de funcionamiento.
El mecanismo de rutas en Play es bastante simple pero de la más alta calidad. Todas las rutas se reúnen en un archivo conf/routes. El formato de la configuración es el siguiente: el controlador y su método, la URL a la que se vincula y una lista de parámetros necesarios con sus tipos de datos. También puede especificar los parámetros innecesarios.
Plantillas Scala de Play. Los desarrolladores de Play no crearon un lenguaje separado para las plantillas o las bibliotecas de etiquetas. Esto les permitió comprender y empezar a utilizar las plantillas Scala al desarrollar páginas HTML responsivas. Los principios generales se tomaron prestados de la tecnología ASP.NET Razor. Tendemos a pensar que es mejor utilizar un enfoque declarativo para el desarrollo de código para la vista. Pero tenemos que admitir que el motor de plantillas Scala está repleto de soluciones potentes y flexibles como los bloques, la decoración implícita de campos de formulario y las composiciones de vistas.
También cabe mencionar que OOB Play ofrece soporte de contenido JSON y XML. El soporte JSON se ha realizado utilizando la biblioteca Jackson. Es importante que el soporte XML no es tan grande como el de Spring MVC, por lo que tendrá que utilizar librerías externas. El formato XML se utiliza raramente para la comunicación en los nuevos proyectos, y los datos se serializan/deserializan en JSON.
Teniendo en cuenta todo lo anterior, se puede decir que Play es un candidato casi perfecto para el desarrollo de un servicio API REST, un pequeño portal o un servicio web de alta carga. En el caso de este último, siempre puede utilizar Akka Cluster y el número necesario de DGC para el mantenimiento del tráfico.
Creemos que las ventajas son las siguientes:
- Marco simple RESTful
- Estructura de módulos con una oportunidad de gestión de dependencias sencilla
- Varias oportunidades OOB: ORM, programador de trabajos, validación, correo SMTP, soporte de JSON y XML, soporte de evolución de la BD, carga automática de archivos, soporte de SSL, etc.
- Marco incorporado para las pruebas
- Soporte completo de tecnologías reactivas, controladores sin estado
- Potente marco de plantillas
- rendimiento sin concesiones
- adquisición y configuración sencillas
- soporte de varias configuraciones tanto para el desarrollo como para el despliegue en el entorno de producción.
Pero también nos gustaría mencionar algunas desventajas:
- Largo proceso de compilación del proyecto debido a un SBT bastante lento
- Escaso soporte de Windows como plataforma de desarrollo equivalente
La experiencia en el uso de Play Framework ha demostrado que es uno de los frameworks universales más prometedores y altamente eficientes. Los desarrolladores de Java/Scala de la empresa Redwerk recomiendan utilizar una combinación de Scala + Play + Slick + Akka para nuevos proyectos como el servicio Rest API o el portal de alta carga.
API web ASP.NET
Vamos a intentar encontrar una forma alternativa de desarrollar servicios web basados en .NET para Windows. Anteriormente, cuando queríamos desarrollar un servicio web RESTful utilizando las herramientas de MS .NET, podíamos optar por los servicios web ASMX o implementar REST con la ayuda de las tecnologías WCF. Pero ahora, tras el lanzamiento de una nueva versión de la plataforma .NET, la 4.5, el desarrollador dispone de una nueva herramienta para el desarrollo de servicios RESTful: ASP.NET Web API. Se trata de un marco de trabajo para WEB construido sobre el HTTP que permite el desarrollo de servicios REST utilizando convenciones comunes y un concepto de software similar de forma rápida y cómoda. La esencia de un nuevo marco es innovadora para la plataforma .NET en general, pero fue implementada previamente en numerosos marcos web como Django, Lift, Play Framework, Ruby on Rails, Spring Framework, etc. También queremos señalar que Web API no es un marco estructural universal como los mencionados anteriormente. Está personalizado específicamente para REST. Por eso intentaremos compararlo con Play Framework en la próxima parte.
Echemos un vistazo a la parte técnica para ver las principales mejoras. Como el framework es bastante pequeño, le daremos los ejemplos de código para una mejor comprensión.
La estructura general del proyecto de la API web .NET
El proyecto basado en la plantilla de la API web .NET puede desarrollarse a través del menú de Microsoft Visual Studio añadiéndolo a una solución existente. Como resultado, obtendremos un proyecto MVC con una estructura estándar. Por defecto, se crearán dos controladores. Serán diferentes de los controladores normales ya que utilizan la clase básica ApiController que no está conectada a una clase básica Controller normal. Los controladores pueden utilizar la estilística REST con el soporte de los métodos GET, POST, PUT, DELETE. No hay métodos estándar de los controladores que devuelvan ActionResult. He aquí un ejemplo de código autogenerado:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | public class NumbersController: ApiController { // GET api/numbers public IEnumerable Get() { return new string[] { "number1", "number2" }; } // GET api/numbers/5 public string Get(int id) { return "number"; } // POST api/numbers public void Post([FromBody] string newNumber) {} } |
Enrutamiento en la API web
Dado que los métodos de las clases se asignan a los tipos de solicitud REST pertinentes con una indicación del método HTTP, el formato de la URL y el tipo de contenido, el enrutamiento junto con los controladores no es estándar. Puede encontrar una lista y definiciones de rutas para los controladores de la API Web en el archivo WebApiConfig.cs de la carpeta App_Start.
Veamos un ejemplo de dicho archivo:
1 2 3 4 5 6 7 8 9 10 11 12 13 | public static class WebApiConfig { public static void Register(HttpConfiguration config) { config.Routes.MapHttpRoute( name: "MyNewWebApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); } } |
Como puede ver en la lista anterior hemos definido una ruta. El primer parámetro es el nombre de la ruta, el segundo es el mapeo del controlador, el tercero es un id de objeto específico (el tercer parámetro es opcional en este caso).
Funciones adicionales de la API web
Para demostrar todas las posibilidades del framework, veamos un ejemplo de un controlador más complicado:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | public class BooksController: ApiController { [Queryable] public IQueryable Get() { return new EnumerableQuery ( new Collection { new Book { Id = 1, Title = "Tittle1" }, new Book { Id = 2, Title = "Tittle2" }, new Book { Id = 3, Title = "Tittle3" }, new Book { Id = 4, Title = "Tittle4" }, new Book { Id = 5, Title = "Tittle5" } } ); } } |
Puede ver en el código anterior que ahora podemos devolver una colección de instancias desde el controlador. Además, la clase IQueryable y el atributo del método del controlador [Queryable] forman parte de una nueva biblioteca OData. La aplicación de esta biblioteca nos permite crear peticiones con un filtro de colección de tipos.
1 2 3 4 5 | http://localhost/api/books/?$skip=25 http://localhost/api/books/?$skip=25&$top=10 http://localhost/api/books/?$filter=(Id gt 20) and (Id lt 50)&$orderby=Id desc |
Creo que no es necesario explicar lo que hace la primera petición
Sin embargo, por desgracia, como suele ocurrir con Microsoft, aparte de las numerosas bondades sintácticas y las grandes innovaciones, hay un pequeño fallo. Por ahora la biblioteca OData no contiene el parámetro count en la respuesta, por lo tanto, es problemático construir una paginación completamente funcional basada en la UI. Los desarrolladores tendrán que ajustar varias clases de la biblioteca según sus necesidades. Puede encontrar cómo hacerlo aquí.
Conclusión
el marco de la API web de .NET es una herramienta excelente para los desarrolladores de .NET. Este marco les permite crear servicios más flexibles y una arquitectura de aplicaciones mucho más sencilla, y al mismo tiempo utilizar todas las ventajas de la plataforma .NET en el código. También simplifica el desarrollo y las pruebas de las aplicaciones REST en general.
Si se comparan las posibilidades de Play Framework y de .NET Web API, se observa que el primero es más potente e implementa todas las tecnologías punteras del procesamiento de peticiones asíncronas. Play Framework es un marco estructural, por lo que contiene varias características a todos los efectos. el marco de la API Web de .NET, a su vez, está dotado de herramientas específicas para la estructura REST, pero también permite utilizar todas las características de la plataforma .NET.
Hablando de la eficiencia, el marco de trabajo Play con el servidor Netty está varios pasos por delante de la mayoría de los marcos de trabajo, incluyendo la API Web .NET. Entre otras ventajas de .NET Web API, nos gustaría señalar las amplias oportunidades de la biblioteca OData OOB – parámetros de solicitud que garantizan el filtrado de datos y la navegación de recogida de datos.
Es usted quien decide qué tecnología utilizar. Los empleados de Redwerk tienen décadas de experiencia en el desarrollo y mantenimiento de proyectos tanto para plataformas .NET como J2EE. Por lo tanto, sea cual sea la tecnología que elija, nuestros especialistas pueden garantizar la máxima calidad del trabajo dentro de unos plazos razonables.
Acerca de Redwerk
Redwerk es una empresa de externalización de TI que lleva más de 13 años ofreciendo productos de software de alta calidad en todo el mundo. Nuestras oficinas están llenas de desarrolladores de software de subcontratación con gran experiencia en el trabajo con diversas tecnologías móviles, web, de escritorio y en la nube, siendo el desarrollo de software Scala una de nuestras principales direcciones. Y nuestros expertos en desarrollo ASP.NET implementan soluciones cliente-servidor de cualquier complejidad. Póngase en contacto con nosotros si no puede decidir qué tecnología quiere utilizar para su proyecto. Le ayudaremos a crear un producto a medida con respecto a todos sus requisitos.