SPA-Architektur für CRM-Systeme: Teil 1

    Einführung

    Vor kurzem stand ich vor einem Projekt zur Fertigstellung des von CRM geschriebenen Dokuments. Ziel der Überarbeitung war es, die Geschwindigkeit des Systems bei der Interaktion mit dem Benutzer zu erhöhen, neue Funktionen hinzuzufügen und Speicherlecks zu beseitigen, die von früheren Entwicklern entdeckt und in JavaScript, auf dem die gesamte Benutzeroberfläche implementiert war, noch nicht beseitigt wurden.
    Nachdem wir angefangen hatten, uns an dem Projekt zu beteiligen, in den Eingeweiden einer Vielzahl von Bibliotheken und Frameworks zu stöbern und nicht sehr freundlich miteinander umzugehen, und eine Reihe von Experimenten durchgeführt hatten, kamen wir zu dem unerwarteten Schluss, dass alles schuld war ... SPA-Architektur.


    Ein paar Worte zur SPA-Architektur

    Wenn man über das moderne Web spricht, hört man immer mehr über die Technologie der Single Page Application (SPA), obwohl SPA der kollektive Name einer Reihe von Technologien ist, mit denen Sie eine WEB-Anwendung, die von einem WEB-Browser ausgeführt wird, als einzelne WEB-Seite implementieren können Implementierte beispielsweise den Google Mail-Dienst von Google. Aus Sicht des Benutzers besticht diese Technologie vor allem durch die schnelle Reaktion auf Aktionen in der Benutzeroberfläche, da kein vollständiges oder gar teilweises Neuladen der WEB-Seite vom Server erforderlich ist und alle visuellen Elemente direkt im Browser mithilfe von JavaScript durch Manipulation des DOM erstellt werden. Dokumentenstruktur.
    Somit werden WEB-Anwendungen zu gewöhnlichen Anwendungen für Workstations, die Informationen aus dem Internet herunterladen, und nur die Laufzeitumgebung ist für sie nicht das Betriebssystem, sondern der Browser, der folglich die gesamte Last tragen muss, die mit der Ausführung von Code von Drittanbietern verbunden ist nämlich Speicherverwaltung, Gewährleistung einer sicheren Umgebung, Bereitstellung von Funktionen für die Arbeit mit Systemfunktionen und Hardwareumgebung usw.

    Der zentrale Ort der SPA-Architektur ist View (Ansicht) - was der Benutzer sieht und mit dem er interagiert. Das Ergebnis der Ansicht ist das am häufigsten vom Browser angezeigte HTML. Im Gegensatz zu "transienten" "WEB 2.0" -Anwendungen, die aktiv mit der DOM-Struktur des Dokuments arbeiten, z. B. mit jQuery oder Unterstrich, verwendet die SPA-Anwendung das DOM nur zum Schreiben von Änderungen, nicht jedoch zum Lesen, dh nicht zum Speichern von Daten . Zum Speichern von Daten wird jetzt eine andere Komponente der SPA-Architektur verwendet - Model.

    Ein Modell ist eine Sammlung von Daten, Funktionen zum Bearbeiten von Daten und Ereignissen. Alle Modelldaten werden vollständig gespeichert. Damit die Daten im Modell und die von der Ansicht angezeigten Daten ihre Integrität behalten, abonniert die Ansicht Modellereignisse und verfolgt so Änderungen an den Daten im Modell. Im Gegenzug reagiert das Modell auch auf Präsentationsbenachrichtigungen und stellt eine untrennbare Verbindung zwischen der WEB-Anwendung und dem Server her, wobei Anforderungen zum Empfangen oder Senden von Daten (insbesondere unter Verwendung der REST-Methode) ausgeführt werden.

    Aber zurück zur Ansicht. Leistung ist der wichtigste und komplexeste Teil des modernen SPA. Normalerweise werden Repräsentationen um die sogenannten Templates erstellt - Leerzeichen, die in HTML konvertiert werden. Außerdem aktualisiert die Ansicht den empfangenen HTML-Code, wenn sich das Modell ändert, und umgekehrt - benachrichtigt das Modell über Benutzeraktionen mit der Ansicht, z. B. Mausklick, Tastatureingabe oder Gerätedrehung, wodurch das Modell Datenmanipulationen durchführen und anschließend erneut die Ansicht über die Datenänderung benachrichtigen kann für die Ansicht, um neues HTML zu aktualisieren oder zu generieren.
    Die Arbeit der klassischen WEB-Anwendung (oder WEB-Site) basiert vollständig auf dem Daten-Caching: auf dem Server, auf dem Proxy-Server und auf dem Client. Wenn die Daten und der Status der Anwendung sehr häufig aktualisiert werden, wird der Vorteil der Verwendung von Caching fast ausgeglichen. Theoretisch sollte eine Einzelseitenanwendung den Cache weniger belegen, da die Daten während des Seitenlebenszyklus einmal geladen werden. In der Praxis ist dies jedoch nicht immer der Fall, und wir werden im Folgenden darauf eingehen.

    CRM-Funktionen, die nicht in die SPA-Implementierung passen

    Sehen wir uns an, wie wir mithilfe der SPA-Technologie ein einfaches Customer Relationship Management-System (CRM) implementieren können. Zunächst interessieren uns die operativen und analytischen Ebenen der Informationsverarbeitung.

    Nehmen Sie zum Beispiel einen sehr vereinfachten Satz von Abschnitten des einfachen CRM:

    • Desktop (Dashboard) - eine Zusammenfassung aller Systemdaten, die für einen bestimmten Benutzer sinnvoll sind.
    • Ereignisse - Zeigen Sie die gemeinsamen Aktionen der Benutzer der Abteilungen Marketing, Vertrieb und Produktion an.
    • Kunden - Verwaltung des Kundenstamms, der Kontakte und der Unternehmen.
    • Projekte und Transaktionen - Kundenbeziehungsmanagement.
    • Aufgaben - Verwaltung des Implementierungsworkflows.
    • Berichte - Anzeigen und Verwalten von Analyseberichten zu den gesammelten Informationen.
    • Profil - Verwalten Sie Ihr Benutzerprofil.

    In jedem Abschnitt arbeitet der Benutzer mit Stichproben häufig geänderter Daten. Eine der entscheidenden Anforderungen für CRM auf operativer Ebene ist die hohe Leistung bei der Interaktion mit dem Benutzer, wenn Vorgänge wie der häufige Zugriff auf die Informationsregistrierung, der aktive Einsatz komplexer Filterung und Sortierung einer großen Menge von Ergebnissen ausgeführt werden. Auch auf analytischer Ebene müssen Sie schnell Berichte, Statistiken, Analysen und Prognosen für verschiedene Metriken und Indikatoren erhalten.

    In einer einseitigen Anwendung arbeiten wir mit "Bildschirmen" anstelle von Seiten. Jeder Bildschirm ist Teil eines Subsystems mit eigenen Vorlagen, Modulen, Controllern, Routen und Modellen. Wenn der Benutzer zu einem anderen Abschnitt der Anwendung navigiert und die Daten, Vorlagen und Module geladen werden, die für den Betrieb dieses Abschnitts erforderlich sind, ist es wichtig, dass sich der Benutzer auf derselben Seite befindet und der aktuelle Status beim Laden eines neuen Bildschirms gespeichert wird.

    Das allgemeine Modell des gesamten Systems ist komplex und besteht aus unabhängigen Modellen für jeden Bildschirm. Das Wechseln zwischen Bildschirmen löscht die aktuelle Ebene der Ansicht und generiert eine neue Ebene, die häufig so implementiert wird, dass die vorherige Ebene einfach unsichtbar wird und stattdessen eine neue angezeigt wird. Das heißt, der Prozess des Wechsels zwischen Bildschirmen ist so angeordnet, dass nach dem erstmaligen Laden fertige Ansichten angezeigt werden im Folgenden einfach ausgeblendet und angezeigt.

    Dies unterscheidet sich stark von der klassischen Arbeitsweise mit einer WEB-Anwendung, bei der das Klicken auf Links eine vollständige Seitenladung verursacht, die automatisch die Freigabe von Ressourcen und die Aktualisierung von Daten bewirkt, und der Benutzer kann davon ausgehen, dass die Daten immer auf dem neuesten Stand sind. Um die Erwartungen des Benutzers während der SPA-Implementierung zu bestätigen, müssen im Zusammenhang mit sich schnell ändernden Daten in CRM beim Wechsel zwischen Bildschirmen auch alle Daten vom Server neu geladen werden, was den Vorteil negiert, dass alle Daten auf dem Client und folglich auf der Anwendung selbst gespeichert werden SPA-Architektur.

    Probleme, die bei der Verwendung von SPA in der CRM

    SPA-Technologie auftreten, zwingen den Entwickler, den Code sehr sorgfältig zu schreiben, da Fehler oder Versehen zu Speicherverlusten und damit zu den „Bremsen“ des gesamten Systems führen können.

    Warum fließt die Erinnerung?

    Eine große Menge von Daten, die sich während der Langzeitarbeit auf dem Client angesammelt haben, werden sehr schnell irrelevant. In der Zwischenzeit werden diese Daten im Modell und die Ansichten in der DOM-Struktur des Dokuments gespeichert, wenn Sie nicht gezielt bereinigen. Um das Modell und das DOM „sauber“ zu halten, ist eine regelmäßige „Garbage Collection“ erforderlich, da Sie sich in diesem Fall nicht auf den integrierten JIT-Garbage Collector verlassen sollten, da Referenzen auf Objekte in der Regel erreichbar bleiben und daher zuvor erstellt wurden und nicht mehr benötigte Objekte bleiben im Speicher. Es ist auch zu berücksichtigen, dass in JavaScript immer die Gefahr besteht, dass alle Links verloren gehen, die Daten jedoch nicht gelöscht werden.

    Warum verlangsamt sich alles?

    Die Verlangsamung der Seite wird hauptsächlich durch Speicherverluste und ein komplexes Modell mit einer großen Anzahl von Ereignishandlern verursacht. Beim Wechsel von Bildschirm zu Bildschirm werden beim Öffnen jedes neuen Formulars Daten in den Browserprozess geladen sowie ausführbarer Code (im Fall von AMD), der häufig mithilfe von eval () -Konstrukten implementiert wird. Modulare Frameworks für den Bau von SPA haben auch eine eigene Infrastruktur mit eigenen Kosten. Der häufigste Grund sind die Fehler und Mängel des Entwicklers, die sehr einfach zu machen und äußerst schwer zu verfolgen sind. Komplexe SPAs zu profilieren und zu debuggen ist teuer: Obwohl Debugging-Tools bereits weit fortgeschritten sind, nimmt die Komplexität des Debuggens mit der zunehmenden Komplexität der Anwendung exponentiell zu. Infolgedessen wird das Problem nur durch modulares Debuggen und Testen gelöst.
    Wie spiegeln sich diese Probleme in der CRM-Entwicklung wider?

    Bei der Entwicklung von CRM sind eine große Anzahl von Bildschirmen und Formularen, unterschiedliche Logik je nach Benutzertyp, ihre Rechte und Berechtigungen, sehr veraltete Daten und die Notwendigkeit einer regelmäßigen Aktualisierung des Zustands des gesamten Systems die Hauptfaktoren, die die Entwicklung von CRM auf der SPA-Technologie erschweren. Während des Betriebs wächst das Datenvolumen, das Modell wächst, und folglich nimmt die Zeit für die Datenverarbeitung zu. Infolgedessen verlangsamt sich das System, selbst wenn es sich in Tests als akzeptabel erwiesen hat.

    Problem mit mehreren Bildschirmen

    Benutzer von Registerkarten-Browsern auf derselben Seite öffnen häufig separate Seiten durch Links in separaten Browser-Registerkarten und kombinieren diese mit Klicks auf Links auf derselben Registerkarte. Ich hätte gerne eine solche Gelegenheit, wenn ich mit einer WEB-Anwendung arbeite: Zum Beispiel, um die Projektseite in einem separaten Tab zu öffnen und sie am Puls der Zeit zu halten. Im Fall von SPA ist dies ebenfalls möglich, aber in diesem Fall steigt der Aufwand für die Entwicklung stark an - wo beim Laden von Seiten gespart wurde, erhalten wir jetzt einen Überlauf, da die Anwendung auf jeder Registerkarte den gesamten Code herunterlädt, den sie benötigt, um zu arbeiten. Die Bedeutung von SPA als einseitige Anwendung geht verloren, da es für den Internetbenutzer offensichtlich ist, dass der Link in einem Browser eine neue Seite öffnen und sich nicht wie eine normale Anwendung verhalten sollte.

    Daher ist die SPA-Architektur bei der Entwicklung von CRM-Systemen unserer Meinung nach der klassischen Architektur einer mehrseitigen Anwendung mit der aktiven Verwendung von AJAX zur Aktualisierung von Daten weniger vorzuziehen.

    Die Problemstellung erwies sich als ziemlich umfangreich, weshalb wir die Geschichte ihrer Lösung für ein separates Material hinterlassen. Vielen Dank an alle, die gelesen haben.

    Jetzt auch beliebt: