Je n’ai jamais caché ma jalousie envers les codeurs Javascript sous meteor.js. C’est à mon sens la techno la plus révolutionnaire en matière de dev Web depuis l’invention des frameworks HTTP.
Ca permet notamment de faire du PUB/SUB entre le navigateur et le serveur. C’est à dire qu’un navigateur déclenche un événement, le serveur le reçoit, et tous les browsers abonnés le reçoivent aussi. Du coup, on modifie une page, toutes les autres pages sont modifiées en temps réel.
Dommage que ce soit codé dans un langage pourri.
Heureusement depuis quelques temps, un standard est en train d’émerger autour du RPC et PUB/SUB entre navigateurs et serveurs : WAMP. Il existe du coup des implémentations du protocole en plusieurs langages, donc une en Python avec autobahn.
Ca s’utilise ainsi : pip install autobahn.
Puis, un petit coup de Python :
import sys from twisted.python import log from twisted.internet import reactor from autobahn.twisted.websocket import listenWS from autobahn.wamp1.protocol import WampServerFactory, WampServerProtocol class MyPubSubServerProtocol(WampServerProtocol): def onSessionOpen(self): # On choisit un namespace pour enregistrer ses events PUB/SUB self.registerForPubSub("http://example.com/events/bam") if __name__ == '__main__': # on lance notre serveur avec moult verbosité log.startLogging(sys.stdout) wampFactory = WampServerFactory("ws://127.0.0.1:9000", debugWamp=True) wampFactory.protocol = MyPubSubServerProtocol listenWS(wampFactory) reactor.run() |
On lance le serveur directement :
python votre_script.py |
Côté client (pas besoin de serveur, on peut l’ouvrir dans le browser cash pistache) :
<!DOCTYPE html>
<html>
<head>
<script src="http://code.jquery.com/jquery-1.11.0.min.js"></script>
<script src="https://raw.github.com/tavendo/AutobahnPython/master/examples/twisted/wamp1/pubsub/simple/example1/autobahn.min.js"></script>
<script type="text/javascript">
$(function(){
ab.connect("ws://localhost:9000", function(session) {
$('#foo').click(function(){
// au clic sur le bouton, on envoit un evenement BAM
session.publish('http://example.com/events/bam', ['bam']);
// On ajoute bam à la liste en local car le publisher ne
// reçoit pas ses propres events
$('#doh').append('<li>bam</li>');
});
session.subscribe('http://example.com/events/bam', function(topic, evt){
// on s'inscrit pour recevoir l'event quand il est
// déclenché. Ceci marchera dans tout autre tab que celui
// qui a déclenché l'event
$('#doh').append('<li>bam</li>');
});
})
});
</script>
</head>
<body>
<!-- Notre liste qui va se remplir de bam ! -->
<ul id="doh"></ul>
<button id="foo" value="Bam">Bam</button>
</body>
</html> |
Ce qui ce passe, c’est que quand j’appuie sur le bouton “Bam”, ça envoit un événement Bam au serveur via Websocket, qui propage l’événement à tous les clients. Donc tous les tabs ouverts sur cette page récupèrent l’événement et peuvent y réagir. Ici, les deux pages sont mises à jour en simultané.
Chez moi ça marche
Bien entendu, ceci est un exemple très basique fait pour vous donner un avant goût de la techno. D’ailleurs, meteor.js, c’est bien plus que du PUB/SUB. Il y a de la gestion de la deco, la synchro de la base côté client, le hot push de code, etc. Ils ont fait un vrai travail de fond sur les problématiques concrètes.
Donc on en est encore loin, surtout que même leur techno est toujours expérimentale. Mais on a enfin de quoi rattraper le temps perdu. Et avec asyncio, îl n’y aura même pas besoin de dépendre de twisted pour ce faire. 2014 va être trop fun !
Ohh ! … en voilà un joli nouveau jouet, merci :-)
Regarde du coté de webalchemy
J’ai regardé mais le projet est moins sérieux, pas basé sur un standard, pas mal de boiler plate, moins de docs et d’exemples, etc
Dans le même domaine, j’ai créé Skink, un petit projet qui permet de synchroniser plusieurs navigateurs ensemble en full Python et d’avoir des callbacks “element.onclick” sur des fonctions Python.
https://github.com/oksome/Skink/
Oui mais c’est comme webalchemy, on manipule pas mal le DOM depuis Python, ce qui n’est pas du tout une bonne pratique : on a un fort couplage avec l’interface. Envoyer des données, et laisser le client le soin de gérer le DOM est bien plus important.
Ca dépend du point de vue. WebAlchemy fait pas mal de magie, surtout avec Pythonium qui convertit une partie du code Python en JS envoyé côté client, approche dont je ne suis pas vraiment fan.
Par contre, pour un hack, un petit projet ou pour des débutants, le fait de pouvoir tout faire en un seul langage côté serveur et en parallèle avec tous les clients est vachement pratique.
Utiliser nodeJS seras bien plus rapide…
L’approche “le même langage partout” ne marche pas pour moi. Si c’est un langage serveur, il faut faire de la compile vers JS est c’est à chier pour le déploiement, le debug, la formation, etc. Si c’est du js partout, on se retrouve avec un langage moche, super limité hors du Web et locké à quelques plateformes type nodejs.
Mieux vaut laisser le js sur le browser (on a pas le choix) et avoir un langage décent côté serveur.
C’est possible d’utilisé socket.io avec autobhan?
Parce que les websocket ne sont pas supporter par tout les browser!
Dans le meme genre il y a geventsocket.io https://github.com/abourget/gevent-socketio
et ici une video
Bonjour,
J’ai testé les 2 : meteor et autobahn.
Pour les websockets, le standard n’est pas finalisé, quelques galères pour des parties authentification, quelques problèmes de montée en charge.
Autobahn, c’est du twisted donc faut aimer lire leur doc incompréhensible…si on veut sortir des sentiers battus. A titre personnel, je n’aime pas la programmation par callback, je trouve que c’est vite le bordel sur une grosse application. Par contre, le fait que ce soir basé sur twisted on a donc accès aux autres modules twisted qui sont très performants.
Meteor c’est plus que ce qui est décrit…par exemple il y a un mécanisme de réplication de la base en local afin d’améliorer les accès. Malheureusement, quelques articles sur le net pointent le fait que meteor, en l’état actuel, ne supporte pas tellement la charge. Bon à titre personnel, toujours, je n’aime pas le javascript, c’est pour moi un langage patché par les différents frameworks. D’ailleurs, il y a tellement de frameworks qu’aucune démarche industrielle n’émerge. Pour moi le Javascript c’est le langage à la mode pour les gars qui viennent pas de l’informatique, genre les web designers ou des gus de la sorte.
J’espère sincèrement que le futur du web ne sera pas full Javascript. Je préférerais encore faire du Dart.
Enfin, pour mes besoins, même si je reste attaché à Python, j’évolue et migre tout doucement mes applications vers le langage Go qui dispose d’une vraie bibliothèque par défaut pour les applications web. Les outils de développement Go sont un réel bonheur (fmt, génération de doc, test unitaire…). Et niveau puissance rien à voir avec le Python. Pour avoir la même puissance en Python, nous sommes obligés de bricoler des choses avec des libs externes (gevent, twisted, tornado, zeromq…). Et je dois plus me coltiner du Python 2 et du Python 3. Pour moi, ces 2 versions sonnent le désengouement du Python, on était très bien avec la version 2…Avec le 3 on repart avec toutes ces conneries d’encodeage de texte et ça me gave copieusement. Enfin la langage Go possède un mode élégant pour gérer la concurrence, et là pareil avec Python, on doit bricoler. Enfin, le déploiement avec Python c’est galère. 3 heures pour générer un setup.py avec distutils ou setuptool…bref le déploiement me saoule tellement que j’utilise nuitka…
Je réserve donc le Python pour mes scripts d’admin et j’utilise exclusivement Go pour mes futurs développement.
J’avais écrit un article pour faire la même chose avec Gevent. C’est un peu plus bas niveau mais c’est le même principe, sauf qu’ici on fait appel au pattern pub/sub pour gérer les messages. Si cela peut servir à quelqu’un, au moins pour comprendre la communication bidirectionnelle, mais je conseille également d’utiliser une bibliothèque pour gérer l’aspect message.
http://www.hautefeuille.eu/tag/gevent.html
Si je ne me trompe pas, Autobahn supporte aussi asyncio en Python3. Du moins c’est ce que prétend leur site.
@albert je m’interresse aussi à Go
Mes collègues de travail veulent passez de ruby, python, scala et perl vers Go.
Mais
1.j’ai peur que ça suit le chemin de nodejs des versions qui changes tout le temps et pas de rétrocompatibilité.
2. j’attend aussi un bon framwork web équivalent à django ou web2py
y a t’il des équivalents en Go ?
@keiser1080
1 – Non, à partir de la version 1, ils assurent une stabilité du langage. Il se peut qu’il y ait des modifications, mais cela sera sur les bibliothèques. Go intègre dès sa conception des objectifs d’industrialisation, de cohérence et de stabilité. Cela se remarque lorsqu’on développe avec.
2 – Oui il y a des équivalents comme le framework Revel (http://robfig.github.io/revel/). De mon côté j’utilise des choses comme webgo (http://webgo.io/) ou martini (http://martini.codegangsta.io/).
@Sam
C’est autobahn pas autobanh :)
Comme on évoque Meteor dans cet article, j’ai mis en ligne un petit exemple d’utilisation de Meteor pour que ceux qui n’ont pas eu l’occasion de regarder. C’est un exemple de tableau de messages avec authentification, c’est un exemple succinct mais il montre rapidement les possibilités offertes par le framework.
https://github.com/jhautefeuille/meteor-example
Très juste mon cher @roger.
Huatefeuille : tu peux rajouter des instructions pour l’installation et le lancement dans le README ? Sinon la plupart des gens pourront pas tester. C’est pas si facile à setup meteorjs (et les trucs node en général).
@Sam : j’ai ajouté un petit fichier d’aide succinct.
Cool merci.
Personnellement je ne suis pas un grand fan de autobahn, d’ailleurs la communauté twisted (techno qu’utilise ce framework) n’en fait pas l’apologie non plus, pour l’instant en tout cas.
La maniere la plus simple que j’ai trouvé pour faire cela avec python est sockjs (c’est plus ou moins ce qui est recommandé par la communauté), la lib coté client n’a rien a envié à autobahn et à socket.io, et pour le coté serveur ca a été implementé dans pas mal de languages dont une super simple pour python/twisted qui s’appelle txsockjs.
Apres on est d’accord c’est juste un choix.. Je trouve juste txsockjs plus light.
Ensuite ce que pense la communauté twisted, c’est peut etre plus tres pertinent. Depuis l’abandon de nevow et andromeda (ils disent que c’est toujours maintenu mais bon……) ils ne sont plus tres loquaces sur toutes l’emergence de ces technologies web et preferent (à mon avis) laisser les user creer leur propre libs et ne pas meler ca au core, pas l’instant en tout cas.
A la rigueur l’avantage, mais je ne peux pas vraiment quantifier car je ne connais pas assez, serait ce protocol wamp, un sub protocol basé sur les websockets apparement (merci je comprends enfin que c’est pas windows apache mysql php !!!)
Enfaites je voulais surtout rebondir sur ce qui a été dit sur node.js.
J’ai longtemps critiqué ce framework, mais surtout le language qu’il faut utiliser pour coder dessus, mais réellement il n’y a pas photo c’est le must. Je suis un tres tres grand fan de python et encore plus de twisted (j’utilise meme le systeme de templating web de twisted pour vous dire). Je fais tout avec, mais là en terme de web je ne m’embarasserais plus jamais avec python.
Le javascript n’a pas une syntaxe de merde en soi, c’est juste que les gens ne savent pas coder dessus. Et comme tout ce qui est au lié facing tel que le web, et donc aussi au business et au marketing on est plus dans une logique de productivité à mettre en production du code qui fonctionne mais totallement mal codé. Par exemple il n’y a pas de classe en javascript, et la delegation est preferable à l’heritage (en realité l’heritage de classe n’existe pas car il n’y a pas de classe). C’est un language vraiment pas compris et on se retrouve encore aujourd’hui à retrouver des questions sur comment creer un objet ou manipuler les prototypes, avec des theories sur l’utilisation ou pas de l’operateur new et ce genre de chose :).
Bref c’etait juste pour dire node.js est un outil puissant, j’ai mit du temps à m’y mettre, à la rigueur si vous ne faites pas de web bon ben c’est pas une grosse perte, mais pour ceux qui sont dedans vous ne pourrez pas l’ignorer longtemps, autant s’y mettre maintenant tant que c’est encore assez jeune, faudra juste ripper le javascript et penser javascript.
Voila juste un petit retour d’experience :)
Et bravo pour ton site vraiment bien fait et avec humour, et les commentateurs aussi son cools :)
Quand je dis que Javascript est moche, je pense généralement à l’itération dégueu, la gestion des arguments à la truelle, l’absence d’unpacking, le slicing verbeux, etc.
C’est pas que l’on puisse pas coder du JS propre, ni que nodejs est un mauvais produit. C’est simplement que le JS n’est pas du tout ergonomique. La seule raison pour laquelle il a ce succès, c’est que c’est la langage par défaut sur le browser. Sinon, personne n’en ferait sur le serveur.
Personne ne ferait du JS parce qu’il aime le JS si il y avait une alternative.
Question naïve, mais si c’est si naze que ça, pourquoi ça a été adapté sur tous les navigateurs ? C’est pareil pour le PHP, tout le monde déteste mais tout le monde en fait. Et à l’opposé de ça, le python tout le monde aime ça mais c’est pas si répandu que ça.
(Bien sûr je caricature un peu, hein).
Pour le Javascript, c’est simplement que ça a été implémenté dans IE qui a ensuite eu le monopole. C’est comme la question : si windows est si naze, pourquoi tout le monde l’utilise.
La raison pour laquelle PHP s’est répendu est différente : PHP a répondu à un besoin clair au moment de sa sortie. Il n’y avait rien de mieux que PHP pour faire de la prog Web à ce moment. De surcroit, la doc PHP et la communauté PHP sont parmi les meilleures au monde. Ceci est indépendant des qualités du produit en tant que langage de prog, qui sont elles, médiocres, comparés à des concurrents comme Ruby, Go, Clojure ou Python.
Un produit n’a pas forcément le succès du fait de ses qualités intrasèques, il y a beaucoup de contexte. Sinon le beta max aurait eu le dessus sur le VHS et les américains utiliseraient le système métrique.
Tu ne penses pas que ca à son avantage aussi?
En terme de communication client/server probablement plus trop depuis que tout le monde abuse de json, mais dans une team qui travaille sur une web app tu penses pas que c’est un avantage que le mec qui code coté browser utilise le meme language language coté client que le mec qui code coté serveur? En plus d’utiliser le meme language ils peuvent meme utiliser les meme libs (voir http://browserify.org/)
Pour ma part, en realité c’est l’un des 2 seul avantage que je trouve à node.js/javascript versus twisted/python c’est que les technos sont les même coté server et client. Pour la gestion de projet c’est tout de meme plus simple.
Le 2eme avantage c’est que pour atteindre les memes perf que node.js avec mon serveur python il faut que j’utilise pypy, bon ce qui est un detail mais qu’il faut prendre en considération lorsqu’on monte en charge et lors de l’intégration.
De toute facon on fait toujours en fonction de nos preférences et de notre expérience, mais surtout.. on fait avec ce qu’on a et les moyens du bord (aka cahiers des charges fait sans toi, budget, deadline, est ce que je peux copy/paste un truc déjà fait, stagiare junkie, chef de projet à l’ouest etc).. et ca c’est pas toujours un cadeau.
C’était la séquence “Programmeur du grenier” :D
On traduis des programmes en ASM depuis X années ça dérange plus personne…
Concernant webalchemy, c’est le debut faut bien commencer par ça.
Bonjour! :)
L’avantage de meteor, c’est que l’on code dans le même langage coté client et coté serveur. D’où une base nodejs.
À moins que le python puisse être executé coté navigateur, assez rapidement, je ne trouve pas cette librairie utile pour de gros site web.
Enfin, c’est mon avis…
Si utiliser le même langage client et serveur était l’unique avantage de meteor, le projet ne serait pas très innovant. La force de meteorjs, c’est le côté temps réel, la transparence entre l’action client et le résultat serveur, etc. Surtout que dans la pratique, on réutilise rarement exactement le même code côté client et serveur, donc on partage juste la syntaxe, qui plus est la syntaxe JS qui est pas top.
Question de goût, perso j’aime la syntax du JS (notamment ES6).