Mentionnons également CouchDB (http://couchdb.apache.org ) qui développe une approche complémentaire : la pénétration de javascript dans la base de données.
Les applications lourdes en javascript ont de plus en plus tendance à générer leur HTML à partir de données encodées en JSON (http://www.json.org/ ). Plutôt que de générer ce json côté serveur à partir de la base de données, l'idée est de stocker directement ces données en JSON, et de les accéder avec un moteur puissant et distribué écrit (partiellement) en Erlang (http://www.erlang.org/ ).
Les requêtes base de données sont écrites en javascript en suivant le principe MapReduce(http://labs.google.com/papers/mapreduce.html ). Cela représente un peu plus de travail en perspective que les requêtes bases de données abstraites habituellement par un framework Web comme Rails ou Django, mais au moins, le développeur n'a pas l'impression de confier une partie critique de son appli web à un blob SQL dont il ne maîtrise (habituellement) pas tous les rouages. Et puis, si l'application est populaire, les problèmes de montée en charge reviennent à la face du développeur qui doit optimiser ses accès base de données de toute façon.
L'inconvénient majeur par rapport à SQL est que, si le système est distribué, le contenu de la base n'est pas cohérent : en parlant à deux serveurs différents, on peut avoir deux versions chronologiquement décalées du même objet. Mais le problème n'est pas si important dans l'univers des applis web (les données à jour apparaîtront au prochain rechargement). Et CouchDB gère les conflits.
Il est donc possible, avec un moteur de Javascript serveur et CouchDB, d'avoir un framework web qui génère en Javascript la page lors du chargement initial. Puis lorsque l'utilisateur interagit avec le site, le visuel est regénéré côté client, en utilisant les mêmes fonctions, et le client interagit directement en échangeant du JSON avec l'interface REST de CouchDB (http://en.wikipedia.org/wiki/Representational_State_Transfer ) plutot qu'avec le framework.
Bref, je vous encourage à l'essayer. Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL :)
# CouchDB
Posté par nicolas_o . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 2.
Les applications lourdes en javascript ont de plus en plus tendance à générer leur HTML à partir de données encodées en JSON (http://www.json.org/ ). Plutôt que de générer ce json côté serveur à partir de la base de données, l'idée est de stocker directement ces données en JSON, et de les accéder avec un moteur puissant et distribué écrit (partiellement) en Erlang (http://www.erlang.org/ ).
Les requêtes base de données sont écrites en javascript en suivant le principe MapReduce(http://labs.google.com/papers/mapreduce.html ). Cela représente un peu plus de travail en perspective que les requêtes bases de données abstraites habituellement par un framework Web comme Rails ou Django, mais au moins, le développeur n'a pas l'impression de confier une partie critique de son appli web à un blob SQL dont il ne maîtrise (habituellement) pas tous les rouages. Et puis, si l'application est populaire, les problèmes de montée en charge reviennent à la face du développeur qui doit optimiser ses accès base de données de toute façon.
L'inconvénient majeur par rapport à SQL est que, si le système est distribué, le contenu de la base n'est pas cohérent : en parlant à deux serveurs différents, on peut avoir deux versions chronologiquement décalées du même objet. Mais le problème n'est pas si important dans l'univers des applis web (les données à jour apparaîtront au prochain rechargement). Et CouchDB gère les conflits.
Il est donc possible, avec un moteur de Javascript serveur et CouchDB, d'avoir un framework web qui génère en Javascript la page lors du chargement initial. Puis lorsque l'utilisateur interagit avec le site, le visuel est regénéré côté client, en utilisant les mêmes fonctions, et le client interagit directement en échangeant du JSON avec l'interface REST de CouchDB (http://en.wikipedia.org/wiki/Representational_State_Transfer ) plutot qu'avec le framework.
Bref, je vous encourage à l'essayer. Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL :)