I currently have a WCF service that the website uses to display data. I also use the same service to run a computation that takes about 8-9 hours and it saves the data it computed into the database during the time (the process/server stays alive). The WCF is only used by the website.
Should I switch to ASP.NET Web API? Can Web API run computation for like 8-9 hours and stay alive like the WCF? Basically I can call the web address and it initiates the computation and I also use different web address to get the data for the clients.
Should I even consider Web API?
Related
Sitting in front of the task to create a new small service, I am wondering if there is some best practice guidelines to ensure a fast response time (including the first 1-3 requests) for that service.
First of all I love to create services with .NET Core and the webapi template (.NET Core 6). But having created some of them I notices the delay for the initial request for the service is very slow and all subsequent request on other endpoints are slow as well.
I was wondering if there is something I can do to prevent this, is there some advice to achieve this without sending requests to all endpoints on service start?
The service is not running on AWS or another lambda service like host. The .NET Core services "feel" slow if you compare to fast starting other services written in e.g. Node. I know the real performance(latency, throughput, ...) is another beast and I am very satisfied with that.
I found the following articles but was not satisfied with the result and/or conclusion.
https://andrewlock.net/reducing-latency-by-pre-building-singletons-in-asp-net-core/
https://blog.markvincze.com/running-asp-net-core-in-auto-scaling-containers-warm-up/
Is there a better way to "warm" the service or reduce the impact of the initial request?
Introduction
We are in the beggining of the development of a new web client for our current web application.
And we will take the chance to build a REST WebApi to access our assets (to be consumed by third parties, and also our new web client)
We're considering OAuth, Service Quotes, Application permisions, etc for the WebAPI
We want to "eat our own dogfood", so the new webclient must use the webapi...
Important: The webApi and the webClient will be hosted in the same server
Questions
A simple use case would be "Get the menu page links"
For the web client which of these 2 approach would you choose?
a) Generate an html with a Js webApiCall inside it to be called from client web browser to get the available menu links for the user. = (2 round trips: 1 for the html/aspx + 1 for the api call MenuGetAvailableItems)
b) Generate an html with the data menu links already populated (webApi MenuGetAvailableItems consumed internally in server side) = (1 round trip for html/aspx + an API internal call..)
If you choose option 1B, Is it possible to avoid the http overhead by consuming the api from the same server and mantain the security, Quotes, etc? I mean, can we use some WCF mechanism or other to communicate this 2 webs instead of making an http call to localhost...?
Thanks for your comments
Q 1
regarding option a - I would avoid calling Web API from the web page, you will start to run into problems with CORS. Also, what if you want to use authentication to access the Web API service, how are you going to send a user name and password from the web page!
regarding option b - you certainly can consume the web api service from inside your web app.
Q 2
I don't understand your what you are asking.
If your primary purpose for building a web service is to allow a third party to interact with you, you are going to want build just the services that need to be exposed.
In general, "eating your own dogfood" might not be the best reason to use Web API where standard calls to the database would be more appropriate. You going to have two applications running, when all you really needed was a data tier in the web app.
It sounds like you are going to end up with a sprawling Web API app that will need new services every time you want to add something to your site.
Is it possible to create a website (hosted locally on my machine is fine for now) using a WCF Service Application?
By "web site" I mean allow an HTTP call from a web browser to my service and have the service return an HTML page that the browser can then render/display.
I am doing something very similar using a WCF based REST service. I have a WCF service that is accessed only from a web browser to download images. If you browse to 'http://www.MyFooImageService.com/100', it will lookup from the database an image with ID 100 and serve it up to the user. I use it to serve images from WCF service for the purpose of sending (user defined) emails with embedded images.
I used this guide with great results: RESTFUL WCF Service Step-ByStep. Check it out and see if a REST based WCF service is what you are looking for.
No, it doesn't quite work like that. WCF applications are service applications. There is no GUI interface or web interface or any kind of interface at all.
What you do is you create a WCF service that does some sort of function. Lets say you create a method called StoreName that stores your name into a database. Keep it simple. WCF services can be hosted in a variety of ways, depending on how you plan to use it. But to keep it simple, lets say you host the application using IIS.
Now this WCF application has no interface for interacting with it. You need to create an ASP.NET application (or it can be PHP, or jQuery if you prefer). It might have a text box and a submit button. Once the submit button is pushed, the ASP.NET application (or jQuery or PHP) makes an ajax call to your WCF service, passing it in the name as a POST parameter. The WCF service then does the work of storing it in the database. Execution then returns back to your web application.
This is a general overview of how this works. I hope it helps!
A website involves:
1) A user requesting HTML from somewhere
You can proxy pass a simple HTTP Get request to a WCF service hosted in a console app (or hosted in IIS), and configure it to return an HTTP request of content type text/html. Then the user would see a website appear in the browser.
But WCF is not a good fit for this. Especially if it's a simple HTML page. Others have said ASP.NET is better for this. And that's true. But node.js or PHP or pretty much anything that isn't .NET is MUCH better for this.
2) A user uses the web page to interact with server processes
This involves a user clicking a button or moving a mouse, or anything, and then that results in the web page (actually a web app at this point) making AJAX requests to one, or several server(s).
WCF is quite a good fit for this.
I have read Why not publish NServiceBus messages from a web application and another similar question about this but I am not clear if this applies to service layer as well. For example, if the service layer is composed of web services or REST services built using WCF or Web API or any other way, should those services publish events or send commands? If those services are hosted in load balanced web servers, the problems outlined in the articles apply to this layer as well. How would the recommendation change or not change?
If I look from the definition of Event vs Command, the messages I am talking about are Events e.g. "a user was created" and so an event should be published. As a matter of fact, the service that created the user doesn't even know what else to do i.e. may be another application is supposed to create a customized portal for it and yet another application is supposed to send a welcome kit to the user. This would be an event and not a command. I guess I am hung up on the definition of a web application and application service when application service itself is composed of one or many web applications.
The definition of Web Application
A web application is an application that is accessed by users over a
network such as the Internet or an intranet.
However, to me, the users can be computers and thus web services are web applications and that is the reason for this question.
EDIT:
Let's consider a concrete example. An ASP.NET website (MVC or Web form - doesn't matter) displays the form to the operator, gets a post with data about user creation (Name, UserName, Password) and invokes a WCF service to create the user. In between website and WCF service we can put ServiceBus and send command to create the user (Request/Response) so that we get all the benefits described in the first article. WCF service is the actual business processing layer i.e. it would create the user. That is where I have the question. After the user is created, it should announce that a user has been created and other systems can react to it and do whatever they are supposed to do. So it fits perfectly the pattern of publish the message. However, the WCF service itself is a web application and thus has most of the traits of the web applications and thus the confusion.
As mentioned in the answer to the SO question you linked to, publishing event has more to do with where the actual processing takes places. Just as a side-note: it is not a matter of Send instead of Publish since that would imply that the two are interchangeable whereas they have rather different intentions. When you want to publish, you want to publish.
The same questions should arise if you find yourself publishing from your web-exposed integration layer: should you be performing the business processing in that code or rather sending it off to another endpoint for processing? Typically you should just send it off to another endpoint. You may even consider how you would perform the relevant action should anyone wish to invoke it. For instance, if you are publishing a UserCreatedEvent message it implies that you created a user. How would a user be created? Would I be forced to use the WCF / Web-Api layer or can I send a CreateUserCommand message on the bus that is processed by some application endpoint? If it is the former then you may need to rethink your design. However, if the latter you should be sending the command from your WCF / Web-Api anyway and the processing endpoint will perform the Publish bit :)
update:
My take on it is that it is more about cohesion / concerns. You would typically interact with your domain, from within your business, via a service bus for commands and events, and a simple query layer for reads. If you need to expose anything to a third-party (or simply via the web) then you use WCF / WS / Web-APi. The point is that you should try to avoid business processing in an integration endpoint (or in a front-end like a website). Business processing is better suited to application servers. There are usually exceptions to the rule but if you are in a position to influence the structure then you are in a better space.
The fact is, whatever code is truly responsible for performing the action should be the same which publishes the event. If you've got a MVC app and in the controller itself you're using Entity Framework to insert the User record, then that is exactly where the Publish should be, right after the SaveChanges call. If however, the controller calls a referenced binary or service which does the actions involved in the "add user" call, then the Publish should be there. My thought is the event should be right alongside the code that does the action whose event you are trying to publish.
I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.