Une petite remarque à propos des lecteurs RSS : si j’ai fait mon lecteur RSS perso, c’est parce qu’il n’y en avait aucun qui ne fonctionnait comme je voulais.
Un des problèmes que je voyais, c’est le temps de chargement entre chaque lecture : à chaque ouverture de post, le navigateur contacte le serveur pour recevoir le contenu de l’article qu’on demande à lire. Entre le moment où l’on clic et le moment où le contenu arrive dans le navigateur, il s’écoule un temps où on ne peut rien faire et c’est chiant.
Le problème quand l’interface et la BDD ne se trouvent pas sur le même système, c’est de synchroniser les deux. À la fois pour le contenu et pour le les actions de l’utilisateur.
Mon lecteur, c’est l’ensemble des éléments non-lus qui se trouve dans le navigateur : donc pas de requête serveur pour obtenir le contenu d’un article, le navigateur l’a déjà. Oui, la quantité de données dans le nav peut sembler importante, mais c’est relatif : 500 articles, ça fait ~2,2 Mo. C’est beaucoup, mais c’est à peine plus que le poids moyen d’une page web aujourd’hui. Ça charge en 3 secondes avec une connexion 8 méga. Ce délai est unique, juste au chargement.
Ensuite, pour la sync des interactions utilisateur (marquage comme lu, etc.), je fais un cache dans le nav : plutôt que de faire une requête serveur à interaction lu, je ne sync que tous les 10 articles lus. C’est là aussi beaucoup plus rentable.
Ce qui prend du temps, aujourd’hui, ce n’est plus la quantité de données à transférer, mais la quantité de requêtes faites au serveur. 10 connexions de 1 Mo sont beaucoup plus lentes que 1 connexion de 10 Mo.
De même pour les requêtes SQL : faire une seule requête pour marquer 10 articles comme lu, c’est plus rapide que 10 requêtes pour un article.
— (
permalink)
