Comparatifs de frameworks web à Devoxx 2011

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

The post Devoxx 2011 – Comparatif de performances des frameworks web Java et plus encore … first appeared on In Fine - Le Blog.

Je suis devenu un adepte du framework Play!. Je ne le pratique pas depuis longtemps, seulement depuis 10 mois environ. Mais la courbe d’apprentissage est vraiment rapide. Une semaine est suffisante pour être à l’aise et être autonome. J’ai la modeste prétention, dans cet article, de montrer 2 ou 3 trucs qui font de ce framework une nouvelle manière de voir le web en Java.

Pour commencer, Play! est très simple à installer. Il suffit de décompresser le zip dans un répertoire, et de créer une variable PLAY_HOME qui pointe sur ce répertoire. Play! a uniquement besoin de Java comme pré-requis pour fonctionner. Et c’est tout ! Pour rappel, la plupart des autres frameworks web Java ont au moins besoin d’un serveur d’application…

Comme Play! embarque un serveur web, il se suffit à lui-même. Cette notion est appelée “full-stack”. Elle signifie que Play! est autonome à la fois dans son mode de développement en proposant tout ce qu’il faut pour faire une application web, de la couche présentation à l’accès aux données, et également lors de l’exécution des applications Play! qui tournent grâce au serveur web intégré.

Play! propose de nombreuses fonctionnalités peu répandues dans le monde du web en java. Par exemple, le code modifié est pris à chaud par le serveur web, il suffit de rafraîchir le navigateur pour voir sa modification ! La gestion d’erreur est également poussée. Lorsqu’une exception se produit, l’erreur s’affiche très clairement dans le navigateur. Comme le montre l’image suivante :

Le développement rapide est une des caractéristiques de Play! On passe beaucoup plus de temps à coder qu’à faire de la configuration ou de l’installation. Et ce n’est pas tout, Play! propose beaucoup de moyens d’accélérer le développement. Je vais donc vous en montrer quelques uns. Je ne compte pas énumérer tout ce qui fait que Play! permet de développer rapidement, mais seulement donner un aperçu.
Play! propose sur son site, une documentation très complète, ainsi qu’un tutoriel bien fait qui permet de se familiariser avec les notions principales du framework. Si on peut paraître sceptique devant tant de d’enthousiasme, faire le tutoriel permettra à quiconque de se rendre compte de la rapidité avec laquelle le développement se fait avec Play!.

Arborescence

Ceux qui connaissent Ruby on Rails et Grails ont déjà les bases pour Play!. Par exemple, l’arborescence des répertoires est très similaire :

Les répertoires ont des noms explicites, par exemple le répertoire public permet au serveur web de renvoyer des ressources directement, telles que des images ou des scripts.
Le répertoire conf contient les fichiers de configuration comme son nom l’indique. Par défaut, Play! en crée trois :

• Un pour l’application de l’application et du serveur web
• Un pour définir les URL de l’application
• Un dernier contenant les messages de l’application

D’autres fichiers de configuration peuvent être créer dans ce répertoire, notamment pour chaque langue gérée par votre application.

La puissance dans le fichier de configuration

Application.conf est un fichier similaire à un fichier properties. Il est créé par Play! lors de la création d’une application. Il contient plein de valeurs essentielles pour configurer le serveur web, telles que le port à utiliser, le nom du cookie. Il contient également des propriétés permettant de configurer l’application comme la base de données, la configuration JPA, du cache…

Le gros avantage de ce fichier, est qu’il peut être l’unique fichier de configuration de l’application, et ce quel que soit l’environnement sur lequel est déployé la web app ! En effet Play! intègre un système qui permet de surcharger des valeurs dans le fichier de configuration. Lors du lancement de l’application, il suffit de préciser un paramètre supplémentaire sur la ligne de commande pour choisir les propriétés à appliquer. Comme ce n’est sûrement pas clair, voici un exemple :

%integration.application.mode=dev
%production.application.mode=prod
application.mode=dev

Le fichier ci-dessus est un extrait d’un fichier de configuration application.conf. Il contient 3 fois la même propriété nommée application.mode. Certaines sont suffixées ce qui permet de donner une valeur précise selon si l’application est lancée en intégration ou en production. Par défaut, la valeur sera celle de ligne 3 si le paramètre n’est pas indiqué. C’est super pratique et très bien pensé !

Le rechargement à chaud du code et de la conf

La propriété que j’ai montré dans l’extrait du fichier application.conf dans le paragraphe précédent, est une clé très spéciale, qui permet encore à Play! de se distinguer. Elle permet d’indiquer au framework que l’application est en mode développement ou production. La distinction est très importante pour le développeur, et pour la sécurité de l’application.

Le mode dev permet au développeur un gain de temps maximum. Lors du développement, un changement sur un fichier de code ou de configuration sera pris à chaud par le framework. Un rafraîchissement de la page du navigateur, et c’est pris en compte ! C’est tout simplement du bonheur de développer dans ces conditions.
Le mode production interdit, bien entendu, le rechargement du code à chaud, mais il permet également de précompiler les fichiers java et les fichiers de templates (qui sont les fichiers permettant l’affichage des pages web). Les performances sont donc meilleures en mode production qu’en mode développement.

Sans état !

Play! est un framework sans état. Cela signifie qu’aucune session n’est conservée du côté du serveur. Cette philosophie est à l’opposée de la plupart des frameworks java bâtis sur la norme servlet. Cela permet à Play! de se rapprocher de la philosophie initiale du protocole HTTP où chaque requête est indépendante de la précédente, donc sans état. Le framework sait qui effectue la requête grâce au cookie.
Du côté serveur, il faut donc repenser sa manière de gérer les requêtes sans état. Par exemple, si des objets doivent être stockés pour être utilisés lors des requêtes suivantes, il faudra utiliser un cache ou la base de donnée directement. D’ailleurs à propos du cache, Play! intègre un cache directement basé sur EhCache.
Le fait que Play! soit sans état permet d’avoir une architecture scalable. Cela permet aussi au framework de gérer très facilement les requêtes de type REST qui sont également des requêtes sans état.
Encore une bonne raison d’essayer Play!.

Exemple d’URL de type REST

Allez, je vous donne un exemple de REST implémenté dans Play!. L’exemple suivant permet d’effacer une personne de l’application.
L’unique page de l’application affiche une liste de personnes. La seule action possible est d’en effacer une :

Le fait de cliquer sur le lien delete appelera une URL définie dans le fichier de configuration routes dont voici l’extrait concerné :

DELETE        /person/{id}         Application.deletePerson

Ce fichier définie une URL de type REST. Elle signifie qu’une URL de type /person/348 avec la méthode HTTP DELETE appelera la méthode Application.deletePerson avec le paramètre 348.
Lorsqu’on affiche la page d’accueil, la log indique :

21:00:57,315 INFO  ~ URL called : GET localhost/

Ensuite, une fois que nous cliquons sur le lien delete :

21:06:24,937 INFO  ~ URL called : DELETE localhost/person/2

Evidemment, l’affichage des personnes fonctionne tel qu’attendu :

Le code java est extrêmement simple. Voici la méthode affichant l’URL et la méthode HTTP pour chaque requête HTTP :

@Before
static void printHttpInfos() {
	Logger.info("URL called : %s %s", request.method, request.domain + request.path);
}

Et voici le code java permettant la suppression d’une personne :

public static void deletePerson(long id) {
	Person.<Person> findById(id).delete();
	index();
}

Je ne vais pas vous décrire ce que fait chaque ligne de code. Je voulais simplement montrer à quel point il est facile de faire des choses qui sont plus compliquées sans Play!. Encore une fois, n’hésitez pas à aller faire le tutoriel sur le site de Play!, on y apprend toutes les bases et notamment ce que je viens de vous montrer.

Les tests

Dans un framework moderne, la prise en charge des tests est indispensable, et Play! n’y échappe pas. Les tests Play! sont basés sur deux librairies très connues : JUnit et Selenium.
En lançant le serveur en mode test, les tests peuvent être lancés via une page dédiée sur l’application web. C’est très pratique pour lancer manuellement des tests via le browser.
D’autre part les données de tests peuvent être initialisées grâce à un fichier YAML. Voici le fichier utilisé pour initialiser les données du paragraphe précédent (dans mon cas je l’ai utilisé pour initialiser la base de données de mon application) :

Person(test1):
    firstName: Florian
    lastName: Boulay

Person(test2):
    firstName: Antonio
    lastName: Goncalves

Person(test3):
    firstName: Antoine
    lastName: Ramponi

Play! permet de créer 3 types de tests :

• Les tests unitaires : les classes doivent hériter de la classe UnitTest. C’est l’équivalent d’un test JUnit classique.
• Les tests fonctionnels : les classes doivent hériter de la classe FunctionnalTest. Ce sont des tests d’intégration avec l’application web.
• Les tests de validation : ce sont des tests Selenium.

Les tests fonctionnels

