Uncategorized

Choix du framework (part 2)

Bon hier soir (la nuit dernière) j’ai un peu dérivé de mon objectif qui était de choisir le framework de développement.

Je voulais avoir une big picture de ce qui se fait actuellement sur les sites communautaires / réseaux sociaux / smartphone en terme d’API de communication. C’est sur qu’après 4 ans dans la finance, je n’avais pas trop suivi les grosses tendances de développement distribué (ca ne se fait plus le RMI, xml schema, le SOAP ou le XML/RPC ? :) Les grosses tendances semblent être REST / JSON / Atom / HttpRequest, OAuth, etc… Bon bref c’est pas très important tout ca mais ca m’a permis de voir ce qui se passer et modeler un peu mes besoins.

Retour aux frameworks de développement ce matin donc. Pour résumer pour l’instant j’ai Java et comme hébergement Google App Engine. J’ai passé pas mal d’années sur les framework web (struts, spring mvc, JSP, taglibs, freemarker + de la veille techno:  wicket, JSF, tapestry ) et persistance (jdbc / procedure, ibatis, hibernate, jdo) avec spring pour lier tout ca. Sur le dernier projet, j’ai mis en place une configuration basé sur les annotations (hibernate/spring) et c’était assez convaincant je dois dire (partie présentation avec swing).

Bon maintenant l’objectif est de pondre un truc super rapidement (prototype/crud) mais suffisamment sérieusement pour ne pas avoir à tout refaire quand l’application marchera (si jamais elle marche).

Il y a pas mal de nouvelles technos intéressantes dans le monde java (scala, clojure, groovy) sans parler de ce qui se fait niveau web2 (jQuery, GWT), JRebel (développement à chaud) et la tendance No SQL.

Fred qui bosse dans le monde des jeux vidéos online est un big fan de scala. Par contre ca me semble être un peu un univers a part entière et j’ai un peu peur de la learning curve pour mon projet. A priori, Scala est supporté sur GAE. Bon c’est tentant mais on essaiera ca plus tard.

Pour le no sql, c’est un passage obligé puisque la persistance sur GAE se fait à travers BigTable. Le seul choix est donc JDO ou JPA coté persistance. Pour ceux qui ne savent pas, BigTable est une base de donnée hiérarchique. C’est sans trop de regret que je quitte le SQL ayant passé trop de temps dans les procédures stockées ces dernières années. Et puis j’ai un autre projet en tête que je verrais bien sur une base de données orientées colonnes.

Coté spring, j’ai vu des solutions intéressantes pour mobile (voir post précédent). Mon soucis est plutôt le cout en temps de la mise en place (note: j’aurais pu utiliser spring roo mais voir note en bas du post). Et puis c’est un framework que je connais trop bien, j’ai envie de passer à autre chose notamment tester un framework a la ruby on rails (convention plutôt que configuration)  et des langages dynamiques.

Le candidat est donc tout choisi (la recherche est terminée on pourrait dire): Grails. Réponse Java à RoR avec du Groovy inside. Ca semble pas mal. Initialement conçu pour tourner avec hibernate (qui lui ne tourne que sur des bases SQL), une couche d’abstraction a été ajoutée pour faire du JDO/JPA (GORM). J’ai fait quelques recherche, ca semble pas trop mal tourner sur Google App Engine (GAE) et même sur Amazon Web Services (AWS). Et ca s’est faire du REST et du GWT. Bonheur

Bon on va partir la dessus, on verra bien. Ci dessous quelques guides qui pourront m’être utile.

Next step installation de l’environnement de développement.

En écrivant la liste de site, je me suis dit et pourquoi pas spring roo ? Grosso modo roo est un générateur d’application spring. Il y a tout ce qui faut pour faire une application dans le cloud. Les grosses différences étant java vs groovy et configuration vs convention. Je reste donc sur grails…

Je suis tombé également sur quelques articles parlant de problème de performance avec GAE sur java. A priori, cela semble du à l’instanciation de nouvelle jvm ou le démarrage (warmup d’une application). Google vient de sortir la version 1.4 de GAE qui semble offrir des solutions à ses problèmes de performances.