La responsabilité de l'arrangement des éléments - frontend ou backend?
Dans notre entreprise, nous avons récemment eu une discussion sur la partie d'une demande qui est responsable de la (ré) disposition des éléments d'une liste.
La liste est une représentation visuelle des étapes à effectuer en production. Le backend le fournit dans l'ordre "normal" (1., 2., 3., 4.). Dans le frontend tout en haut devrait être le 4ème élément, en dessous le 3ème, en dessous du 2ème ... Comme c'est un site web, le frontend doit être rendu de haut en bas, c'est le mauvais ordre pour le site web. Il a besoin que les éléments soient 4., 3., 2., 1., afin de le rendre dans le bon sens.
Ce sont 10 articles au maximum qui sont tous affichés à chaque fois. Donc pas de pagination ou de filtres nécessaires.
Fondamentalement, le frontend a besoin des éléments dans l'ordre inverse dont le backend le renvoie. Mon collègue, un développeur frontend, dit que c'est le travail du backend. À mon avis (en tant que développeur backend), cela fait partie du frontend.
Ses points:
- le frontend est "intouchable". S'il y aura des changements dans la présentation, nous n'avons rien à changer dans le frontend,
- le frontend dit ce dont il a besoin et le backend doit s'adapter,
- le frontend est stupide - il ne devrait y avoir aucune logique.
Mes points:
- c'est une question de représentation. le backend ne devrait pas du tout avoir à s'en soucier. Il ne se soucie pas (et ne sait pas) dans quel ordre il a besoin des articles.
- mauvaise responsabilité. Je ne veux pas travailler sur le moteur de ma voiture si je veux changer de pneus, donc s'il y a des changements dans l'interface utilisateur (c'est-à-dire un autre arrangement), les changements devraient se produire dans l'interface utilisateur.
- Je ne veux pas être précis sur une interface utilisateur. Si nous choisissons d'ajouter une autre interface (ce que nous n'allons probablement pas faire) et cela ne va pas afficher la liste de la même manière, devons-nous fournir une autre méthode pour cela?
Je suppose que vous comprenez notre point de vue. Ce n'est pas une question d'implémentation car c'est probablement une ligne de code. C'est une question architecturale puisque nous prévoyons une nouvelle partie du système. Peut-être que nous avons juste besoin d'une autre couche entre les deux. Mais de quel côté, frontend ou backend?
Dernière édition: Merci à tous pour vos réponses, celles-ci étaient plus détaillées et détaillées que ce à quoi je m'attendais. Pour ceux qui sont intéressés, voici comment nous l'avons fait. Bien que la majorité ait recommandé de l'installer dans le backend, nous mettrons la logique dans le frontend. Pourquoi? Principalement parce que je l'ai décrit trop vaguement et que les réponses étaient basées sur des faits et des exigences que j'ai décrits trop tard. Par définition, cette liste de max. 10 éléments est ordonné dans le bon ordre. Et puisque le frontend en a besoin dans un autre ordre qui n'est dû qu'à la raison qu'il est plus facile de le rendre sur le Web de cette façon, c'est purement une chose de présentation. Ne vous méprenez pas, toutes les réponses ont été très utiles et nous en avons tiré beaucoup d'informations. Je suppose que la suringénierie était le mot clé dont nous avions besoin pour réaliser que nous n'aurons jamais besoin de filtres, de pagination ou de quoi que ce soit d'autre sur cette API. Mais bon sang, nous avons appris bien plus que ce à quoi nous nous attendions!
Toute API back-end décente doit recevoir des paramètres qui permettent une certaine personnalisation ou un filtrage des résultats qu'elle donne au client. Pour quelque chose qui renvoie une liste, il est généralement courant de fournir:
- paramètres de commande (ASC ou DESC) basés sur certains critères de champ;
- paramètres de pagination;
- les paramètres de la requête de recherche (c'est-à-dire le filtrage de la liste pour ne demander qu'un sous-ensemble d'enregistrements).
Ce n'est pas toujours une règle, mais souvent vous trouvez tous ces trois éléments combinés.
Avoir une API back-end ne renvoie qu'une liste de résultats, puis "c'est le problème du front-end ce qu'elle en fait" est la plupart du temps une mauvaise idée. Cela rend l'interface utilisateur plus compliquée, pour faire quelque chose que le back-end peut faire très facilement et sans impact sur les performances.
Commençons la discussion pendant une seconde et réfléchissons au cas d'utilisation de la pagination de la liste à l'intérieur de l'interface utilisateur. Allez-vous forcer le front-end à récupérer la liste entière, à la garder en mémoire et à faire la pagination côté client? Et si quelqu'un décide de demander la liste complète à chaque fois que l'utilisateur clique sur la page suivante?
Ce que je dis, c'est que c'est un compromis. Certaines choses doivent être faites sur le back-end, d'autres sur le front-end. Ce n'est pas "tout sur le back-end" ou "tout sur le front-end". Discutez-en entre vous et convenez de ce que l'API devrait renvoyer et des paramètres qu'elle devrait recevoir. Fondamentalement, pour créer une API flexible, pas une API rigide.
Et si cela ne vous dérange pas d'être complètement honnête, ce n'est pas une question architecturale. L'architecture est ce qui est important . L'ordre des éléments à l'écran n'est pas important, donc pas l'architecture.
Clients légers
Lorsque votre collègue dit que le client est stupide, il veut dire l'idée d'un client léger. Lorsque vous concevez votre API descriptive et avec non seulement de simples opérations CRUD (Créer, Lire, Mettre à jour, Supprimer), il est facile d'écrire un client stupide qui consomme simplement l'API et affiche simplement son résultat. Cette approche garantit que le frontend et le backend restent relativement simples.
Délégué au client
Maintenant, lorsque vous concevez une application plus grande dont les cas d'utilisation sont plus complexes, vous souhaiterez peut-être utiliser l'idée de déléguer un travail intensif au processeur au client. Lorsque votre serveur est utilisé par de nombreux clients, il est judicieux de déplacer des calculs individuels vers le client pour accélérer le système.
Big data
Le problème de la délégation au client réside dans la plupart des conceptions d'applications, votre couche de données est l'une des plus difficiles à optimiser les performances. Cela n'a aucun sens d'interroger une énorme liste de données, de l'envoyer au client et de l'afficher uniquement pour le filtrer ensuite. Lorsqu'il y a une certaine quantité de données, il est préférable d'utiliser les algorithmes de base de données hautement optimisés pour ordonner, filtrer et paginer vos données. Vous sécurisez également la bande passante.
Conclusion
Faites ce qui reste le plus simple et répondez à vos exigences de performance.
Adresse de l'édition
S'il n'y a qu'une seule commande correcte et qu'il n'est pas nécessaire de réorganiser les données pour une meilleure visualisation, c'est au backend de faire la commande.
Votre modification ajoute du contexte, ce qui est important pour l'OMI - il ne s'agit pas d'une source de données abstraite qui peut être affichée dans n'importe quel ordre ou qui sera triée par divers attributs. Il s'agit d'un processus physique avec une séquence définie.
Ce qui signifie que le backend, qui devrait en savoir le plus sur le processus, devrait donner les informations dans le bon ordre. Le frontend ne devrait pas avoir à se soucier du backend donnant les étapes du processus dans l'ordre inverse ou aléatoire.
Le front-end doit afficher les étapes dans l'ordre reçu, ce qu'il fait pour le faire (sans jeu de mots), c'est à lui.
Vous et votre collègue avez tous deux essentiellement raison de "ce que vous pensez". Ce que vous avez manqué, c'est un troisième élément central de la programmation moderne, le modèle. Dans l'architecture Model-View-Controller (MVC), le modèle est une série de fichiers de données, de tables de base de données ou d'autres sortes de "données" qui décrivent les champs, comment ils sont disposés, l'ordre des valeurs de sélection, etc. .
La vue est ce que vous avez appelé le "front-end", et en effet, elle devrait contenir un minimum de logique, comme le soutient votre collègue. En fait, à l'origine, les connexions à un ordinateur central se faisaient via un "terminal stupide". Ils ont été appelés ainsi parce qu'ils n'avaient pratiquement aucune logique et montraient simplement tout ce que le serveur affichait sans modification. Cependant, il pourrait y avoir des exceptions ici; peut-être qu'une vue pourrait avoir l'option "par défaut" en haut de la liste, ou autre chose, mais cela devrait être au cas par cas.
Le contrôleur est ce que vous avez appelé le "back-end", et il devrait être responsable de la validation des champs obligatoires, de l'application des règles métier, etc. Il ne devrait pas non plus spécifiquement dicter l'ordre des valeurs de sélection. Il doit consulter le modèle et retourner tout ce que le modèle définit. Dans ce cas, votre contrôleur est incorrect en renvoyant le modèle dans l'ordre "inverse".
En ajoutant un troisième composant, vous autorisez les administrateurs systèmes à modifier les valeurs de sélection sans avoir à affecter les règles métier ou à mettre à jour la logique frontale. En fait, le SA n'a même pas besoin d'être un programmeur dans cette situation, car les fichiers qui doivent être modifiés sont généralement exposés via une application d'administration d'une certaine forme. Même si vous ne Je ne pense pas que vous ayez besoin de ce type de flexibilité maintenant, c'est généralement un minimum d'effort pour coder quelque chose maintenant, donc vous avez l'option plus tard.
En fin de compte, votre système gagnerait à développer un modèle que le front-end et le back-end peuvent exploiter pour fournir une expérience cohérente. Ni les développeurs frontaux ni les développeurs principaux ne devraient se quereller sur l'ordre des valeurs de sélection, car il doit s'agir d'un fichier de données quelque part qui peut potentiellement être modifié pour affecter le comportement du système sans changer le code. Ce sera plus de travail pour vous maintenant, bien sûr, mais à la fin, tout le monde sera plus productif avec un modèle efficace en place.
Source: près de 15 ans d'expérience (à partir de 2019) avec salesforce.com en tant que support technique, consultant, administrateur et développeur.