Laden...

.NET Core Anwendung mit ASP.NET Core API

Erstellt von cRUSHERHLG vor 4 Jahren Letzter Beitrag vor 4 Jahren 3.629 Views
C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren
.NET Core Anwendung mit ASP.NET Core API

Hallo liebe mycsharp-community,

Aktuelle Situation:
Ich bin aktuell dabei eine Anwendung zu entwickeln auf Basis von .NET CORE welches später als Microservice auf einem Docker Container laufen soll. Das Programm soll nur für die Ausführung von Operationen dienen, die durch die Web API mit ASP.NET CORE an die .NET CORE Anwendung weitergeleitet werden.
Bei ASP.NET CORE die API mit dem Entity Framework ist ja eher für Datenbank Operationen gedacht und nicht als Middleware um Anfragen an das Programm richtig weiterzuleiten.
Dann stellt sich auch noch die Frage wie verbinde ich die ASP.NET CORE API mit der .NET CORE Anwendung das die Anfragen auch dort ankommen wo sie ankommen sollen.

Ich habe aktuell keine vergleichbare Zusammensetzung gefunden bis jetzt und möchte da nachfragen ob ihr mir hierzu vielleicht Ressourcen zeigen könnt oder wie ihr so eine Architektur aufbauen würdet.

Mit freundlichen Grüßen,
Andi Näther

16.807 Beiträge seit 2008
vor 4 Jahren

Das Programm soll nur für die Ausführung von Operationen dienen, die durch die Web API mit ASP.NET CORE an die .NET CORE Anwendung weitergeleitet werden.

Also Remote Calls via Json API? JsonRPC?

Bei ASP.NET CORE die API mit dem Entity Framework ist ja eher für Datenbank Operationen gedacht und nicht als Middleware um Anfragen an das Programm richtig weiterzuleiten.

EF ist ein "Datenbank Provider/Treiber" - keine Middleware.

Dann stellt sich auch noch die Frage wie verbinde ich die ASP.NET CORE API mit der .NET CORE Anwendung das die Anfragen auch dort ankommen wo sie ankommen sollen.

Wat? Nix verstehen.

Ich habe aktuell keine vergleichbare Zusammensetzung gefunden bis jetzt und möchte da nachfragen ob ihr mir hierzu vielleicht Ressourcen zeigen könnt oder wie ihr so eine Architektur aufbauen würdet.

Erklär bitte nochmal verständlich, was Du genau tun willst - wie sieht ein Request aus?

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Meine Intention ist es, dass eine .NET CORE Anwendung etwas verarbeitet. Die ASP.NET CORE API soll diese Daten an die Anwendung "transportieren". Ich habe es jetzt einfach mal anhand von schritten gezeigt.

Schritte:

  1. ASP.NET CORE API: Erhält Request mit Daten.
  2. .NET CORE: Anwendung erhält Request der API.
  3. .NET CORE: Verarbeitet den Request mit der entsprechenden Methode.
  4. .NET CORE: Sendet die Daten an die API zurück.
  5. ASP.NET CORE API: Sendet das Ergebniss an den Client.

Ich bin aktuell noch am überlegen wie ich das am besten aufbaue. Darum frage ich euch wie ihr sowas lösen würdet oder habt.

T
2.219 Beiträge seit 2008
vor 4 Jahren

Ohne sicher zu sein klingt es so als wolle er von Anwendung A über die Web API mit Anwendung B kommunizieren wollen.
Wird ohne weiteres nicht funktionieren, da eine Web Anwendung nicht als zentralle Kommunikationsstelle zwischen Anwendungen in dieser Form gedacht ist.

Wenn es "nur" dem einfachen Datenaustausch dient, wäre dies nur ein kleines Problem.
Hier muss nur Anwendung A dem Web mitteilen, dass die gesendeten Daten zu Anwendung B gesendet werden sollen.
Dann muss das Web die Daten entweder vorhalten bis Anwendung B seine Daten abfragt oder du setzt hier z.B. auf einen Push Service der die Daten aktiv an Anwendung B schicken kann.

Ich würde mir überlegen ob es nicht sinnvoller wäre dies mit einem MQTT Broker umzusetzen.
Im .NET Bereicht hatte ich letztens z.B. mit MQTTnet gearbeitet um eine ähnliche Lösung umzusetzen.
Hier würden die Clients dann in ihren Topics über neue Daten informiert, die sie dann abholen konnten.
In diesem Fall könnte man einen MQTT Broker dann zum verteilen der Daten zwischen den Anwendungen verwenden.
Dafür müssten beide nur entsprechende Topics anlegen und auf ihren Topic auf Daten warten.

Nachtrag:
Kommentar oben war vor dem Post des OP.

@cRUSHERHLG
Hier würde sich MQTT besser anbieten als eine API mit ASP .NET Core.
Bei dem Ansatz per API müsste sich jede Anwendung erst einmal anmelden und du müsstest zusätzlichen Verwaltungsaufwand betreiben um die Daten an die richtigen Clients zu verteilen.
Dies nimmt dir MQTT ab.

Mit MQTTnet könntest du auch den Server selbst bauen und die Anfragen sowie die Clients auf Zugriffserlaubnis prüfen.
Habe ich bei meinem Projekt auch gemacht um unerlaubte Zugriffe zu blocken.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 4 Jahren

Deiner Schrittfolge entnehme ich, dass wir von einer synchronen Kommunikation sprechen - also der Client auf die Antwort der API wartet.
Deinem Text entnehme ich aber, dass wir von längeren Executions sprechen - das beisst sich.

Im Prinzip basierend jede Microservice Architektur auf Deiner "Basiskonstellation":

  • Public APIs zum Annehmen von Informationen
  • Micro Service, die die Operationen durchführen und von außen direkt nicht erreichbar sind.

Mit dem Wissenstand, den Du uns gibst, erkenne ich aber nicht, was Du wirklich hast oder haben willst.
Es ist nicht klar, was ausgeführt wird, warum eine Weiterleitung notwendig ist, ob synchron sinnvoll ist.

Als Grundgerüst kann ich Dich an Micro Services verweisen, weil sie diese Basis Solution Architektur von Public und Execution erfüllen.
Aber das ist halt nur eine Richtung.

Ich würde mir überlegen ob es nicht sinnvoller wäre dies mit einem MQTT Broker umzusetzen.

Auch wenn es gerne missbraucht wird: MQTT ist und bleibt ein Telemetrie-Protokoll und ist nicht für Anwendungskommunikation konzipiert.
Dafür gibt es AMQP, das auch Routing unterstützt.

Aber ja - insgesamt hört sich das nach einem Wunsch nach Event Sourcing an.

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Abt
Ich lese es eher so, dass die API nur der Übertragungskanal zwischen den Client ist.
Die eigentliche Verarbeitung findet wohl in der Anwendung statt, also nicht in der Web API.
Deshalb würde ich die API eher außen vorlassen und z.BN. über MQTT wenn möglich die DAten transferieren.

Nachtrag:
Kannte AMQP noch gar nicht.
Werde ich mir bei Zeiten mal anschauen.
Dürfte hier wirklich die bessere Wahl sein.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 4 Jahren

Deshalb würde ich die API eher außen vorlassen und z.BN. über MQTT wenn möglich die DAten transferieren.

Den Rat kann man aber seriös überhaupt nicht geben.
Du kennst die Rahmenparameter nicht; weißt also gar nicht, ob MQTT überhaupt in die Tüte passt (davon abgesehen: wie gesagt ein Telemetrieprotokoll).

Weiterhin: Broker niemans öffentlich anbieten - nicht MQTT und auch nicht AMQP.

Es ist absolut üblich, dass eine API (HTTP, Json, gRPC..) eine Anfrage entgegen nimmt, diese in eine Message packt über einen Broker weiter reicht und dem Anfragenden mit HTTP 201 antwortet.
Darauf basieren viele Cloud-basierte APIs.

Eine Antwort bekommt der Client dann aber über einen zweiten Kanal - nicht direkt über den Request (asynchrone Kommunikation alá CQRS).

Natürlich kann die Kommunikation zwischen API und der ausführenden Anwendung dann aber ein Message Broker sein; aber niemals die API durch einen Broker ersetzen.
Du setzt ja auch keine Datenbank direkt in das Internet - sondern setzt ne Server Side API davor, mit dem die Client kommunizieren.

Einen Broker nutzt Du nur direkt, wenn Du der Herrscher über alle Kommunikationspartner bist und auch selbst die AuthN und AuthZ garantieren kannst.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Die Antwort von T-Virus geht schon eher in meine Richtung. Ich werde mit MQTT anschauen, habe bis jetzt noch nix davon gehört. Kennst du vielleicht noch gute Ressources die du so weiter empfehlen würdest 😄?

16.807 Beiträge seit 2008
vor 4 Jahren

