web-dev-qa-db-fra.com

Est-il normal de découpler complètement les applications Web dorsales et frontales et de leur permettre de communiquer avec (JSON) REST API?

Je crée une nouvelle application web d'entreprise et je souhaite atteindre:

  • Utilisez les meilleures technologies de leurs domaines respectifs. Je veux un framework backend fiable avec un ORM solide. Et je veux le framework SPA (application de page unique) le plus avancé avec l'utilisation des fonctionnalités HTML et Javascript les plus récentes pour l'application frontend
  • Exposer des entités back-end et des services métier à utiliser à partir de différents types d'applications - par exemple applications Web, mobiles (Android) et éventuellement d'autres types (appareils intelligents, etc.)

Donc - pour satisfaire les deux exigences, je suis enclin à séparer complètement mon application dans les applications backend et frontend et organiser la communication entre elles en utilisant REST API (JSON). Est-ce une bonne approche?

Une telle séparation n'est pas une solution de conception évidente, car de nombreuses technologies d'application Web ont des couches de vue intégrées où l'application côté serveur contrôle plus ou moins la génération de la vue et gère partiellement les réponses de la vue (par exemple SpringMVC avec couche de vue, PHP Yii avec couche de vue, Java JSF/Facelets enregistre complètement l'état de leurs composants sur le serveur). Donc - il y en a beaucoup les technologies qui proposent un couplage plus fort et promettent un temps de développement plus rapide et un parcours plus standard. Donc - je dois être prudent lorsque je commence à utiliser des technologies d'une manière qui n'est pas largement utilisée.

Si je comprends bien, le frontend SPA complètement séparé découle généralement de la nécessité d'utiliser une API tierce. Mais n tel découplage est-il une conception sonore lorsque le backend et le frontend sont développés par une seule entreprise?

Mon choix de technologies est actuellement Java/Spring backend et Angular2/Web Components/Polymer pour frontend - si j'ai le droit de le dire. Mais cela n'est pas pertinent pour cette question, car cette question concerne la conception générale et non le choix des technologies concrètes?

designrestapifront-endbackend
21
TomR

Est-il normal de découpler complètement les applications Web dorsales et frontales et de leur permettre de communiquer avec (JSON) REST API?

Oui, c'est normal. Mais ce n'est normal que si vous avez besoin de ce type de séparation et que vous ne forcez pas cette configuration dans votre application globale.

Un SPA est livré avec quelques problèmes qui lui sont associés. En voici quelques-unes qui me viennent à l'esprit:

  • c'est principalement JavaScript. Une erreur dans une section de votre application peut empêcher les autres sections de l'application de fonctionner en raison de cette erreur Javascript. Avec les pages servies depuis le serveur (SpringMVC, PHP, etc.), vous rechargez une nouvelle section;
  • CORS . Pas nécessairement obligatoire mais souvent le back-end est sur un nom de domaine différent du front-end. Alors maintenant, vous devez faire face aux problèmes de sécurité du navigateur;
  • SEO . As tu besoin de ça? Votre site est-il public? Google peut comprendre Javascript et essayer de donner un sens à votre site, mais vous donnez essentiellement le contrôle à un bot et espérez le meilleur. Reprendre le contrôle peut signifier devoir recourir à d'autres outils comme PhantomJS .
  • une application frontale distincte signifie des projets distincts, des pipelines de déploiement, des outils supplémentaires, etc.;
  • la sécurité est plus difficile à faire lorsque tout le code est sur le client;

Bien sûr, il y a aussi des avantages SPA:

  • interagir complètement dans le front-end avec l'utilisateur et ne charger que les données nécessaires depuis le serveur. Donc meilleure réactivité et expérience utilisateur;
  • selon l'application, certains traitements effectués sur le client signifient que vous épargnez le serveur de ces calculs.
  • avoir une meilleure flexibilité dans l'évolution du back-end et du front-end (vous pouvez le faire séparément);
  • si votre back-end est essentiellement une API, vous pouvez avoir d'autres clients devant lui comme des applications natives Android/iPhone;
  • la séparation pourrait rendre plus facile pour les développeurs front-end de faire CSS/HTML sans avoir besoin d'avoir une application serveur en cours d'exécution sur leur machine.

Donc, la chose est qu'il y a des avantages et des inconvénients aux deux approches (pages SPA vs pages serveur). Passez un peu de temps à rechercher les deux options, puis choisissez en fonction de votre situation.

14
Bogdan

La réponse à votre question est simple. Oui. Ce que vous proposez est une approche saine. Mais alors, ce que je pense que vous voulez demander, c'est si c'est une approche meilleure, et malheureusement, aucun de nous ne peut répondre à cela pour vous. Les facteurs impliqués couvrent trop de facettes, sans divulguer tout sur votre organisation et les exigences du produit, aucune conclusion réelle ne peut être tirée. Je pense que vous savez déjà quoi faire de toute façon.

1
samazi

Normal avec des mises en garde.

les frameworks javascript frontaux sont limités dans ce qu'ils peuvent faire. Si vous créez des API brutes à utiliser par plusieurs applications, elles nécessitent généralement un certain traitement côté serveur des appels d'API bruts dans les modèles de vue qui fonctionnent avec cette application particulière.

Par conséquent, une architecture "normale" pourrait être:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Maintenant, si vous n'avez qu'une seule application Web, vous pouvez couper la couche "API exposant la logique métier" et demander au code Web côté serveur d'appeler directement la logique métier.

Parce que vous avez séparé la logique métier dans sa propre bibliothèque, elle est toujours découplée de la logique d'interface utilisateur et vous pouvez toujours ajouter une couche de service plus tard.

De même, comme le service api est appelé par le code côté serveur, vous n'êtes pas limité par la communication http. (bien que ce soit à peu près universel maintenant)

De plus, le fait que le javascript appelle le même hôte à partir duquel il est servi signifie que vous n'avez pas à vous promener avec des cors

0
Ewan