Notre entreprise développe des logiciels depuis plus de 12 ans. Et environ la moitié de nos projets sont des systèmes distribués multithread à forte charge. Par conséquent, nos développeurs utilisent des technologies de pointe et les derniers frameworks dans ce processus.
Dans cet article, nous allons nous concentrer sur deux frameworks récents mentionnés : Play et ASP.NET Web API.

Play Framework
Récemment, une grande attention a été portée au Play Framework 2.x. Cela fait déjà trois ans que Redwerk a implémenté Play pour Java pour la première fois. Forts de notre expérience avec Play, nous allons tenter de vous présenter un aperçu court mais complet de tous les avantages de ce framework.
Les développeurs de Play décrivent leur framework en une phrase : « Le framework web à haute vélocité pour Java et Scala ». Aujourd’hui, ce framework est considéré comme un framework full stack et se compose de plusieurs « couches ».
Outils de déploiement et de gestion des dépendances
Tout comme Django, Ruby on Rails et d’autres frameworks multifonctionnels, Play est livré avec un ensemble d’utilitaires regroupés dans TypeSafe Activator, un service de gestion et de création d’applications réactives. Activator comprend un outil de compilation simple, une interface graphique de démarrage rapide et un catalogue de modèles d’applications prêts à l’emploi.
Ses principales caractéristiques sont :
- Compilation incrémentielle
- Système de documentation de code intégré
- Système de modèles et de plugins
- Serveur web intégré pour le développement
- Large fonctionnalité de débogage
- Excellent framework pour la création de tests unitaires Specs2
- Prise en charge complète du développement de services RESTful
- Système de gestion des dépendances de code
- Intégration avec les IDE leaders
Nous souhaitons également souligner la possibilité de configurer les mises à jour automatiques pour les plugins choisis dans la version de configuration d’Activator et de Scala, ainsi que la grande variété de plugins disponibles. Scala et Play fonctionnent sur la plateforme Java, de sorte que toutes les dépendances externes sont tirées d’un dépôt Maven standard. Bien sûr, vous pouvez également ajouter des dépôts personnalisés.
Serveur HTTP Netty
Les développeurs de Play n’utilisent plus le modèle JEE avec les servlets, mais préfèrent Netty, un serveur réseau NIO avancé. Par conséquent, Play représente une couche web qui ne stocke ni ne partage d’état (couche web sans état), ce qui est très important pour les services web multithread à forte charge. De plus, le framework prend en charge les dernières technologies comme l’E/S non bloquantes et le support de la communication en temps réel (Websockets, EventSource, Comet). De plus, Play offre des options de configuration très flexibles, y compris les pools de threads : nombre de workers et facteurs de parallélisme.
Nous aimerions également souligner que Play représente un ensemble complet d’outils pour la création d’applications réactives en utilisant le Akka Framework, qui est basé sur le concept de threads verts et dont le cœur repose sur les notions d’Acteur et de Future. C’est pourquoi tout un chapitre de la documentation est consacré à la méthode de développement de code non bloquant. Il y a des descriptions des principaux cas de blocage de code comme la base de données, les requêtes API tierces, le travail avec des fichiers et les opérations intensives sur le processeur. Ceci est fait pour aider les développeurs à minimiser l’utilisation de code bloquant dans leurs projets.
Modèle de données
Play inclut nativement un framework ORM, EBean. Nous l’avons utilisé dans nos projets plusieurs fois et en avons été très satisfaits. Il est beaucoup plus simple que JPA et ses implémentations comme Hibernate, tant pour l’apprentissage que pour le développement. De plus, Play est livré avec le mécanisme de migration de schéma de base de données « Evolutions » qui s’est avéré être une solution fantastique. Dans une application, il surveille automatiquement le dossier conf/evolutions/ concernant les nouveaux scripts de mise à niveau/rétrogradation du schéma de base de données (*.sql files). Lorsqu’une nouvelle évolution est détectée, le framework demande au développeur si une nouvelle évolution doit être appliquée ou non. Pour aider le script d’évolution à fonctionner, le développeur n’a qu’à cliquer sur « Appliquer le script ». Tout ce qui précède garantit la validité des données et la correspondance entre le code et le modèle de données. C’est primordial, car le développement moderne se déroule normalement sur plusieurs branches, et il faut souvent basculer entre elles.
Notez que grâce à sa structure modulaire, vous pouvez facilement utiliser des frameworks ORM externes comme Slick, qui est la bibliothèque de base de données la plus recommandée pour Scala. Slick est un framework fantastique, car il n’utilise pas des requêtes HSQL ou des tonnes d’annotations pour travailler avec la base de données. Il utilise du code Scala natif. Ainsi, une sélection depuis la base de données avec des filtres ressemble au code qui fonctionne avec une simple collection comme List ou Map. Vous trouverez plus de détails sur Slick dans leur documentation officielle ici.
Play Web API
Lorsque nous avons commencé à utiliser Play Web API, nous nous attendions à voir une grande variété de filtres, des tonnes d’annotations, un routage complexe, des configurations XML et des exceptions avec de nombreuses lignes inutiles comme dans Spring Framework. Mais à notre grande joie, tout était différent. Laissez toutes vos inquiétudes derrière vous, car elles appartiennent au passé maintenant.
Tout d’abord, Play Framework 2.x est écrit en langage Scala, ce qui est déjà un grand pas. Jetez un œil à la liste exhaustive des entreprises qui utilisent Scala dans un environnement de production.
Le cœur de Play est construit sur deux autres frameworks de pointe : Akka actors et Netty network stack. Les deux développeurs adhèrent au style de développement fonctionnel et aux techniques de pointe comme l’immutabilité des états, les boucles d’événements, le passage de messages, la composition de comportements, les fonctions de première classe. C’est pourquoi Play est l’un des frameworks les plus progressistes grâce à ses fonctionnalités et sa vitesse d’exécution.
Le mécanisme de routage dans Play est assez simple mais de la plus haute qualité. Toutes les routes sont rassemblées dans un seul fichier conf/routes. Le format de configuration est le suivant : le contrôleur et sa méthode, l’URL à laquelle il est lié, et une liste de paramètres requis avec leurs types de données. Vous pouvez également spécifier des paramètres facultatifs.
Modèles Scala de Play. Les développeurs de Play n’ont pas créé de langage séparé pour les modèles ou les bibliothèques de balises. Cela leur a permis de comprendre et de commencer à utiliser les modèles Scala lors du développement de pages HTML réactives. Les principes généraux ont été empruntés à la technologie ASP.NET Razor. Nous pensons qu’il est préférable d’utiliser une approche déclarative pour le développement de code pour la vue. Mais nous devons admettre que Scala Templates Engine est doté de solutions puissantes et flexibles comme les blocs, la décoration implicite des champs de formulaire et les compositions de vues.
Il convient également de mentionner que Play offre nativement un support de contenu JSON et XML. Le support JSON a été réalisé à l’aide de la bibliothèque Jackson. Il est important de noter que le support XML n’est pas aussi performant que celui de Spring MVC, vous devrez donc utiliser des bibliothèques externes. Le format XML est rarement utilisé pour la communication dans les nouveaux projets, et les données sont sérialisées / désérialisées en JSON.
Compte tenu de tout ce qui précède, Play peut être qualifié de candidat presque parfait pour le développement de services REST API, de petits portails ou de services Web à forte charge. Dans le cas de ces derniers, vous pouvez toujours utiliser Akka Cluster et le nombre nécessaire de GCD pour la maintenance du trafic.
Nous pensons que les avantages sont les suivants :
- Framework RESTful simple
- Structure modulaire avec possibilité de gestion simple des dépendances
- Diverses opportunités natives : ORM, planificateur de tâches, validation, email SMTP, support JSON et XML, support d’évolution de base de données, téléversement automatique de fichiers, support SSL, etc.
- Framework intégré pour les tests
- Prise en charge complète des technologies réactives, contrôleurs sans état
- Framework de modèles puissant
- performances intransigeantes
- acquisition et configuration simples
- prise en charge de plusieurs configurations à la fois pour le développement et le déploiement en environnement de production.
Mais nous aimerions également mentionner quelques inconvénients :
- Long processus de compilation des projets en raison de SBT plutôt lent
- Faible prise en charge de Windows en tant que plateforme de développement équivalente
L’expérience d’utilisation de Play Framework a montré qu’il s’agit de l’un des frameworks universels les plus prometteurs et les plus efficaces. Les développeurs Java/Scala de la société Redwerk recommandent l’utilisation d’une combinaison de Scala + Play + Slick + Akka pour de nouveaux projets comme les services Rest API ou les portails à forte charge.