Ich werde mit MQTT anschauen,

ActiveMQ Artemis - verweise aber erneut auf AMQP (für .NET Standard AmqpNetLite).

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Auf den ersten Blick sind MQTT und ActiveMQ relativ gleich.
Damit soll man API aufbauen können bzw. einen Server der die Anfragen annimmt und an die Anwendung mittels des Clients weiterleitet. Wenn man den Ansatz geht, warum nutzt man dann nicht direkt beispielweise Sockets direkt?

16.807 Beiträge seit 2008
vor 4 Jahren

Auf den ersten Blick sind MQTT und ActiveMQ relativ gleich.

Das ist wie wenn man sagen würde, dass XML und JSON eigentlich gleich sind 😃
Daher: schau bitte nochmal ein zweites Mal hin 😃

Wenn man den Ansatz geht, warum nutzt man dann nicht direkt beispielweise Sockets direkt?

Weil Dir Protokolle Dinge abnehmen:

  • Security
  • Standards
  • Skalierung
  • Ausfallsicherheit
  • Connectivity Management
  • Typisierung
  • Cross-Technology
  • Cross-Platform

.. um nur wenige Gründe zu nennen.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Also hätte ich dann im Grunde eine Client/Server Architektur.
Für meinen Fall, welches der Beiden "Dienste" sollte ich eher nutzen?

@Abt kannst du mir bitte eine Struktur vorschlagen wie du sowas lösen würdest?

16.807 Beiträge seit 2008
vor 4 Jahren

Also hätte ich dann im Grunde eine Client/Server Architektur.

Redest Du von Client zu API: Ja
API zu Handler App: Nein.

Siehe auch:

insgesamt hört sich das nach einem Wunsch nach Event Sourcing an.

An dieser Stelle hättest Du nun Event Sourcing googlen können, was Dir sehr schnell zeigt, dass das mit klassicher Client/Server wenig zutun hat (wobei Dich mehr der Event-Teil als der Store-Teil interessiert).
Vereinfacht zeigt das auch der Publish-Subscribe Pattern, der für Dich nach dem aktuellen Stand der Infos hier Dir wohl völlig ausreicht.

Für meinen Fall, welches der Beiden "Dienste" sollte ich eher nutzen?

Dienste? Wir haben hier bisher nicht über Dienste gesprochen.

@Abt kannst du mir bitte eine Struktur vorschlagen wie du sowas lösen würdest?

Von was von einer Struktur sprichst Du? Code? Solution? Communication?
Du kannst Dich aber natürlich auch selbst in solche Architekturbasics einarbeiten und selbst mal starten, eine Struktur zu evaluieren....

Mit dem aktuellen Infostand bleibe ich aber weiterhin dabei, dass ich den Hinweis auf MQTT bzw. Broker Allgemein völlig mit Kanonen auf Spatzen geschossen empfinde.
Message Broker erzeugen einen organisatorischen und technischen Aufwand, der hier sehr wahrscheinlich - so wie es sich für mich anhört - völligst übertrieben ist.

Keep it simple.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Ich versuche es anders zu erklären als davor.
Ich möchte einen Service erstellen der Anfragen von einem Client annimmt und diese dann verarbeitet. Dabei soll er das auch wieder zurück an den Client senden. Dieser Service soll als eigenständiger Service auf Docker laufen können.

Am besten wäre es wenn man es unter Docker deployen könnte, sodass man durch docker swarm dann dafür auch eine dementsprechende Lastenverteilung hat bei den Anfragen der Clienten.

So wie ich es jetzt geschrieben habe, ist es sehr offen geschrieben. Aus der Erklärung ganz oben meine ich wie man so einen "Service" an besten aufbaut.

Ich hoffe mal ich habe es nun vereinfachter dargestellt was ich ganz einfach gesagt meine.

16.807 Beiträge seit 2008
vor 4 Jahren

Ob Docker oder nicht spielt in dem Szenario ja weniger eine Rolle.
Spielt in diesem Szenario ja weniger eine Rolle wie man orchestriert.

Ich sehe in Deiner Erklärung nun weiterhin keine Notwendigkeit für die Komplexität einer zusätzlichen Applikation.

Wieso lässt Du die API nicht direkt die Operation durchführen?
Das erspart Dir die App-to-App Communication.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Du meinst jetzt aus der bestehenden .NET CORE Anwendung eine ASP.NET CORE API erstellen, die diese Funktionen beinhaltet?

