Performances HTTP - Beaucoup de petites demandes ou une grande
Scénario:
- Dans mon site, j'expose des livres.
- L'utilisateur peut ajouter chaque livre à une liste "Lire plus tard".
Comportement:
Lorsque l'utilisateur entre sur le site, une liste de livres lui est présentée. Certains sont déjà dans leur liste "Lire plus tard", d'autres non.
L'utilisateur a une indication à côté de chaque livre lui indiquant si le livre a été ajouté à la liste ou non.
Mon problème
Je discute de l'option qui est l'idéal pour ma situation.
Option 1:
- Pour chaque livre, demandez au serveur s'il existe déjà dans la liste des utilisateurs.
- Mettez à jour l'indicateur pour chaque livre.
Pro: Très petite requête au serveur, et réponse très simple (vrai ou faux).
Con: Dans une page avec 30 livres, j'enverrai 30 requêtes http distinctes, qui peuvent bloquer les sockets, et est plutôt lente compte tenu du fait que le navigateur et le serveur doivent effectuer la poignée de main entière pour chaque transaction.
Option 2:
- J'interroge le serveur une fois et j'obtiens une réponse avec la liste complète des livres dans la liste "Lire plus tard" sous forme de tableau.
- Dans le navigateur, je passe en revue le tableau et je mets à jour l'indication de chaque livre selon qu'il existe dans le tableau ou non.
Pro: Je ne fais qu'une seule demande et je mets à jour l'indicateur pour tous les livres en même temps.
Con: La liste "Lire plus tard" peut contenir des centaines de livres, et passer un grand tableau peut s'avérer lent et excessif. Surtout dans les scénarios où pas 30 livres apparaissent à l'écran, mais seulement 2-3. (C'est-à-dire que je veux vérifier si un certain livre est dans la liste, et pour cela j'ai le serveur envoie au client la liste complète des livres de la liste).
Alors,
Quelle voie choisiriez-vous pour maximiser les performances: 1 ou 2?
Y a-t-il une alternative qui me manque?
L'option 1 sonne bien mais a un gros problème en termes d'évolutivité.
L'option 2 atténue ce problème d'évolutivité et nous pouvons améliorer sa conception:
Côté client, via javascript, ne collectez que les identifiants de livres affichés et interrogez une fois, via ajax, pour un tableau d'informations lues ultérieurement, uniquement pour ces 30 livres. De cette façon, vous continuez à servir la page rapidement et à demander un petit ensemble d'informations supplémentaires, une fois avec une seule demande http.
Côté serveur, vous pouvez encore améliorer la mise en cache d'une matrice en mémoire d'ID lus ultérieurement pour chaque utilisateur.
Je pense qu'en 2017, la solution concerne moins les performances globales mais l'expérience utilisateur et les attentes des utilisateurs.
Et de nos jours, l'utilisateur ne tolère pas les retards. En ce sens, les interfaces utilisateur sophistiquées essaient d'être réactives le plus rapidement possible. Ainsi: si vous pouvez utiliser ces petites demandes pour permettre à l'utilisateur de faire quelque chose (au lieu d'attendre 2 secondes pour qu'une seule grande demande revienne), vous devriez préférer cette solution.
A ma connaissance, il existe de nombreux sites "haute fidélité" où une seule page peut envoyer 50, 100 requêtes ... Je considérerais donc cette pratique courante.
Et peut-être que cela est utile ici: podcast se-radio.net épisode 277 traite ce sujet de manière intensive, dans le contexte de la latence de la queue.
À mon avis, cela dépend de la façon dont les données sont stockées. Si une base de données relationnelle est utilisée, vous pouvez facilement obtenir l'indicateur booléen dans la liste des livres en faisant simplement une jointure sur les tables correspondantes. Cela vous donnera probablement les meilleurs résultats et vous n'aurez pas à écrire d'algorithmes dans le front-end.