I have a confusion over differences between using app service alone and app service with web jobs.
I have a computation intense task (2-20 min) that must be triggered manually (user asks for it from time to time). Right now everything happens in one app service. I'm thinking to extract this heavy process to a webjob in another app service. This new app service will be empty (no api served) but host this web job, which I'll trigger from first app service.
I'm bothered that second app service will be empty. Can I use second app service to do the work without using webjobs (just WebApi project)? Or I should stick to webjobs? What would be pros and cons of these two approaches?
In my opinion, we shouldn't compare the web api and web jobs. Because this two things is used for different environment.
The webjobs feature:
Web Jobs can be configured to be manually triggered or run on a schedule.
Web Jobs can be configured to be Continuously running (aka running constantly, all the time)
Azure Web Jobs can be implemented to fill any background processing need.
So if you want to work with background processing and don't want to return the response to any other application. I suggest you could choose webjobs.
The web api is easy to build HTTP services for the customer to get the response.
So this is used to interact with others. So If you want to get the result and used in any other place. You could choose web api.
The web api feature:
All in all, if the computation will not interact with others(return the result to customer), I suggest you could choose web jobs.