16.807 Beiträge seit 2008
vor 4 Jahren

Wenn Du Dich an [Artikel] Drei-Schichten-Architektur hälst, dann ist es egal ob die Logik aus einer Konsolenanwendung oder eine Webanwendung angesprochen wird....

Wenn Du hier grundlegend was umbauen musst, dann haste eh schon was gegen die Wand gesemmelt.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Das ist damit garnicht gemeint. Die aktuelle Architektur lässt es zu. Ich meinte nur das man dennoch ein paar sachen für ASP.NET CORE dann abändern muss aber nicht bezogen auf die Architektur.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Die Frage wäre dann aber ob es sich dann immer noch um einen Mikroservice handelt, wenn man die API/Verarbeitung und noch Datenbank abfragen in ein Programm zusammen packt.

16.807 Beiträge seit 2008
vor 4 Jahren

Martin Fowler - Microservices - a definition of this new architectural term

Die Frage ist auch, ob Du viel zu komplex denkst / vorgehst für ein total simples Problem...
Aber dazu musst Du Dich mit Architekturpattern beschäftigen. Keiner hier kennt Deine genauen Anfordungen.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Naja gut mit dem Punkt zu kompliziert denken, dass ist bei mir ein generelles Problem.
Ich möchte an sich nur eine Webseite programmieren.
Über eine Schnittstelle soll die Funktion die von der Webseite aufgerufen wurde dann ausgeführt werden und dem Client das Ergebnis zurück geliefert werden.

Dabei wäre es halt schon gut wenn man die von dir genannten Funktionen mittels ActiveMQ nutzt um diese Schnittstelle abzusichern und für dritte nicht authorisierte zu sichern.

2.207 Beiträge seit 2011
vor 4 Jahren

Hallo cRUSHERHLG,

willst du nicht erstmal eine ganz normale WebAPI (oder MVC) mit ASP.NET Core machen, die genau das macht, und dann absichern etc.?

Gruss

Coffeebean

16.807 Beiträge seit 2008
vor 4 Jahren

Sehe weiterhin keine Notwendigkeit eines Brokers. 🤔
Aber ich klinke mich ma an der Stelle aus - Du musst erst mal ordentlich evaluieren und Dich mit den Konzepten beschäftigen, die man Dir mittlerweile alle gegeben hat.

Dieses Rumstochern und planlos in irgendeine Richtung laufen hat in der Entwicklung noch nie was gebracht.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Das mit dem stochern alles schön und gut. Ich frage euch wie ihr sowas handhaben würdet und liefere euch die Infos zu denn genannten Punkten die für euch unschlüssig sind. Was wäre denn nun die sauberste Lösung aktuell in an betracht, der Wartbarkeit/Erweiterbarkeit.

16.807 Beiträge seit 2008
vor 4 Jahren

Naja, man hat dich jetzt gefühlt 200 mal auf Ressourcen und Lernstoff verwiesen und Du willst hier offensichtlich nicht selbst agieren.
Und ich will nicht Deine Software schreiben - und auch nicht, dass das hier nen Endlosthread wird.
Das ist nicht das Ziel eines Forums.

Wenn Du eine persönliche Betreuung willst, die Dich beim Projekt begleitet, dann musst Du das sagen.
Das Forum kann und wird Dir das aber nicht bieten.

Was wäre denn nun die sauberste Lösung aktuell in an betracht, der Wartbarkeit/Erweiterbarkeit.

Dir sollte bewusst sein, dass es nicht nur einen Weg nach Rom gibt - und wir weiterhin Deine Umgebung und Rahmenparameter nicht kennen.
Die Frage ist nicht absolut beantwortbar.

Aber Du bekommst das schon hin. Viel Erfolg!

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Ich weiß nicht was du verstehen möchtest. Ich will nicht das jemand von euch das Programmiert oder sonst was. Ich möchte nur wissen welcher der beste Ansatz ist auf lange Sicht denn man nutzen sollte. Nicht mehr und nicht weniger.

16.807 Beiträge seit 2008
vor 4 Jahren

Ich möchte nur wissen welcher der beste Ansatz ist auf lange Sicht denn man nutzen sollte.

Wenn Dir das jemand in der Form beantworten kann, dann muss er eine Glaskugel haben.

C
cRUSHERHLG Themenstarter:in
31 Beiträge seit 2018
vor 4 Jahren

Dann Frage ich dich halt nochmal 😄. Welche konkreten Informationen benötigst du damit du eine Aussage treffen kannst?