Je code donc je suis

Pour faire suite à mon billet sur les lapins, voici un article très intéressant, Got applications?, de Peter Saint-Andre le directeur de la XMPP Standards Foundation. Je conseille en complément la lecture rapide de ses slides à l’eComm.

En effet même si XMPP est de plus en plus utilisé en backend, HTTP via REST est toujours autant populaire pour fournir des APIs publics. Cependant, à moins de s’appeler Google ou Amazon et d’avoir suffisamment de ressources en matériels et bande passante à gaspiller, ce protocole synchrone nécessitant des poolings n’est pas du tout adapté comme il l’explique avec l’exemple de Twitter.
Le problème de Twitter n’est pas Rails. Leur problème est de proposer un service ayant de plus en plus de succès, utilisé par de plus en plus d’applications tierces et traitant une somme considérable de données à chaque seconde. De la même manière, on ne peut pas dire que Facebook soit très rapide.
Or pour résoudre ces problèmes de tenue en charge, HTTP n’est pas le meilleur candidat… Il n’est pas concu pour maintenir une connexion client serveur ou serveur serveur, à moins de bricoler, et n’est pas concu pour conserver un état entre chaque requête, à moins de bricoler. Bref on se gausse du web2, mais c’est une vaste blague face à l’énergie dépensé en développement et en administration pour compenser ses lacunes, afin de s’approcher, de loin, de ce qui ce fait depuis des décennies et simplement sur le desktop. Certes le navigateur web est universel, quoi que là encore l’énergie dépensé pour faire fonctionner et présenter correctement un site sur tous les navigateurs est phénoménale.

Bien sûr HTTP n’est pas prêt de disparaître en tant que protocole navigateur web serveur. La question se pose, serveur à serveur et client desktop à serveur comme le propose Peter Saint-Andre. Il est plus simple de convaincre des développeurs, surtout si on obtient ainsi un lapin plus réactif :)

Non cela ne résoud toujours pas le problème entre le navigateur et le serveur. Mais qui peut croire qu’un service à succès est utilisé plusieurs fois par heure depuis un navigateur ?! L’utilisateur le veut à porté de doigt en permanence, intégré à son desktop ou à son iPhone et surtout qu’il consomme le moins de ressources possible. En sommes tout le contraire d’un navigateur …

L’avenir du développement des architectures web se dirige clairement vers des environnements asynchrones et concurrentiels. Bref des outils adaptés aux besoins. Laissons HTTP à ce qu’il sait faire : servir des pages.