4 raisons de séparer l'interface utilisateur et l'API de l'application Web

À moins que votre application Web soit composée à 100 % de code côté client, vous devez séparer le front-end et le back-end. Les gens tombent souvent dans le piège de dire qu'ils ne devraient pas passer du temps à développer une API et une application client distinctes, car le monde réel nécessite souvent de nombreux ajustements, ou ils pensent que leur application est trop petite et qu'aucune séparation n'est requise.

Ce genre d'application est ce que j'appelle une application tout-en-un. Dans ce type d'application, votre logique métier et votre interface utilisateur constituent une seule entité exécutée sur le serveur. Cependant, disposer d’une application Web avec un front-end et un back-end indépendants présente de nombreux avantages.

1. Modularisation

En divisant l'application en applications front-end et back-end distinctes, l'un des avantages est la modularité. La logique de l’application étant complètement séparée de l’interface utilisateur, votre application Web peut déjà avoir une structure modulaire rudimentaire. La modularité est utile à bien des égards, notamment en matière de tests, de lisibilité et de maintenabilité.

2. Réutilisabilité

En utilisant une seule API, votre logique applicative peut être réutilisée par de nombreuses applications. Cela signifie que vous pouvez créer une application mobile qui utilise l'API, ou utiliser l'API dans une application complètement distincte, ou autoriser d'autres personnes à accéder à l'API (gratuite ou payante).

3. Livraison de contenu

Étant donné que l'application client est une entité complètement indépendante, vous pouvez gérer des techniques avancées de service de fichiers statiques, tandis que dans les applications qui doivent restituer l'interface utilisateur côté serveur, ces technologies ne sont pas disponibles. Par exemple, il est désormais possible de mettre en cache des applications clientes entières à l’aide de NGINX et de quelques règles simples.

4. Réactivité

L'un des plus gros défauts des applications côté serveur « tout-en-un » est l'aspect de la réactivité des commentaires des utilisateurs. Dans les applications côté serveur, l'utilisateur clique sur un bouton pour obtenir des données. Le processus le plus courant est décrit comme suit :

1 L'utilisateur clique sur un bouton pour obtenir des données
2. au serveur Envoyer une requête
3. Le serveur interroge la base de données
4 L'application effectue un traitement logique sur les données
5. L'application présente les données dans la couche de présentation
6. renvoie la réponse à l'utilisateur
7. Les utilisateurs verront des commentaires après avoir attendu le chargement de la page
8. Avec une application client distincte, vous pouvez profiter de nombreux mécanismes de retour, tels que l'utilisation de chargeurs ou de barres de progression. Une fois votre demande renvoyée (par exemple via un appel AJAX), vous pouvez mettre à jour votre affichage.

5. Contrôle de version

Oui, j'ai ajouté un 5. Avec des projets d'API et d'interface utilisateur distincts, vous n'avez plus besoin de mettre à jour ou de déployer deux applications en même temps. Si un problème critique survient dans l'interface utilisateur nouvellement déployée, vous pouvez l'annuler sans vous soucier des modifications apportées aux performances que vous avez apportées au projet d'API.

Quels sont les avantages d’une architecture globale ?

Cette architecture séparée présente de nombreux avantages. Cependant, l’utilisation d’une architecture monolithique présente certains avantages. Par exemple, si votre application est incluse dans un projet, vous pouvez terminer le travail de développement plus rapidement. Ce n'est un secret pour personne qu'il y a beaucoup plus de codage impliqué dans l'interface utilisateur et l'API séparées (mais de nombreux frameworks facilitent cela). Il existe également certains avantages en matière de sécurité. Par exemple, vous n’exposez pas du tout l’API. Il existe des moyens de protéger une API, mais il vaut mieux ne pas l'exposer. Si vous pensez qu'il existe d'autres avantages, vous pouvez en parler en laissant un commentaire et discutons-en.

Conclusion

Cela semble être un choix normal pour de nombreux développeurs de logiciels. Cependant, certaines personnes, soit parce qu’elles ne connaissent pas le concept, soit par simple paresse, n’adoptent tout simplement pas cette architecture. En termes d’architecture globale, il existe de nombreux exemples qui n’utilisent peut-être pas cette structure mais qui sont également très réussis. Cependant, ce que je vois davantage, c'est que la séparation de l'API et de l'interface utilisateur apportera de nombreux avantages à l'avenir. Il est recommandé aux développeurs qui n'ont pas encore essayé ce concept de l'essayer et de ressentir par eux-mêmes les avantages de la séparation front-end et back-end.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!