Supression totale des fields

[rducom]

A été évoqué l'idée de permettre la suppression totale des fields, à la condition obligatoire de permettre de "couper" la sérialisation une fois arrivé sur un objet Entity lors du parcours de graphe du type, et à remplacer cet objet par son URL uniquement.

Cette approche colle parfaitement à l'approche Fluent (https://github.com/LuccaSA/RestDrivenDomain/issues/193) : on pourrait réutiliser le cache des entités lors de la sérialisation pour effectuer le check permettant de substituer un objet par son URL.

Actuellement les fields sont aussi utilisés côté backend pour piloter les Includes EF, dans une logique "d'optimisation". C'est à ma connaissance le seul aspect qui serait impacté, mais je pense qu'il doit en exister d'autres.

Quels sont vos avis à ce sujet ?

[nfaugout-lucca]

J'ai pas compris ta première phrase, tu peux préciser stp ?

En effet les Fields sont historiquement utilisés dans la sérialisation et dans l'infra pour savoir quelles tables inclure.

Mais si on embrasse une approche strictement REST, ça équivaudrait à dire :

• que sur 1 seule entité on inclus toujours toutes ses dépendances, et pour éviter de ramener toute la base à chaque fois, on éclate son code dans différents Bounded Contexts, ce qui fait qu'une entité dans 1 BC particulier ne sera jamais "trop" grosse pour qu'on veuille n'en renvoyer qu'une partie. Cette contrainte me paraît saine et c'est notamment pour ça que j'ai simplifié les HandleIncludes( ) dans RDD v2 notamment en virant tout ce qui était include automatique, includes imbriqués & co.

• que sur une collection d'entités, on ne renvoie QUE id, name, url, mais ça on a déjà vu dans d'autres Issues que c'était un gros frein car va demander une grosse adaptation du front ET un changement de paradigme assez lourd = faire N requêtes plutôt que 1. Du coup, si on autorise les "fields" sur les collections, et si on se soumet à la contrainte ci-dessus, ça sous entend que sur une collection on charge aussi TOUS les fields d'une entité. C'est la que la paging devient intéressant ! Mais ça veut aussi dire qu'on s'interdit de fetcher "juste" les id,name,url d'une grosse collection (ex 1000 entités) car même si on ne demandait que id,name,url vu la contrainte ci-dessus et ce que je viens juste de dire, ça loaderait TOUTES les propriétés des 1000 entités, ce qui n'est probablement pas scalable.

D'où la situation actuelle, où les fields sont autorisés sur les collections, et ou les includes sont déconseillés mais possibles.

[rducom]

on pourrait réutiliser le cache des entités lors de la sérialisation pour effectuer le check permettant de substituer un objet par son URL.

Lors de l'étape de sérialisation, le cache des entités permettrait très facilement (via un .ContainsKey(typeof(T)) sur le type entité) de savoir si une entité est oui ou non un BO/BR, et si c'est le cas, substituer l'objet par son URL.

Le problème que tu soulève me rappelle aussi un point remonté hier sur les "sous-collections", actuellement problématique : si un BO a une propriété contenant une liste de 10 000 objets, et que ceux-ci ne sont pas des des BO, alors on les remonte tous. Actuellement les fields permet de "limiter les dégats", mais le pb existera toujours tant que le dev ne transformera pas cette "sous-entité" en un BO avec sa propre API. Peut-être que la solution est à ce niveau d'ailleurs : c'est de la responsabilité des devs de structurer correctement leur domain.

[nfaugout-lucca]

c'est de la responsabilité des devs de structurer correctement leur domain.

Voilà pour moi c'est ça la solution. Faire en sorte de ne pas se retrouver dans une situation délicate (trop de fields sur une entité, trop de sous objets), de sorte qu'on n'ait pas besoin des fields.

Mais on les laisse parce qu'on sait bien que assez souvent ça dépanne bien.

[Poltuu]

à mon humble avis, virer les fields, c de la science fiction. C'est largement la feature la plus utilisée dans le monolithe et dans rdd. Si tu vires les fields, que va-t-il se passer ? Les objets ne vont pas changer de taille, car la taille des objets n'est pas lié à la feature, les includes ne seront plus pilotés par le front, mais toujours joués. Les fronteux ne vont pas changer leurs habitudes, car ils devraient dès aujourd'hui embrasser le http2 et faire plus de petites requêtes, mais ce n'est comme ça qu'ils aiment faire.

Ce qu'on essaye de vendre là en fait c'est quoi ? c'est genre faite n apis qui correspondent quasi 1 pour 1 avec les n tables en base, et puis faites n appels sur ces apis, chargez les données dans le client, indexés par id, et roulez jeunesse, le front est prêt. Coté back, c sur, c plus simple (encore que pour les droits, on se rends vite compte que ça ne marche pas souvent comme ça). Pour le front, ça implique de modifier tous leurs réflexes, et les boucliers vont se lever.

[GMouron]

:+1, et pas que chez les fronteux 😛