it-swarm.com.de

Ist es normal, Backend- und Frontend-Webanwendungen vollständig zu entkoppeln und ihnen die Kommunikation mit (JSON) REST API) zu ermöglichen?

Ich erstelle eine neue Business-Webanwendung und möchte Folgendes erreichen:

  • Verwenden Sie die besten Technologien aus ihren jeweiligen Bereichen. Ich möchte ein zuverlässiges Backend-Framework mit soliden ORM. Und ich möchte das fortschrittlichste SPA-Framework (Single Page Application) mit den aktuellsten HTML- und Javascript-Funktionen für die Frontend-Anwendung
  • Stellen Sie Backend-Entitäten und Geschäftsdienste für die Verwendung aus verschiedenen Arten von Anwendungen bereit - z. Webanwendungen, mobile (Android) und möglicherweise andere Arten (intelligente Geräte usw.)

Um beide Anforderungen zu erfüllen, neige ich dazu, meine Anwendung in Backend- und Frontend-Anwendungen vollständig zu trennen und die Kommunikation zwischen ihnen mithilfe von REST API (JSON). Ist das ein vernünftiger Ansatz?

Eine solche Trennung ist keine offensichtliche Entwurfslösung, da viele Webanwendungstechnologien Ansichtsebenen integriert haben, in denen die serverseitige Anwendung die Generierung der Ansicht mehr oder weniger steuert und die Antworten aus der Ansicht teilweise verarbeitet (z. B. SpringMVC mit Ansichtsebene, PHP Yii mit Ansichtsebene, Java JSF/Facelets speichert den Status ihrer Komponenten vollständig auf dem Server). Es gibt also viele Technologien, die eine stärkere Kopplung vorschlagen und eine schnellere Entwicklungszeit und eine standardmäßigere Pfadfahrt versprechen. Daher muss ich vorsichtig sein, wenn ich anfange, Technologien auf eine Art und Weise einzusetzen, die nicht weit verbreitet ist.

Soweit ich weiß, ergibt sich dann ein vollständig getrenntes SPA-Frontend normalerweise aus der Notwendigkeit, eine Drittanbieter-API zu verwenden. Aber ist ein solches entkoppelndes Sounddesign, wenn sowohl Backend als auch Frontend von einer Firma entwickelt werden?

Meine Auswahl an Technologien ist derzeit Java/Spring-Backend und Angular2/Web Components/Polymer für das Frontend - wenn ich das sagen darf. Aber das ist für diese Frage irrelevant, denn bei dieser Frage geht es um allgemeines Design und nicht um die Wahl konkreter Technologien?

21
TomR

Ist es normal, Backend- und Frontend-Webanwendungen vollständig zu entkoppeln und ihnen die Kommunikation mit (JSON) REST API) zu ermöglichen?

Ja, das ist normal. Es ist jedoch nur dann normal, wenn Sie diese Art der Trennung benötigen und dieses Setup nicht in Ihre Gesamtanwendung erzwingen.

Ein SPA bringt einige Probleme mit sich. Hier sind nur einige, die mir jetzt in den Sinn kommen:

  • es ist meistens JavaScript. Ein Fehler in einem Abschnitt Ihrer Anwendung kann aufgrund dieses Javascript-Fehlers dazu führen, dass andere Abschnitte der Anwendung nicht mehr funktionieren. Mit Seiten, die vom Server bereitgestellt werden (SpringMVC, PHP usw.), laden Sie einen neuen Abschnitt neu.
  • CORS . Nicht unbedingt obligatorisch, aber häufig befindet sich das Back-End unter einem anderen Domainnamen als das Front-End. Jetzt müssen Sie sich mit Browsersicherheitsproblemen befassen.
  • SEO . Brauchst du das? Ist Ihre Website öffentlich? Google kann Javascript verstehen und versuchen, aus Ihrer Website einen Sinn zu machen, aber Sie geben einem Bot im Grunde die Kontrolle und hoffen auf das Beste. Die Kontrolle zurückzugewinnen bedeutet möglicherweise, sich auf andere Tools wie PhantomJS verlassen zu müssen.
  • separate Front-End-Anwendung bedeutet separate Projekte, Bereitstellungs-Pipelines, zusätzliche Tools usw.;
  • sicherheit ist schwieriger, wenn sich der gesamte Code auf dem Client befindet.

Natürlich gibt es auch SPA-Vorteile:

  • interagieren Sie vollständig im Front-End mit dem Benutzer und laden Sie die Daten nur nach Bedarf vom Server. So bessere Reaktionsfähigkeit und Benutzererfahrung;
  • abhängig von der Anwendung bedeutet eine auf dem Client durchgeführte Verarbeitung, dass Sie dem Server diese Berechnungen ersparen.
  • eine bessere Flexibilität bei der Weiterentwicklung des Back-End und des Front-End haben (Sie können dies separat tun);
  • wenn es sich bei Ihrem Back-End im Wesentlichen um eine API handelt, können Sie andere Clients wie native Android/iPhone-Anwendungen vor sich haben.
  • die Trennung erleichtert Front-End-Entwicklern möglicherweise die Ausführung von CSS/HTML, ohne dass eine Serveranwendung auf ihrem Computer ausgeführt werden muss.

Die Sache ist also, dass beide Ansätze Vor- und Nachteile haben (SPA vs. Serverseiten). Nehmen Sie sich etwas Zeit, um beide Optionen zu untersuchen, und wählen Sie sie dann basierend auf Ihrer Situation aus.

14
Bogdan

Die Antwort auf Ihre Frage ist einfach. Ja. Was Sie vorschlagen, ist ein Ton Ansatz. Aber ich denke, Sie möchten fragen, ob es sich um einen besseren Ansatz handelt, und leider kann keiner von uns dies für Sie beantworten. Die Faktoren umfassen zu viele Facetten, sodass keine wirklichen Schlussfolgerungen gezogen werden können, ohne alles über Ihr Unternehmen und die Produktanforderungen preiszugeben. Ich denke du weißt sowieso schon was zu tun ist.

1
samazi

Normal mit Vorbehalten.

front-End-Javascript-Frameworks sind in ihren Möglichkeiten begrenzt. Wenn Sie Raw-APIs für die Verwendung durch mehrere Anwendungen erstellen, müssen diese in der Regel serverseitig die Raw-API-Aufrufe in Ansichtsmodellen verarbeiten, die mit dieser bestimmten Anwendung funktionieren.

Daher könnte eine "normale" Architektur sein:

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

Wenn Sie nur eine Webanwendung haben, können Sie die Ebene "API Exposising Business Logic" ausschneiden und den serverseitigen Webcode die Geschäftslogik direkt aufrufen lassen.

Da Sie die Geschäftslogik in eine eigene Bibliothek unterteilt haben, ist sie immer noch von der UI-Logik entkoppelt, und Sie können später jederzeit eine Serviceschicht hinzufügen.

Da der API-Dienst über serverseitigen Code aufgerufen wird, ist die http-Kommunikation nicht eingeschränkt. (obwohl dies jetzt ziemlich universell ist)

Wenn das Javascript denselben Host aufruft, von dem es bedient wird, müssen Sie nicht mit Cors herumspielen

0
Ewan