Laden...

Verteilen von Ergebnisse

Erstellt von TotalerASPNETN00B vor 2 Jahren Letzter Beitrag vor 2 Jahren 501 Views
T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren
Verteilen von Ergebnisse

Hallo liebe Community,

Ich habe mir mit ASP Net Core v5.0.0 (C#) einen WebHook Daemon Service gebaut der auch soweit als Konsolenanwendung funktioniert. Jetzt möchte ich diesen erweitern, es sollen sich beliebig viele User (aber mit mehr als 50) mit einem bestimmten Front-End (in Python) mit dem Service verbinden können, jeder User hat aber eigene Filter Optionen und dadurch bekommt jeder User auch andere Ergebnisse von dem WebHook.

Mein erster aber (naiv ineffiziente) Gedanke, war jede Anfrage samt Anfrage Adresse in eine Datenbank (In Memory-DB ?!) zu speichern und diese Anfragen dann nach und nach abzuarbeiten und diese dann an die Front-End(s) zu schicken. Aber das ist aber eher unschön.

Hat jemand andere (bessere) Vorschläge ? 😉

Über freundliche Tipps würde ich mich sehr freuen

D
615 Beiträge seit 2009
vor 2 Jahren

Guten Tag

Eigentlich stellst du Events zur Verfügung. Die Subscriber können solche abonnieren um über "Änderungen" informiert zu werden. Dafür kannst du bspw. ein Pub/Sub Pattern verwenden.

Ein schöner Artikel mit ausführlichen Beschreibung findest du in diesem Blog.

Liebe Grüsse

T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Guten Morgen,

vielen dank für die sehr schnelle Rückmeldung 🙂

Ein Kumpel meinte es wäre besser das mit SignalR zu machen aber mein Front-End nutzt für die Logik ausschließlich (Python 3.x). Woanders bekam ich den Vorschlag es mit SSE, Websockets zu machen ich bin irgendwie erschlagen 😉

Ein Lehrer meinte das Observer und Pub-Sub Pattern ansich das gleiche wären, wie stehst Du dazu ?

D
615 Beiträge seit 2009
vor 2 Jahren

Ein Kumpel meinte es wäre besser das mit SignalR

Irgendwo brauchst du ein Backend um Pub/Sub (siehe erste Antwort) zu managen. SignalR kannst du im Frontend einsetzen um anhand von Notifications eines WebHook im GUI etwas anzuzeigen oder was anderes zu wurschteln 🙂

Woanders bekam ich den Vorschlag es mit SSE

Hier sind die Unterschiede erklärt.

Beste Grüsse

T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Also den Webhook-Service selbst will ich nicht verändern der funktioniert einwandfrei, ich will halt nur die "personalisierten" Benachrichtigungen(JSON´s) an die n Clients schicken. Pub/Sub Muster klingt schon sinnvoll.

16.806 Beiträge seit 2008
vor 2 Jahren

TotalerASPNETN00B, bitte lass die Full Quotes -> [Hinweis] Wie poste ich richtig?
Erspar uns den Aufwand bitte, dass wir jeden Deiner Beiträge editieren müssten. Danke!

Zum Thema:
SignalR bzw. WebSockets (mit SignalR) ist der in .NET übliche Weg, um Clients zu benachrichtigen.
WebHooks haben einen anderen Zweck als die aktive Benachrichtigung von Clients.

Aber so wie ich das verstehe spielt das Thema WebHook hier keine Rolle (verwirrt eher), weil es mit den Clients nichts zutun hat.
Das ist halt Dein Dateneingang.

Ein Lehrer meinte das Observer und Pub-Sub Pattern ansich das gleiche wären, wie stehst Du dazu ?

Observer und PubSub ist nicht das gleiche.
Sind zwei verschiedene Vorgehensweisen mit teilweise gleichen use cases.

Kurz:

  • Beim Observer Pattern kennt der Ersteller den Empfänger
  • Beim PubSub Pattern gibt es eine zusätzliche Abstraktion, den Event Channel. Dadurch müssen sich Ersteller und Empfänger nicht kennen.
T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Zum Thema:
SignalR bzw. WebSockets (mit SignalR) ist der in .NET übliche Weg, um Clients zu benachrichtigen.
WebHooks haben einen anderen Zweck als die aktive Benachrichtigung von Clients.

Hallo,

vielleicht muss ich es genauer beschreiben. Ich wollte einen Mechanismus der mich benachrichtigt das es Änderungen in Azure gab, dies machte ich nach diesen Übungen und diese realisiert Microsoft als Webhook. Jetzt bekomme ich in der Konsole Ressourcen-Änderungen angezeigt was gut ist. Jetzt will ich diesen Webhook "ausbauen" und von der reinen Konsolenanwendung weg und den Service mehreren Usern zur Verfügung stellen und jeder User des Front-Ends andere Wünsche hat, muss ich die irgendwie managen, also so ist mein Gedanke.

16.806 Beiträge seit 2008
vor 2 Jahren

Ich wollte einen Mechanismus der mich benachrichtigt das es Änderungen in Azure gab

Das ist die Dokumentation von Microsoft Graph und nicht von "ganz Azure".
Es gibt viele Wege gewisse Teilnehmer zu benachrichtigen, WebHooks ist nur einer davon - und kommt auch auf den Use Case an.

WebHooks verwendet man i.d.R. wenn man einen neutralen, event-basierten Weg benötigt, der hier gegeben ist. WebHooks sind ein klassisches Backend Konzept und hat mit Frontends nichts zutun.
Aber WebHooks sind kein Allzweckmittel für jede Event Benachrichtigung in "ganz Azure".

Jetzt will ich diesen Webhook "ausbauen" und von der reinen Konsolenanwendung weg und den Service mehreren Usern zur Verfügung stellen und jeder User des Front-Ends andere Wünsche hat, muss ich die irgendwie managen, also so ist mein Gedanke.

In der Form ist das halt falsch formuliert.
Du kannst keinen "WebHook ausbauen", vor allem nicht von fremden Systemen.
Für Dein Problem ist der WebHook sogar egal, weil das an einer anderen Stelle stattfindet. Ob der Event von einem WebHook kommt oder von woanders ist für die Client-Information irrelevant.

  • Du hast einen Informationsfluss, er von einem WebHook ausgelöst wird
  • Die Daten willst Du aufarbeiten, speicher, was auch immer
  • Du willst die aufgearbeiteten Informationen Clients zur Verfügung stellen.

Der Architektur-Begriff nennt sich in diesem Fall Event Sourcing und es gibt in Azure viele Wege sowas umzusetzen.
Das geht mit Konsolen-Applikationen, das geht mit Docker-Containern, das geht mit Web-Apps, mit Logic Apps, mit Functions...

Daher: WebHooks spielen für die Sache, dass Du Clients informieren willst, keine Rolle 🙂

Aber die Client-Benachrichtigung kannst Du aber in allen Fällen über WebSockets machen.
Und als fertiges Framework gibts dazu zB SignalR und als fertigen Service gibts dazu zB Azure SignalR.

T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Aber die Client-Benachrichtigung kannst Du aber in allen Fällen über WebSockets machen.
Und als fertiges Framework gibts dazu zB SignalR und als fertigen Service gibts dazu zB Azure SignalR.

Ok, ich hab Videos zu SingalR gefunden ,die waren aber schon älter, dort wurde erklärt das dass Fron-End in JavaScript geschrieben sein muss, stimmt das eigentlich (noch) ?! Oder ist es egal in welcher Programmiersprache das Front-End geschrieben ist ?!

16.806 Beiträge seit 2008
vor 2 Jahren

Wieso schaust dann veraltete Videos an statt die aktuelle Dokumentation auf Real-time ASP.NET with SignalR | .NET ?
Da siehst ja, dass es ein offenes Protokoll ist und für mehr als nur .NET und JavaScript Clients existieren.

Und dann gibts da noch so ne große Suchmaschine, die einem helfen kann 🙂Google Suche nach "signalr python"

T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Und dann gibts da noch so ne große Suchmaschine, die einem helfen kann 🙂
>

Ja es gibt nette Python Libs, keine Frage, die scheine aber zum Teil älter zu sein 😉

M
368 Beiträge seit 2006
vor 2 Jahren

Front-End in JavaScript geschrieben sein muss, stimmt das eigentlich (noch) ?! Ob es ein Muss ist, sei dahingestellt. Auf jeden Fall gibt es neuere Ansätze, z.B. TypeScript (typisiertes JavaScript), Angular, Vue.JS, Aurelia, React (bekanntere JS-Frameworks)

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

T
TotalerASPNETN00B Themenstarter:in
20 Beiträge seit 2021
vor 2 Jahren

Ob es ein Muss ist, sei dahingestellt. Auf jeden Fall gibt es neuere Ansätze, z.B. TypeScript (typisiertes JavaScript), Angular, Vue.JS, Aurelia, React (bekanntere JS-Frameworks)

Hallo,

alles schön 🙂 aber das Front-End ist in Python, leider

P
441 Beiträge seit 2014
vor 2 Jahren

SignalR ist ein Protokoll Framework mit verschiedenen Implementierungen für Clients. Server gibt es meines Wissens nur in .NET.

Wichtig ist: es sollte auf dem Client laufen. Bei Python Webapps habe ich zuwenig Erfahrung um das direkt sagen zu können - prinzipiell würde ich aber tippen, dass der Python Anteil auf dem Server läuft. Damit hättest du vermutlich erst einmal keine Push Möglichkeit an den Client (oder es wird ein Teil versteckt).

Aber Google hilft dir da sicher weiter - hat Abt ja bereits geschrieben.