ASP.NET Web API
Essayons de trouver une méthode alternative pour développer des services web basés sur .NET pour Windows. Auparavant, lorsque nous voulions développer un service web RESTful à l’aide des outils MS .NET, nous pouvions soit opter pour les services web ASMX, soit implémenter REST à l’aide des technologies WCF. Mais maintenant, après la sortie d’une nouvelle version de la plateforme .NET, 4.5, un développeur dispose d’un nouvel outil pour le développement de services RESTful — ASP.NET Web API. Il s’agit d’un framework pour le WEB basé sur HTTP, permettant le développement de services REST en utilisant des conventions communes et un concept logiciel similaire de manière rapide et pratique. L’essence du nouveau framework est innovante pour la plateforme .NET en général, mais elle a été précédemment implémentée dans de nombreux frameworks web comme Django, Lift, Play Framework, Ruby on Rails, Spring Framework, etc. Nous souhaitons également souligner que Web API n’est pas un framework structurel universel comme ceux mentionnés ci-dessus. Il est spécifiquement adapté à REST. C’est pourquoi nous essaierons de le comparer à Play Framework dans la partie suivante.
Examinons de plus près l’aspect technique pour voir les principales améliorations. Le framework étant plutôt petit, nous vous donnerons des exemples de code pour une meilleure compréhension.
La structure générale d’un projet .NET Web API
Un projet basé sur le modèle .NET Web API peut être développé via le menu Microsoft Visual Studio en l’ajoutant à une solution existante. En conséquence, nous obtiendrons un projet MVC avec une structure standard. Par défaut, deux contrôleurs seront créés. Ils seront différents des contrôleurs ordinaires car ils utilisent la classe ApiController de base qui n’est pas connectée à une classe Controller de base ordinaire. Les contrôleurs peuvent utiliser la stylistique REST avec la prise en charge des méthodes GET, POST, PUT, DELETE. Il n’y a pas de méthodes standard de contrôleurs qui retournent ActionResult. Voici un exemple de code autogénéré :
public class NumbersController: ApiController {
// GET api/numbers
public IEnumerable < string > 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) {}
}
Routage dans Web API
Étant donné que les méthodes de classe sont mappées aux types de requêtes REST pertinents avec une indication de la méthode HTTP, du format de l’URL et du type de contenu, le routage ainsi que les contrôleurs ne sont pas standard. Une liste et les définitions des routes pour les contrôleurs Web API se trouvent dans le fichier WebApiConfig.cs dans le dossier App_Start.
Jetons un coup d’œil à un exemple d’un tel fichier :
public static class WebApiConfig {
public static void Register(HttpConfiguration config) {
config.Routes.MapHttpRoute(
name: "MyNewWebApi",
routeTemplate: "api/{controller}/{id}",
defaults: new {
id = RouteParameter.Optional
});
}
}
Comme vous pouvez le voir d’après ce qui précède, nous avons défini une route. Le premier paramètre est le nom de la route, le second est le mappage du contrôleur, le troisième est un objet id spécifique (le 3ème paramètre est facultatif dans ce cas).
Fonctionnalités supplémentaires de Web API
Pour démontrer toutes les possibilités du framework, jetons un coup d’œil à un exemple de contrôleur plus complexe :
public class BooksController: ApiController {
[Queryable] public IQueryable < Book > Get() {
return
new EnumerableQuery < Book > (
new Collection < Book > {
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"
}
});
}
}
Vous pouvez voir dans le code ci-dessus que nous pouvons maintenant retourner une collection d’instances à partir du contrôleur. De plus, la classe IQueryable et l’attribut de méthode de contrôleur [Queryable] font partie de la nouvelle bibliothèque OData. L’application de cette bibliothèque nous permet de créer des requêtes avec un filtre de type collection.
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
Je pense qu’il n’est pas nécessaire d’expliquer ce que fait la première requête.
Cependant, malheureusement, comme cela arrive souvent avec Microsoft, en plus de nombreuses subtilités syntaxiques et de grandes innovations, il y a un petit défaut. Pour l’instant, la bibliothèque OData ne contient pas de paramètre count dans la réponse, il est donc problématique de construire une pagination entièrement fonctionnelle basée sur l’interface utilisateur. Les développeurs devront ajuster plusieurs classes de la bibliothèque selon leurs besoins. Vous pouvez trouver comment le faire ici.
Conclusion
Le framework .NET Web API est un excellent outil pour les développeurs .NET. Ce framework leur permet de créer des services plus flexibles et une architecture d’application beaucoup plus simple, tout en exploitant tous les avantages de la plateforme .NET dans le code. Il simplifie également le développement et le test des applications REST en général.
En comparant les opportunités de Play Framework et de .NET Web API, vous constaterez que le premier est plus puissant et implémente toutes les technologies de pointe du traitement des requêtes asynchrones. Play Framework est un framework structurel, il contient donc diverses fonctionnalités pour toutes les intentions et tous les objectifs. Le framework .NET Web API, quant à lui, est spécifiquement conçu pour la structure REST mais permet également d’utiliser toutes les fonctionnalités de la plateforme .NET.
En termes d’efficacité, Play Framework avec le serveur Netty a plusieurs longueurs d’avance sur la plupart des frameworks, y compris .NET Web API. Parmi les autres avantages de .NET Web API, nous tenons à souligner les larges opportunités de la bibliothèque OData native – les paramètres de requête qui assurent le filtrage des données et la navigation dans les collections de données.
C’est à vous de décider quelle technologie utiliser. Les employés de Redwerk ont des décennies d’expérience dans le développement et la maintenance de projets sur les plateformes .NET et J2EE. Ainsi, quelle que soit la technologie que vous choisiriez, nos spécialistes peuvent garantir la plus haute qualité de travail dans des délais raisonnables.
À propos de Redwerk
Redwerk est une société d’externalisation informatique qui livre des produits logiciels de haute qualité dans le monde entier depuis plus de 13 ans. Nos bureaux regorgent de développeurs de logiciels en externalisation très expérimentés dans le travail avec diverses technologies mobiles, web, desktop et cloud, avec le développement de logiciels Scala comme l’une de nos principales orientations. Et nos experts en développement ASP.NET implémentent des solutions client-serveur de toute complexité. Contactez-nous si vous ne parvenez pas à décider quelle technologie utiliser pour votre projet. Nous vous aiderons à créer un produit personnalisé en tenant compte de toutes vos exigences.