For background process listening to a service bus topic, what would be the considerations for choosing between running a hosted service in ASP.NET core VS creating a worker service?
I'm seeing several options from the internet and I'm wondering which scenarios would make one go for each of these options:
Running API & Worker service separately
Running API with hosted service
Running worker service with API inside (not for us)
Our system will have an ASP.NET Core API as well, so I'm wondering whether to add a hosted service to this API or to separate the application as a worker service.
We also want to run this in container and deploy it in Azure container app (if that makes a difference to the considerations)
I saw someone mentioned if health check is needed for the background process then it's better to go with ASP.NET with hosted service implementation. But then I found this lib https://github.com/bruceharrison1984/TinyHealthCheck which seems to add health check functionality to worker service
The API and the worker should be separated. You can then scale the two separately. Especially if you plan to deploy the worker on Azure Container App, you can scale automatically the worker depending on the message number on the bus using KEDA. When no message is in the queue it will automatically scale down to 0 !
Your API in the other hand should be always up.
To create a worker you should consider using the generic host of .Net.
In my opinion, this is related with the relationship with the web api and the worker service.
If this worker service is just used for this asp.net core web api, I suggest you could choose 2 or 3.
If this work service is also used for other web api or else, I suggest you should run API & Worker service separately.
From the comments you have added I can see that the API and the worker service are separate and that you are deploying using docker. For those reasons I would suggest that you deploy these two things separately in their own containers. I would choose this because it makes each application simpler and easier to maintain. A good place to start is here Background tasks with hosted services in ASP.NET Core. There is a simple dotnet cli template to create the project
dotnet new worker -o [your project name]
Related
I have an ASP.net Core web API running the ASP.net Core Web Host.
In the ServiceCollection, I register a HostedService to run a worker that subscribes to a message bus.
Some messages come from web API. Some messages come from the message bus through the worker.
They all get written to a database.
Presently I'm having problems where when I write messages coming from the worker to the database I get System.ObjectDisposedException on my dependency injected data access Scoped service.
It feels like my worker is somehow using the HTTP request scopes for the DI injected services.
So, could this be caused by using a Hosted Service in the ASP.NET Core Web Host
Do not read messages in a ServiceHosted, you should read it seperately (maybe in a singleton scenario)
If you're reading messages from service-bus manually you should not have that problem otherwise you should not use scoped services for that. for example in RabbitMQ the best practice is to open a connection for each app
I am building a micro-service-oriented .NET Core web application and now I want to add real-time communication. It is possible to create a SignalR server and publish it on Azure? I want to use it in my microservices to send messages to users when a certain even occurs.
Yes, you can deploy your app to Azure and point your users to your hub endpoint with no problems. You have two options here:
Use SignalR and manually manage the connections and other signalR stuff if you will scale your application. For example, when you have 2 web apps and the client connects to one of them, you need to "tell" to other app that you have a new client connected using for example Redis Blackplane.
Use Azure SignalR and this kind of management is not needed, what you need to provide is only 1 app with the hub logic. So when a client connects to your hub it is automaticaly redirected to the Azure SignalR.
You can read more about this two options here:
https://learn.microsoft.com/pt-pt/azure/azure-signalr/signalr-concept-scale-aspnet-core
Why not deploy SignalR myself?´
It is still a valid approach to deploy your own Azure web app supporting ASP.NET Core SignalR as a backend component to your overall web application.
One of the key reasons to use the Azure SignalR Service is simplicity. With Azure SignalR Service, you don't need to handle problems like performance, scalability, availability. These issues are handled for you with a 99.9% service-level agreement.
Also, WebSockets are typically the preferred technique to support real-time content updates. However, load balancing a large number of persistent WebSocket connections becomes a complicated problem to solve as you scale. Common solutions leverage: DNS load balancing, hardware load balancers, and software load balancing. Azure SignalR Service handles this problem for you.
Another reason may be you have no requirements to actually host a web application at all. The logic of your web application may leverage Serverless computing. For example, maybe your code is only hosted and executed on demand with Azure Functions triggers. This scenario can be tricky because your code only runs on-demand and doesn't maintain long connections with clients. Azure SignalR Service can handle this situation since the service already manages connections for you. See the overview on how to use SignalR Service with Azure Functions for more details.
Yes you can, this is the official quick start sample.
https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-quickstart-dotnet-core
My organization is transitioning from MS WCF services to Web API services. One big difference I've noticed is in the startup behavior. If a WCF service isn't spun up, it waits to return until it is spun up. However, if a Web API service is not spun up, it returns 500s until it is spun up.
Is there any way to configure the Web API applications or IIS so that it starts up more like a WCF service, in that it doesn't return anything until it's spun up? I've googled extensively but have been unable to find anything addressing this.
As an FYI, app init isn't an option for us right now.
I believe this is configurable via IIS.
See here:
Auto-Start Feature
I was reading this article in looking for differences between creating an API using WebAPI and MVC and came across this statement:
In simple load testing on my local machine, I’ve found that Web API
endpoints hosted in console apps are nearly 50% faster than both
ASP.NET controller actions and Web API endpoints hosted within MVC
projects.
As such, I'm interested in how this would take shape in a production environment.
Obviously I'm looking for performance, so I looked into OWIN and self-hosting. However I'm not clear on if this offers the same efficiency as the console app discussed above.
Can someone please explain the proposal of hosting an API console application for consumption in a production environment - i.e. how would you connect a URL to the console app, etc.?
Thanks.
My understanding is self hosted OWIN apps can be run within any kind of app domain e.g console, windows forms, windows service, AWS EC2, Azure Worker Role etc. The application you should run it in is dependent upon the hosting environment you choose, there are lots of options.
Currently I maintain an application that runs as a Windows service, reads messages from a message queue server, processes them and puts the result back into the message queue server. But it also contains a health monitoring component that is accessible through a web API.
It is implemented as a console app that uses Katana to self-host the health monitoring sub-system.
I'm now trying to figure out if we can move this to .NET Core and ASP.NET Core once they RTM. I know the Windows Service part cannot be ported, but I could also run the console app as a detached Docker container to basically achieve the same thing, in terms of main functionality.
But how will the health monitoring work? From what I can see the Katana project has been updated to ASP.NET 5 (which I guess is ASP.NET Core 1 before the big rename), but it does not run on the .NET Core CLR. Katana will require the full CLR. So that means Katana is out.
Does this mean that the way we build our app is impossible with .NET Core? Or does hosting the app through Kestrel not rule out the possibility of running code before the first request? With IIS the app does not live until the first request (unless you use the auto-start, but it's more of a speed-optimisation than have the app behave like an "allways-running-app") and generally the app is request-based and not continually running. Background threads in a IIS hosted app are a really bad idea.
Is this the same with Kestrel? Or will DNX start your app and keep it running until it's shutdown, much like a console app, so we can run all the background threads we want?
It follows the console app model. Katana is actually more the spiritual predecessor to kestrel. It is invoked for normal ASP.NET Core projects from the Main method with a normal method call. There are countless tutorials how to setup a server in RC1 (see Startup.cs Main method) and some for the upcoming RC2 (there is a builder for it). That would allow you to do both, your app code and your web api based monitoring, in a console app. Kestrel and DNX are not at all an application server like IIS. Kestrel is a plain HTTP server library and nothing more. You start it up and it listens from that moment on.
Nevertheless, you have to adjust your WebApi 2 and Katana based application to the new ASP.NET Core interfaces and middleware concept. But that should be easy compared to your message queuing adaption.