2 votes

Application à page unique (SPA) et applications à pile complète. Contraintes et avantages.

Je suis actuellement en train de faire évoluer notre application web d'une application web Spring MVC traditionnelle vers une application à page unique avec des points d'extrémité REST. Notre application MVC frontale actuelle n'utilise pas les appels REST pour communiquer avec le backend, mais communique plutôt avec le backend (écrit en JAVA) en appelant directement les façades nécessaires. Les fichiers JAR et WAR sont regroupés dans un seul fichier ear et déployés sur notre serveur de production (qui utilise actuellement JBoss EAP 6).

Puisque nous passons maintenant à une application à page unique et que nous mettons à jour notre système avec un nouvel ensemble d'API, je me demande si l'application à page unique et le reste du backend écrit en JAVA doivent être hébergés sur le même serveur (JBoss EAP 6) ? Ou doivent-ils être répartis sur des serveurs distincts, l'un pour servir le contenu de la SPA et l'autre pour exécuter le backend ? Dans ce dernier cas, quel serveur de production est le plus approprié pour héberger le contenu de l'application à page unique (JS, HTML et CSS) ? (notre backend sera toujours hébergé sur JBoss EAP 6)

Quels sont les avantages de séparer le front-end et le back-end sur des serveurs différents ?

J'ai essayé de rechercher les meilleures pratiques pour déployer des applications à page unique avec un point de terminaison JAVA REST, mais je n'ai pas trouvé d'articles utiles applicables à nos besoins.

Merci beaucoup d'avance ! :)

3voto

Shaunak Points 3769

Pour répondre à votre première question :

  • Oui, vous pouvez tout à fait les séparer, et idéalement vous devriez le faire afin de pouvoir déployer le front-end sans dépendre du back-end du service web.

  • Vous pouvez déployer les fichiers statiques de votre SPA avec n'importe quel serveur web populaire comme Apache, Nginx, ou même sur un hébergement en nuage comme S3 (derrière un CDN en nuage).

  • En supposant que vos points de terminaison REST soient toujours en Java, ils devraient résider dans un serveur d'application Java comme jBOSS, tomcat ou glass fish.

Contraintes/Gotchas :

  1. Domaine croisé :

    • Vous pouvez soit placer votre JBOSS derrière le même proxy inverse Apache/Nginx qui exécute vos fichiers statiques.

    • Vous pouvez également activer CORS sur les services web si vos domaines sont séparés.

    • Enfin, jsonp est toujours une option si vos services web sont en JSON.

  2. Authentification et sécurité :

    • Généralement, lorsque vous utilisez un framework web complet comme Spring, vous bénéficiez d'une grande sécurité et d'une authentification dès le départ. Vous pouvez protéger votre site en utilisant des sessions, CSRF, etc. Cependant, avec REST, vous devez généralement utiliser une authentification basée sur des jetons pour votre front-end afin de communiquer avec les services REST. Ce n'est pas nécessairement difficile, mais c'est une approche différente, et c'est pourquoi elle est listée dans les contraintes.

Avantages :

  1. Il est plus facile de faire évoluer le back-end et le front-end séparément, avec une SPA statique sur un service comme amazon S3 et CloudFront CDN, vous pouvez faire évoluer cette partie à l'infini.

  2. Les services web back-end peuvent maintenant être facilement placés derrière un modèle de cluster d'équilibreur de charge parce que vos services sont REST.

  3. Il est beaucoup plus facile de s'occuper des déploiements aujourd'hui grâce à la séparation des préoccupations.

  4. Moins de problèmes de régression lorsque l'on ne pousse que les modifications du front-end. Il n'est plus nécessaire de remplacer tout le fichier WAR.

Serveurs séparés ou non

Cela dépend du type de trafic que votre application est censée gérer. Permettez-moi de vous présenter trois scénarios.

  1. Faible trafic : Vous pouvez placer un serveur avec le serveur Java App derrière le proxy inverse de ce serveur Web. Le serveur web servira également de répertoire à la SPA.

  2. Trafic modéré : Vous devriez séparer le serveur frontal et le serveur web sur un seul serveur web et avoir les services REST hébergés sur une machine séparée. Techniquement, cette configuration ne sera pas très différente de l'option 1, mais votre serveur d'applications ne sera pas en concurrence avec le serveur Web pour les cycles de CPU afin de répondre aux demandes.

  3. Trafic élevé : Même chose que l'option 2, mais maintenant vous pouvez avoir plusieurs serveurs d'applications et serveurs Web SPA et avoir un Apache/Nginx pour équilibrer la charge au sommet.

  4. Trafic insensé sur une vaste zone géographique : Dans ce cas, vous ne devez pas héberger vous-même ces SAP. Il serait préférable d'opter pour un service comme Amazon S3 derrière CloudFront CDN, de sorte que votre contenu statique soit répliqué dans le monde entier pour des temps de réponse optimaux. Cela réduira également la charge sur vos serveurs. Passons maintenant au serveur d'application qui hébergera les points d'extrémité REST. Vous pouvez soit utiliser vos propres serveurs dans le nuage pour héberger votre cluster, soit utiliser un PAAS comme Heroku ou Amazon pour héberger vos fichiers WAR et les faire évoluer à la demande.

Remarque : ces scénarios de mise à l'échelle ne tiennent pas compte de la base de données, car vous auriez besoin de plus d'informations sur votre base de données pour déterminer comment la mettre à l'échelle dans les scénarios ci-dessus.

J'espère que cela vous aidera. N'hésitez pas à me faire savoir si vous avez besoin de précisions sur l'un ou l'autre des points mentionnés.

0voto

McBoman Points 379

C'est une question de goût.

Je préfère créer une SPA à l'aide d'un générateur tel que Yeoman et créez ensuite un service avec la configuration propre à Spring IO pour les webservices (exemple ici : Spring webservice exemple ) ou Jersey aquí .

En ce qui concerne le déploiement, existe-t-il plusieurs configurations ?

Apache | Nginx | S3. Voici un excellent article pour déployer une application AngularJS : Déploiement d'une application angulaire

Vous devrez probablement continuer à utiliser Tomcat, Glashfish ou JBOSS ect pour la partie Java.

Il ne s'agit pas d'une réponse, mais seulement d'un choix de mon goût.

0voto

ShahSahab Points 5

De nos jours, le front-end est principalement hébergé sur des serveurs séparés et les services back-end sur des clouds comme AWS. FireBase pour le front-end (Html, CSS, JS, Angular) et bien sûr vous pouvez utiliser un serveur séparé pour les services back-end, il est également possible d'utiliser Spring MVC comme votre framework actuel avec lui en tant que restful services.

Jetez un coup d'œil à ceci démo

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X