Je vais faire un petit zoom sur les tests dits fonctionnels.

Pour cela j’ai un peu modifié l’exemple utilisé précédemment afin d’avoir plus de cas de tests possibles. La mini application web ne comporte toujours qu’une seule page, mais elle est désormais composée de 2 listes : une liste d’employés disponibles, et une des employés d’astreinte. L’interface ressemble à ceci :

Le fait de cliquer sur on call permet de faire passer la personne d’astreinte en la mettant dans la seconde liste. Le fait de cliquer sur free permet de faire l’inverse.

Comme dit précédemment les classes de test doivent hériter de la classe FunctionnalTest. De plus, le serveur doit être lancé en mode test. Voici un exemple de test fonctionnel permettant de tester l’unique page de cette application. La première méthode teste l’état initial, c’est-à-dire les 3 personnes qui sont présentes dans la liste des employés disponibles. La seconde méthode teste le passage d’une personne de la première liste à la seconde en cliquant sur le lien on call :

public class EmployeesTest extends FunctionalTest {

	@Before
	public void setUp() {
		Logger.debug("Reloading all data");
		Fixtures.deleteAll();
		Fixtures.load("data.yml");
	}

	@Test
	public void testStartState() throws Exception {
		Response response = GET("/");
		// test the 200 status
		assertIsOk(response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		// test that 3 <li> are returned
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antonio Goncalves.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
	}

	@Test
	public void testOnCallPeople() throws Exception {
		// make Antonio Goncalves on call
		Person antonio = Person.find("byFirstName", "Antonio").<Person> first();
		Response response = PUT("/person/onCall/" + antonio.id, "text/html", "");
		// test the 302 response
		assertStatus(302, response);
		String httpBody = getContent(response);
		assertTrue(httpBody.length() == 0);
		java.net.URL locationHeader = new java.net.URL(response.getHeader("location"));
		response = GET(locationHeader.getPath());
		// test the 200 response
		httpBody = getContent(response);
		assertTrue(httpBody.length() > 0);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Florian Boulay.*" +
							"<li>Antoine Ramponi.*" +
							"</ul>", response);
		assertContentMatch("(?s)<ul>\\s*" +
							"<li>Antonio Goncalves.*" +
							"</ul>", response);
	}

}

Voici les quelques logs générées :

00:39:21,725 DEBUG ~ Reloading all data
00:39:21,777 INFO  ~ URL called : GET localhost/
00:39:22,469 DEBUG ~ Reloading all data
00:39:22,505 INFO  ~ URL called : PUT localhost/person/onCall/8
00:39:22,525 INFO  ~ URL called : GET localhost/

L’API simple

Ce qui est très agréable au quotidien avec Play! est la facilité d’utilisation des API disponibles. Je n’ai pas montré beaucoup de code dans cet article, mais vous pouvez constater la simplicité de lecture du code fait avec Play!. Cela permet comme presque tout le reste, d’avoir une marge de progression rapide, d’être opérationnel bien plus vite qu’avec d’autres framework web… Mais tout ça, je l’ai déjà dit. Je vais plutôt vous montrer quelques lignes utilisant l’API de Play!, vous pourrez vous faire une idée bien plus facilement qu’avec un long discours.

// récupérer la requête HTTP courante
Request request = Http.Request.current();

// récupérer l'EntityManager 
EntityManager em = JPA.em();

// faire un appel rapide à un web service
HttpResponse response = WS.url("http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius").get();

// récupérer toutes les entités Person (entité au sens objet du modèle de donnée)
List<Person> findAll = Person.findAll()
// compter le nombre d'entités Person
long count = Person.count();
// faire des requêtes simple sur l'entité Person
List<Person> allAntos = Person.find("byFirstNameLike", "anto%").fetch();
// etc......

Petit mot de la fin

Cet article touche à sa fin. J’aurais tellement voulu vous en montrer plus comme la validation super simple, les templates HTML, comment répondre au client en fonction du format qu’il demande (XML, JSON….), mais c’est déjà assez long. Je profiterai d’un prochain article pour me concentrer sur un aspect plus précis du framework.
J’espère avoir convaincu les quelques sceptiques à propos du framework Play!

Ressources

Site officiel du framework Play! : http://www.playframework.org/
Le google group très actif : http://groups.google.com/group/play-framework
Le repository git du code source de Play! : https://github.com/playframework/play
Le premier livre sur Play! : http://www.the-play-book.co.uk/

The post Ce que j’aime dans Play! first appeared on In Fine - Le Blog.