Google AppEngine : impressions après quelques tests
Le 2008-04-26 17:01:55J'ai obtenu, la semaine dernière, une invitation pour la version béta de Google AppEngine. Premiers avis et impressions.
"Whoot ! I know Python !" dit Neo en enlevant son casque
Je ne connaissait absolument pas Python, qui est le seul langage actuellement disponible avec AppEngine.Alors l'une des premières choses que j'ai fait est de commander le livre Python de chez Eyrolles. Le titre de ce paragraphe est la première phrase du livre.
Evidemment, le livre n'est pas constitué que de citations de geek rigolotes.
Bien au contraire, il détaille extrêmement bien toutes les possibilités offertes par le langage. Malheureusement cependant, il n'aborde absolument pas le développement web avec Django par exemple.
Celà n'est cependant pas spécialement génant pour toute personne qui a déjà une bonne expérience dans le développement avec au moins un autre langage (PHP avec les objets par exemple).
Les trucs qu'ils sont trop bien
Revenons un peu dans le sujet de Google AppEngine. Il s'agit d'une plateforme offrant l'hébergement d'applications web développées en Python.D'autres langages pourront faire leur apparition dans le futur. Mais si vous souhaitez commencer à développer sur cette plateform, dès maintenant, il faudra le faire avec ce langage.
Voici donc l'avantage principal de Google AppEngine. Le fait que l'on puisse héberger rapidement une application web, sans se soucier de contraintes serveur. Où presque.
Les trucs un peu moins bien
Oui car forcément, comme toute offre gratuite (où payante d'ailleurs), il y a des limitations techniques.Celles-ci sont disponibles sur le site d'AppEngine.
De base, cette plateforme ne sera donc vraiment accessible que aux petites applications, nécessitant peu de ressources système.
J'ai voulu par exemple intégrer les données du RDF dmoz afin d'exporter certains de mes outils dédiés aux éditeurs là-bas. Malheureusement, l'importation de telles données est totalement inenvisageable à cause des limitations du système au niveau de l'ouverture et du téléchargement de fichiers.
C'est d'ailleurs pour cette raison que je n'ai aucune application à vous présenter bien que j'ai déjà commencé à développer. J'ai une seconde application en tête. Mais il faudra attendre un peu ;-)
Google parle de possibilités payantes d'évolution du service afin de pouvoir passer outre ces limitations. Mais elles ne sont pas encore implémentées et nous n'avons aucune idée de la manière dont elles le seront.
L'utilisation d'un compte Google
Un truc qui m'a paru intéressant au départ, c'est le fait que l'utilisateur puisse s'identifier avec con compe Google.Intéressant afin de s'épargner le développement d'une interface de connexion utilisateur.
Mais lorsque l'on regarde la documentation, on se rends compte que cette identification est difficilement utilisable à l'heure actuelle.
En effet, aucun identifiant unique n'est fourni pour chaque utilisateur. Seul l'email de celui-ci est présent. Que se passe-t-il donc lorsqu'un utilisateur change son email ?
La documentation le dit clairement : vous l'avez dans le baba. L'utilisateur a changé son email, vous ne connaissez que celà. Vous avez donc perdu la relation entre l'email et l'utilisateur.
Génant et limite légal lors de l'implémentation d'une newsletter sur votre service par exemple.
BigTable, un pseudo SGBDR
Bah oui quand même, il y a un système de gestion de bases de données. Déjà que ce billet n'est pas très positif pour l'outil. Dans le cas contraire, cela aurait été un démontage total ;-)Le R de SGBD est à mettre car on peut mettre en relation deux tables. Un bon point pour l'outil.
Cependant, seuls les SELECT sont abordables en SQL pur. Aucune possibilité de faire des INSERT, UPDATE où DELETE en SQL pur. Il faut impérativement passer par les méthodes de l'API.
Je n'ai ainsi pas encore trouvé comment faire l'équivalent d'un TRUNCATE (suppression de toutes les entrées d'une table) autrement que ... manuellement dans l'interface (et on ne peux supprimer que jusqu'à une centaine d'uplets à la fois. Génant).
Et encore une limitation, au niveau du SQL pur. Chacune de ces limitations possède un chemin détourné pour arriver à la même chose. Cependant ce chemin détourné n'épargnera par les ressources systèmes.
- Pas de ORDER BY ran(). Chemin raccourci : récupérer toutes les données. Puis voir combien il y en a, générer un nombre aléatoire et récupérer l'uplet relatif à ce numéro.
Pas d'optimisation de la RAM de la machine puisque vous récupérez toutes vos données et devez impérativement les placer dans un objet pour au final ne garder qu'un seul uplet. - Pas de JOIN. C'est toujours du relationnel quand on peut associer un champ d'une table à une autre (table). Mais que l'on ne peut pas faire de requête qui récupère les données des deux tables ?
- Pas de LIKE (et encore moins de MATCH). Pas de recherche possible donc.
La seule solution à l'heure actuelle est de récupérer toutes les données de votre base et de chercher dans chacune d'elles si une n'est pas intéressante.
Sachez cependant qu'un technicien Google a parlé d'une méthode search() sur la mailing liste officielle de la plate forme. Cependant il a dit clairement que cette méthode n'est absolument pas optimisée et n'est pas documentée car elle est déconseillée.
Il a cependant parlé de possibilité de meilleures méthodes à ce niveau dans le futur.
Et comment j'envoie mes données ?
Un SDK est à télécharger sur le site de la plate forme. Celui-ci comprends deux applications :appcfg_devserver.py, qui vous permet de lancer un serveur local sur le chemin de votre application. Utile (voir indispensable) pour développer votre application.
appcfg.py, qui vous permet d'envoyer votre application sur AppEngine.
Et seulement envoyer ! Aucune possibilité de rapatrier votre application sur votre machine. En cas de crash de votre machine et d'un manque de sauvegardes, votre application ne sera alors plus maintenable.
Un service encore en béta
Et ça se voit !L'idée est appréciable. Non seulement afin d'offrir une meilleure visibilité au langage Python, qui est très sympathique à utiliser.
Cependant à la vue de tous les défauts énumérés ci-dessus, l'outil n'est pas encore utilisable sur des grosses applications.
Mais peut-être est-ce le but recherché, d'héberger des milliers de petits trucs sans intéret mais de laisser les gros qui peuvent en présenter en externe.
Le seul réel avantage que je trouve à Google AppEngine est donc le fait qu'il me permet de débuter facilement avec Python, qui est un langage magnifique.
Et vous, que pensez-vous de Google AppEngine ?
Publie : Développement
Tags : développement google appengine python
Recommandez cet article !
: faire connaitre ce post sur Wikio.
: faire connaitre ce post sur Scoopeo.
: faire connaitre ce post sur Fuzz.
le 2008-04-29 15:11:38
Alors, moi, c'est tout le contraire ...
Déjà, je connais bien python depuis un bail et développe des sites web en python depuis qques temps déjà ...
Pour l'upload de données, il y a le bulk_upload qui permet de remplir ses datastore simplement. (moi même je n'utilise pas, je me suis développer qques scripts pour remplir mes datastores : je met des csv sur mon gae, et je fetch des urls pour traiter, c'est parallélisable, et à condition de respecter certaines conditions (limitation ressources), il est tout à fait envisageabl de charger de grosses quantités de données)
L'utilisation du compte google, c'est un plus ... et pour réaliser vite fait un service sans se prendre le choux, c'est le pied total.
Maintenant libre à tout le monde de mettre en place son authent classique login/pass ou de passer par openid ... rien que du classique. l'utilisation de l'account google est juste un petit plus énorme.
Pour bigtable, on est à l'opposé d'un SGBDR, et les gens qui voudront effectivement rentrer leurs bases dans bigtable tel quel vont se casser les dents. C'est le prix à payer pour être scalable. Il faut dénormaliser et oublier tout ce qu'on a appris en sgbdr. Il faut penser autrement, dénormaliser ... c'est le maître mot.
Moi perso, je suis très fan, déjà utilisatauer de sqlachemy, et d'autres orb. Pouvoir/devoir manipuler simplement des instances objets/entités ... sans être obliger de passer par des phpmyadmin et autres syntaxes sql abscons : C'est un reel plus pour vite implémenter qqchose simplement. En 20 lignes de codes python, tu te fait un "blog" (simple), structure de données comprises.
Pour rappatrier son code, j'ai vite développé un truc, car j'avais ce besoin (plusieurs machines de dev): http://manatlan.com/blog/zipme___download_sources_of_your_gae_website__as_a_zip_file
ça fait amplement l'affaire ... (hebergement GAE en nom de domaine)
Oui, c'est du preview, et c'est perfectible (et ça va l'être)
Mais c'est, à mon sens, une énorme innovation de la part de google. Réduisant la maintenance/administration à 0, offrant une scalabilité énorme, et en réduisant au strict minimum le dev.
Si j'étais fou, j'irai jusqu'à parler de web3.0 ;-) ...
Note : je me suis aussi cassé les dents à dénormaliser une bdd mysql que j'avais dans un autre hébergement python pour la faire entrer dans bigtable : mais c'est totallement faisable. Faut juste pas raisonner sgbdR !
le 2008-04-29 15:28:46
j'oubliais d'argumenter "web3.0", pk l'application n'est plus lié à une machine, une ferme de serveurs avec des frontaux et autres répartiteurs de charges, affinités de session, et serveurs de bdd. Donc, dans le sens : tout ça on oublie aussi : ce qui simplifie énormément l'administration. L'application et ses données sont réparties un peu partout, et se scalent très bien, en ajoutant simplement des datanodes dans les datacenters de google.
le 2008-04-29 15:47:38
Idem, j'irai plutôt dans le sens de manaltan.
J'y connaissais rien en python et j'ai fait un clone de TinyURL (yatuc.appspot.com) en 6 heures, moche mais fonctionnel.
Autant je trouve la doc très mal foutue (un peu comme celle de python :) ) pour un débutant autant je trouve très peu de limitations pour une première version de GAE.
Ensuite, Django c'est sur, j'ai rien compris ni pris le temps de lire toute la doc mais sur le reste BigTable, Authentification (compatible avec Apps!!),.. c'est excellent même sans JOIN, LIKE,... C'est rapide : on récupère "le monde" et ensuite on le traite dans le code voilà. C'est une nouvelle approche.
Par contre, un des points chiants non signalés dans l'article : le yaml... Non pas que les conf en xml soient bcp mieux mais sur une grosse application, je pense qu'il y a un bon moyen de se faire chier avec.
Je sais pas par contre si appspot sans support de Java par exemple ne va pas rester sur de toutes petites applications. Non pas que Python soit limitatif mais plutôt du fait d'une plus petite population.
PS : si quelqu'un a trouvé un moyen de mettre des beakpoints, faire du step-by-step avec Eclipse + pydev + devserver.py, je suis preneur.
le 2008-04-29 17:11:03
@syl
le yaml, c'est assez génial comme concept. Et bien plus lisble qu'un .ini ou un .xml ! Perso, mon yaml contient generallement 2 entrées les ressources statics et un point d'entrée vers l'appli. Et c'est après, dans l'appli que je reroute mes urls sans soucis. Je ne vois pas où ça peut géner dans une grosse appli. Car après, dans ton appli tu met en place ce que tu veux pour gérér tes reroutages.
Bon, c'est vrai que je n'utilise pas le framework fournie par google, mais celui de webpy.org, que je manipule aisément depuis plusieurs années, et qui fonctionne out-of-the-box sur gae.
Pour les breakpoints dans eclipse/pydev : aucune idée, mais tente ulipad, qui a un debuguer très bien intégré ("à la VisualStudio"). Moi perso j'utilise open-komodo qui est absolument parfait.
le 2008-04-29 17:45:37
@manatlan
Merci pour les infos.
Pour les breaks, step-by-step ca fonctionne en direct avec le devserver.py d'activé. En gros, c'est capable de bloquer l'exécution du server web sur un break et de voir les valeurs des variables ? Je vais regarder open-komodo.