Bei der Kommunikation mit dem ASP.NET Backend gibt es neben REST (Representational State Transfer) mit SignalR für das Web-Frontend, die Alternative über GraphQL zu kommunizieren.
Folgend ein kurzer Überblick über die Technologien.
REST mit SignalR
REST ist weit verbreitet und einfach anzuwenden. Mit gängigen Routen weiß sofort jeder Entwickler welche Daten von einem Endpunkt zu erwarten sind und wie diese mit den HTTP Methoden (GET, POST, PUT, DELETE) verarbeitet werden können.
Des Weiteren können Echtzeit Updates von Daten über SignalR (Websockets) an alle verbundenen UI-Clients gesendet werden, sodass sie stets über die neuesten Daten verfügen.
REST ist zudem zustandslos, wodurch es einfach über mehrere Instanzen horizontal skaliert werden kann.
Der Hauptvorteil von REST mit SignalR liegt vor allem darin, dass auf Serverseite bereits granular pro Endpunkt entschieden werden kann, wer, welche Daten, wie anfordern kann.
So kann auf Serverseite je nach Abfrage einfach unterschieden werden, ob der Benutzer berechtigt ist, die Daten abzufragen (Authentifizierung/Autorisierung) und wie die Anfrage möglichst schnell und effizient verarbeitet werden kann (Threading, Caching, vorkompilierte Queries).
GraphQL
Das von Facebook entwickelte GraphQL besticht vor allem durch seine Flexibilität. Es kann sowohl für Echtzeitkommunikation (Subscriptions) als auch für Abfragen von Daten verwendet werden. Und hierzu ist rein theoretisch nur ein einziger Endpunkt erforderlich. Das Web-Frontend kann also auf diesen einen Endpunkt vertrauen und muss nicht für jeden neue Endpunkt einen eigenen (HTTP, Websocket) Service implementieren und ist dadurch seltener von Code Änderungen im Backend betroffen.
Das Web-Frontend kann mit einer selbst erstellten Query, nur Daten abfragen welche es vom Backend benötigt. Hierdurch kann der Response klein gehalten und die Ladezeit verringert werden.
Besonders bei datenintensiven Applikationen in denen häufig Daten in verschiedenster Weise abgefragt und verändert werden, ist der Einsatz von GraphQL sinnvoll.
Der Vorteil dem Web-Frontend die Möglichkeit zu überlassen, die Queries selbst zu erstellen, kann allerdings schnell zum Nachteil werden, wenn auf Serverseite die Abfragen nicht performant ausgeführt werden können.
Hier ist es hilfreich, wenn das Frontend weiß, wie eine performante Query auszusehen hat oder in der SW-Architektur (z.B. mit Micro-Frontends) bereits entsprechende Vorkehrungen zur Datenaggregation getroffen wurden.
Fazit
GraphQL ist besonders hilfreich, wenn die Daten auf unterschiedlichste Weise und Form abgefragt und manipuliert werden sollen.
Hierbei sollte möglichst wenig Infrastruktur zwischen der Datenbank und dem Web-Frontend stehen, sodass die Datenaggregation einfach zu bewerkstelligen ist.
Wenn die Flexibilität bei der Datenabfrage nicht das Hauptaugenmerk ist, ist der Einsatz von REST mit SignalR aufgrund seiner granularen Skalierbarkeit zu empfehlen. So können Services einfacher skaliert und sicherheits- und performancekritische Aspekte zuverlässig implementiert werden.
Je nach Anwendungsfall gilt es abzuwägen, welche Technologie besser geeignet ist.
Der Parallelbetrieb beider Technologien ist ebenso möglich.
