Angularjs est si puissant. Il a implémenté MVC dans le frontend, etc. Pour obtenir des données, utilisez-vous habituellement $http pour les obtenir depuis le backend ? Dans ce cas, le backend ne devrait-il pas simplement écrire des API ?
Quels sont les frameworks généraux pour écrire des API en PHP ? Laravel semble très tricher, mais il a un moteur de template, est-il adapté ?
Il vaut mieux écrire directement sans framework
Désolé, je n'ai pas assez de réputation pour l'aimer ! o(╯□╰)o
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
NG est un framework front-end MVVM, idéalement, il permettrait une séparation complète du front-end et du back-end et ne fournirait des API que dans le backend. Le découplage du front-end et du back-end est obtenu. Ce découplage nous permet de développer des applications front-end et back-end indépendantes. La manière dont le navigateur consomme l'API back-end est également adaptée aux appareils mobiles tels que l'iPhone Andoird. Lorsque nous développons des applications front-end, le langage de programmation back-end n'est plus nécessaire, seul HTML/CSS/JS est nécessaire, ce qui est une libération pour la plupart des développeurs front-end.
C'est une bonne chose. Et personnellement, je pense que cela ne peut pas être attribué uniquement à Angular, cela a aussi beaucoup à voir avec l'acceptation généralisée des interfaces de style RESTful
Tous les frameworks, conceptions et projets n'ont finalement qu'une seule direction : Laissez chacun se concentrer sur son propre domaine
Avant Angular, il existait également des frameworks front-end pour SPA (Single Page Application), tels que extjs, qui plaçaient également l'intégralité de la couche de vue du côté du navigateur.
La méthode de développement de SPA résout un problème de maintenance très important : Zones sales des modèles front-end et back-end Dans le passé, cette zone nécessitait une maintenance conjointe du front-end et du front-end. fin, mais maintenant ce n'est plus nécessaire. Les ingénieurs back-end ne sont plus nécessaires Participer directementau travail de la couche de présentation
.Cependant, comme il n'existe pas de style d'interface largement reconnu, il est toujours inévitable de prendre en compte la couche de présentation lors de la conception de l'interface, ce qui rend sa réutilisation difficile. La situation la plus courante consiste à développer à plusieurs reprises plusieurs sockets pour des ressources back-end similaires, ce qui constitue en fait une perte de temps précieux pour les ingénieurs back-end.
On peut dire que garantir des ingénieurs back-end
只管写接口，只管把接口写好d'un point de vue technique est une énorme libération de productivité back-end.Pour y parvenir, il est nécessaire de disposer d'un ensemble de styles d'interface généralement acceptés par le front et le back-end, qui peuvent répondre aux besoins d'accès aux ressources multi-pages et même multi-plateformes, et en même temps avoir une bonne sémantique et une bonne capacité de cache
La réponse est RESTful
Avec l'acceptation généralisée des interfaces de style RESTful, le front-end n'a pas besoin de considérer avec quel back-end coopérer au niveau du framework, tant qu'il accède aux ressources RESTful. Les ingénieurs backend sont complètement découplés de la couche de présentation, que le client utilise angulaire/backbone ou mobile. Écrivez simplement l'interface et écrivez l'interface
Quand chacun se concentre sur son propre domaine, c'est là que la valeur est maximisée
Théoriquement oui,
.Si votre application est transformée en SPA, le backend n'a besoin que d'une seule route racine pour afficher la page. Le reste sont des routes API
Mais dans les projets réels, que SPA soit facile à utiliser et qu'il y ait de nombreux pièges, alors il est nécessaire de combiner le routage hybride back-end avec le SPA front-end.
Le backend écrit simplement une API, ce qui ressemble presque à ça