You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Conseil sur l'architecture du service de recherche de la suite DoTS :
Cette issue inclut explicitement une phase d’analyse et de conseil visant à déterminer la meilleure architecture à adopter pour leservice de recherche de la suite DoTS, pour arbitrer notamment entre :
la conception d'outils de recherche permettant le dialogue direct entre l'API d'Elasticsearch et le front-end DoTS-vue, impliquant :
l'exposition des APIs ES de nos instances ES (non-accessibles actuellement)
la création des requêtes ES en JS dans un/des composants du front-end
la lecture, le traitement et l'enrichissement des réponses d'ES dans un/des composants du front-end
la conception d'un middle-ware "dots-es-app" sur le modèle d'applications existantes : encpos-app, miroir-app ou surtout lettres-app pour la complexité de ce dernier (lettres-app/elastic, lettres-app/app/api/search.py et lettres-app/app/api/route_registrar.py : def search et def register_search_route), impliquant :
la non exposition des APIs d'ES
la création des requêtes ES en python sur la base de requêtes custom en provenance du front-end sur la route search
la lecture, le pré-traitement et l'enrichissement des réponses d'ES en python dans ce middle-ware
une autre implémentation appropriée, de préférence basée sur le stack technologique existant
Fonctionalités attendues
Formulaire de recherche
Recherche différenciée entre métadonnées (notice) et contenu des documents
Filtres/Facettes à auto-complétion sur les colonnes pertinentes (selon disponibilité) pour un projet DoTS : (sous-)collection d'appartenance, dates (plus ou moins précises), auteur, etc
Liage des résultats :
Les résultats de recherche plein texte dans les documents doivent être associés au passage (au sens DTS) du texte où ils été trouvés (voir aussi #1).
Les URLs (domaine/base_url/projet_id_ou_collection_id/fragment_édité_id#ancre_id_éventuelle) devront pouvoir être reconstruites au clic sur un résultat.
Critères d'évaluation des propositions d'architecture :
Sécurité (accès direct ouvert vers nos instances ES)
Capacité à assurer les fonctionnalités de recherche attendues (cf. ci-dessus )
Capacité à dialoguer avec ES via l'API ES directement mais aussi de gérer des recherches custom plus complexes (si nécessaire pour répondre au point 2.)
Capacité à rendre optionelle la fonctionnalité de recherche par projet d'un déploiement DoTS-vue donné
Capacité à prendre en compte, le cas échéant, des paramètres de configuration des dossiers de configuration des déploiements front-end (dots-elec-settings)