Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Verteilen von Ergebnisse
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

Verteilen von Ergebnisse

beantworten | zitieren | melden

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
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von TotalerASPNETN00B am .
private Nachricht | Beiträge des Benutzers
Diräkt
myCSharp.de - Member



Dabei seit:
Beiträge: 622
Herkunft: Schweiz

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

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 ?
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von TotalerASPNETN00B am .
private Nachricht | Beiträge des Benutzers
Diräkt
myCSharp.de - Member



Dabei seit:
Beiträge: 622
Herkunft: Schweiz

beantworten | zitieren | melden

Zitat
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 :-)

Zitat
Woanders bekam ich den Vorschlag es mit SSE

Hier sind die Unterschiede erklärt.

Beste Grüsse
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Diräkt am .
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von TotalerASPNETN00B am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16152

beantworten | zitieren | melden

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.
Zitat
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16152

beantworten | zitieren | melden

Zitat von TotalerASPNETN00B
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".
Zitat von TotalerASPNETN00B
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt
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 ?!
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16152

beantworten | zitieren | melden

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"
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt
Und dann gibts da noch so ne große Suchmaschine, die einem helfen kann :-)
Google Suche nach "signalr python"

Ja es gibt nette Python Libs, keine Frage, die scheine aber zum Teil älter zu sein
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von TotalerASPNETN00B am .
private Nachricht | Beiträge des Benutzers
M.L.
myCSharp.de - Member



Dabei seit:
Beiträge: 271

beantworten | zitieren | melden

Zitat
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 ;-)
private Nachricht | Beiträge des Benutzers
TotalerASPNETN00B
myCSharp.de - Member



Dabei seit:
Beiträge: 9

Themenstarter:

beantworten | zitieren | melden

Zitat von M.L.
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
private Nachricht | Beiträge des Benutzers
Papst
myCSharp.de - Experte



Dabei seit:
Beiträge: 394
Herkunft: Kassel

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers