Étiquette : App Engine

Google App Engine est une plateforme vraiment sympa. En plus d’être multi-langage (Python, Java, Go et Php), App Engine fournit tout un tas de services appréciables, tels qu’un DataStore intégré, un BlobStore, une gestion de Cache, un service d’envoi de mail et j’en passe… Retrouvez la liste complète ici : https://developers.google.com/appengine/docs/java/apis

Bref, C’est un PAAS complet et performant, qui a fait ses preuves en production.

Mais parlons maintenant de confort de développement.

Je suis développeur Java, et j’essaye autant que possible d’avoir des projets standardisés autour d’un outil de build, au hasard Maven. A priori, tout va bien, Google fournit le plugin qui va bien. Si l’on suit les instructions et que l’on construit correctement son projet, tout devrait bien se passer. Plus qu’à lancer en local mon serveur et ses services associés :

mvn appengine:devserver

Mon projet se build, mon serveur se lance, ma jolie page HTML s’affiche, je suis content !

Habitude oblige, je laisse mon serveur tourner et je commence à modifier mes pages HTML. Sauvegarde, F5, et……. rien. Ma page n’est pas actualisée. Pourquoi ? Et bien le serveur App Engine qui est lancé se base sur votre dossier target généré par Maven. Et sans nouveau build, aucune raison que ce dossier n’évolue.

Alors comment faire pour profiter des fonctionnalités App Engine (datastore par exemple) en local, tout en pouvant développer son Front-End confortablement ?

L’objectif est d’arriver à découpler le Front et le Back End… Le serveur App Engine, qui contient les fonctionnalités du back-end qui nous intéressent, pourra être lancé une fois à l’aide de Maven, disons sur le port 8000. Pour configurer le port, il suffit de changer votre POM :

<plugin>
   <groupId>com.google.appengine</groupId>
   <artifactId>appengine-maven-plugin</artifactId>
   <version>${appengine.target.version}</version>
   <configuration>
     <port>8000</port>
   </configuration>
 </plugin>

Maintenant, nous allons ajouter un serveur qui nous servira le front, par exemple Jetty. Hop, on alimente le POM.xml avec le plugin qui va bien :

<plugin>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-maven-plugin</artifactId>
   <version>9.0.3.v20130506</version>
 </plugin>

On lance notre Jetty (qui lui se lancera sur le port 8080)

mvn jetty:run

On ouvre notre navigateur favori, on va sur localhost:8080 pour attaquer notre Jetty et si tout s’est bien passé, le site apparaît… On modifie l’index.html (par exemple), on sauvegarde, F5 sur le navigateur, et la modification est bien prise en compte, ouf !

Problématique : à un moment, votre front va vouloir parler au back, par exemple à travers une requête REST, L’objectif est donc d’appeler son serveur App Engine, qui se trouve sur un autre port. On fait un petit Hack dans son code Javascript pour appeler la bonne URL, on lance sa requête, et…. Erreur dans le navigateur, Requête Cross Domain non autorisée. Et oui, un navigateur ne lance pas de requêtes vers un autre site, question de sécurité ! Pour Chrome, il existe une solution simple, le lancer avec l’option

--disable-web-security

Mais ce n’est pas l’idéal. Pourquoi ? D’abord parce que cela compromet votre navigateur si vous l’utilisez pour vous balader sur le net. La seconde raison est que de toute façon ça vous oblige à avoir un petit hack dans votre code côté client pour faire pointer vos requêtes vers le bon port.

La Solution ? Apache 2 et un Reverse Proxy

Alors comment faire ? Ma solution est d’avoir un troisième serveur, en frontal, qui va décider vers qui envoyer vos requêtes vers App Engine ou Jetty. Pour ma part j’ai choisi Apache2 et son module Proxy / Reverse Proxy qui fait ça très bien. (Documentation officielle : http://httpd.apache.org/docs/current/mod/mod_proxy.html )

Pour résumer ma configuration Apache 2 : Un fichier apache2.conf qui écoutera le port 80

Listen 80

Et la définition d’un site (il faudra avoir chargé les modules adequat auparavant, cf documentation officielle) :

<VirtualHost localhost:80>
   ServerAdmin webmaster@localhost
   ServerName localhost

   ProxyRequests Off
   ProxyVia Off

   ProxyPass /_ah http://localhost:8000/_ah
   ProxyPassReverse /_ah http://localhost:8000/_ah

   ProxyPass / http://localhost:8080/ 
   ProxyPassReverse / http://localhost:8080/
</VirtualHost>

Maintenant, quand avec mon navigateur je vais sur http://localhost/, Je sais que toutes mes requêtes REST qui sont préfixées par « _ah » sont redirigées vers App Engine sur le port 8000 par le reverse proxy, le reste allant vers Jetty.

Mission accomplie 🙂

Conclusion

On résume.
J’ai un Apache frontal qui dispatch mes requêtes vers Jetty ou App Engine en filtrant les URL appelés grâce à un Reverse Proxy.

OK, j’entends d’ici la critique : il faut vraiment lancer 3 serveurs différents pour pouvoir développer confortablement un simple site Web hébergé sur App Engine ? Prenons le temps de relativiser, et intégrons le fait qu’App Engine transporte avec lui sa persistence, c’est déjà un service d’économisé.

Dans mon exemple, j’aurais pu aussi éviter de devoir lancer Jetty. En effet, si mon front-end est 100% statique, aucune JSP à compiler ni rien, je pourrais demander à Apache de me restituer directement mes fichiers statiques en configurant un Directory qui pointe vers mon projet dans le VirtualHost. Qui plus, mon Apache est démarré comme service, et une fois lancé il est fait pour être oublié !

Passer une heure à configurer tout ça est un sacrifice que je referai tant les services rendus sont appréciables, le résultat étant un projet buildable, intégrable dans une usine de développement continu, testable et facilement déployable dans un environnement puissant.

LB.