I have gotten a Web API service up and running and receiving/returning data to my Blazor application. But, what I would like to do is to receive real-time information back from the service so that I can display updates to the Blazor application on what stage the API call is in the process. I have done a little digging and I am confused if I should go with PushStreamContent, Duplex service, or a new SignalR connection back to the service call.
Any suggestions?
I think that this is the ultimate answer:
https://chrissainty.com/calling-grpc-services-with-server-side-blazor/
Related
I am developing a C# backend app using ASP.NET core web API application. Inside this API, I need to call some API(WCF SOAP service) from database. For this WCF service, we were provided pre-built .dll, so will not use adding service reference. When calling these WCF service, have to pass my windows credential to let WCF service know I am a qualified user before use the service. Now I am stuck on how I can pass my credential to this WCF. What is the right architecture to use.(Screen shot is showing some endpoint of the WCF service)
Adding some background info, In our react frontend, will call these ASP.NET core web API to get data back from WCF, and show it on frontend.
I am new to C# and .Net core. Please share some insight. Thanks a lot. Happy New Year!!!
I did the ASP.NET core web API part. but could not figure out the right way to authenticate when connecting to WCF API.
There is a ready azure microservices that I need to build a client app against. There are 2 choices blazor server side and client side. Because the client side is not ready yet and has limited debugging capabilities I want to use blazor server side.
My question is if calling services from blazor server side is possible and if it is a good idea. To use it as a client app?
And also if it is possible to host blazor next to the microservices in azure?
I believe what you are asking is if it's acceptable to use the Blazor server side as a proxy to a microservice?
Technically, there's no reason that you couldn't. You would simply create an HttpClient to call your Microservice assuming that it exposes a REST API.
I'm not sure what you mean by, "..if it is possible to host blazor next to microservices in azure?" If you're using an Azure Web App to host your microservice, you would probably want to create a new Web App for your blazor server side app, otherwise you aren't really getting the benefit from the app service.
There are other options for configuring this type of architecture, but it all depends on your goals. Additionally, you might want to check out the following project:
https://github.com/Suchiman/BlazorDualMode
It will let you run blazor client and server side together. I've used it to help debug client side blazor apps.
We are developing ASP.Net core that is hosted as Azure Web Application.
We also use Azure SignalR service
Everything works great as long as we have single instance of the Web App, but once we scale it out we have the following problem:
From the Controller's action we resolve IHubContext and we send message to Hub's client. Everything works great so far
Hub's client accepts response and sends it TheHub endpoint.
The problem here is that response could be sent to another instance of Web App. So we send request from instance #1 but response is sent to instance #2 with 50% chance and instance #1 never receives response
Any ideas of how we could make it work so instance that emitted request actually received response?
SignalR has support for scaleout scenarios out of the box, it's called backplanes. The idea is that with help of one of backplane components, it will spread out SignalR events accross all instances. For Asp.Net framework, use one of these packages
Microsoft.AspNet.SignalR.ServiceBus3
Microsoft.AspNet.SignalR.ServiceBus
Microsoft.AspNet.SignalR.StackExchangeRedis
Microsoft.AspNet.SignalR.SqlServer
For ASP.Net Core only Redis is ported with Microsoft.AspNetCore.SignalR.StackExchangeRedis package, but there are some provided by community, see https://github.com/thomaslevesque/AspNetCore.SignalR.AzureServiceBus
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR()
.AddAzureSignalR(options =>
{
options.ApplicationName = "app1";
}
);
}
You could specify an ApplicationName in the server SDK for different server groups.
It will help your server generate access tokens like ......?hub=app1_<your_hub> during negotiation which can help our ASRS instances differentiate connections coming from different server groups
Unfortunately I didn't find reliable solution that wouldn't require a bit clumsy workarounds
But there are 2 solutions I could offer for this scenario
#LexLi suggested a good approach to solve this problem. So you basically can make your web app a SignalR client as well and make it a member of a group. This way every instance of web app is also a client and then instance that receives response for Hub's client can pass this response to group of web app instances
You could leverage Azure Service Bus topics. So once started instance will start subscribe to listen a topic. And then once any instance receives a response from Hub's client it would place response into Service Bus Topic and then every instance will receive this response from the topic
I was hoping that there could be a better solution for such problem
I've followed the instructions from https://github.com/SignalR/SignalR/wiki/Hubs
entitled "Broadcasting over a Hub from outside of a Hub".
I got this method working from within an MVC Action in the same project. Requesting the Action sends the update to connected clients.
My problem is that I need to be able to send updates from another project, in particular a WCF Web Services project. My app has an API and a web component and when API users make calls that change things, these updates need to be pushed out to the Web clients via SignalR. And calling a web service with the same code as my Test Action doesn't work.
I also tried the same code inside an nunit unit test that didn't work either.
What do I need to do to make this same method described on the Wiki work for a WCF Project?
The easiest solution is probably to provide an API on your Web Application (use MVC or the new WebAPI) that broadcasts to all connected clients. Any other application (an NT Service, an NUnit test, ...) can call that API if it wants to send a message to the clients.
You can't expect SignalR to do anything if you aren't hosting a Hub either in a Web Application running under IIS, or another application hosting it directly.
If you need two-way communication from your separate application to your clients then simply make your application into a SignalR client too and have it communicate via the Web Application hosted SignalR to the clients and have it listen to messages from them too.
For example, here's how I have configured a complex Service + WebSite + Clients solution (ignore the purple for now):
The Live Web Server allows NT Services to connect and create SignalR Groups. NT Services send to those groups. Web browsers connect to a group and receive messages send to that group. In effect the middle box becomes a pubsubhub.
I cannot get exactly what you aim. But if I understood correctly you're trying to send some kind of notifications raised inside WCF services to SignalR clients.
If that's the case; I can suggest you my approach:
I have some WCF services and a SignalR hub in the same application server. IMHO, the best way to communicate WCF with SignalR hub is by using MSMQ.
When a notification occurs inside a WCF service, it puts the notification payload into MSMQ.
On the other end, SignalR hub listens the same queue. When a message put into the queue, it gets the content and broadcasts to the hub clients. Very easy and straightforward. No extra service/hub call at the server side.
SignalR hub can listen for new queue items by using System.Messaging.MessageQueue#ReceiveCompleted method. When this event raised, SignalR hub gets the queue item and broadcasts to its clients.
I am currently developing a WCF duplex Service for 2 clients. The first client would be an asp.net webpage which upon receiving a posting, it will send the data over to the service. When the service receives the data, it will then AUTOMATICALLY send it to the second client which is a winform app through the callback channel...
To make it simpler.
Asp.net will invoke the wcf
The wcf will reside on the iis server, same as the asp.net
WCF will require to send a data to the windows form application that is running on a client side. Only 1 instance of this application will be run at a time.
Your service should know nothing about the clients attached to it. Doing so pretty much breaks the intention of WCF.
A better solution might be to have your clients subscribe to "events" that your service can fire off. Or maybe the client can provide some information in their requests that indicates a service and method to call back to when needed.