[frontend] Changer la façon de requêter les données pour passer via LDP au lieu de SPARQL

[mguihal]

Tension Actuellement, les données de liste sont récupérées via une requête SPARQL (via le getList du dataProvider). Cela pose des problèmes de performance, et ce fonctionnement est dépendant de la gestion de permissions via la base de données elle-même. C'est le cas actuellement avec Jena Fuseki, mais empêche la potentielle migration vers une autre base de données dans le futur.

Proposition Basculer le requêtage de l'ensemble des ressources par les containers LDP, en rajoutant la propriété list.fetchContainer (https://semapps.org/docs/frontend/semantic-data-provider/data-model) dans la configuration des ressources

Alternatives Modifier le dataProvider pour ajouter une propriété booléenne globale du type fetchContainer ou plus explicite useLDPContainer, qui permettrait de changer ce paramètre globalement pour l'ensemble des requêtes des ressources.

[srosset81]

L'option fetchContainer peut être moins performante selon les données. Notamment parce que le container ne gère pas encore la pagination... Il faut tester

[mguihal]

L'option fetchContainer peut être moins performante selon les données. Notamment parce que le container ne gère pas encore la pagination... Il faut tester

Ce qu'on a constaté sur l'instance de Nantes, c'est un gain aux alentours de 20s de chargement pour une liste de 300 organisations par exemple. Je pourrai remontrer ici un benchmark entre les deux méthode. Après, je pense surtout que c'est dû à l'utilisation du cache Redis qui permet de ne pas aller requêter la base pour une grande majorité des requêtes de lecture.

Quant à la pagination, que ce soit côté LDP ou Sparql, elle est de toutes façons actuellement faite après la requête, côté front.