WebAPI stability
I've got a few websites in classic ASP, and a bunch I did in webforms/vb.net. I decided it was time for me to try MVC and figured I should go ahead and learn C# at the same time.
Unfortunately, these aren't small systems that can be easily moved to new platforms. Some of them have hundreds of pages and a few hours outage could cost millions of dollars.
I finally decided that the ideal move was to go from classic ASP to WebApi, using CORS, so I could put the API server on a nice clean server and simply add javascript to the bottom of each page, filling in the same boxes that classic ASP used to fill in.
It has been EXCELLENT. I had all the ASP code separated with values passed down to the primary page. However, I have some questions about stability.
WebApi appears to be all one "program". I've already had several times where something worked on my dev box, then when I published it, everything went to crap. (dependancies, etc...)
When I started my testing with the API model, it was before WebApi even existed. I was using generic handlers (ashx) to produce Json for my ajax calls.
What I like about the handler thing is that, if you have 100 pages, and you put in a dumb fix on some little sub-page, publish it, then nobody is really effected except people who are trying to load that page. Even better, the result, if you're using ajax, is that it won't populate the page. No evil bad error.
I'd like to know if perhaps I'm doing something wrong with my WebApi. If I publish a controller with a bug, will the entire site crap out? These are internal ERP systems, so if the part where the warehouse picks products goes down, I have hundreds of people just standing around. Obviously, that will have to be tested and QA'd carefully. I've got other parts where the CIO does analysis on sales of certain products, sometimes calling for modifications in real time. Sometimes the page is jacked up or whatever, he doesn't care and it doesn't affect business.
So, if a failure in a controller to compile is going to blow the entire site, I'm going to have to make a couple CORS data servers on the same box. Maybe one for each module. --yuck.
OR
Do the entire thing in Generic Handlers.... which would be easy, but ... yuck.
OR
Is there a way that the WebAPI controllers can be run somewhat independantly?
OR
Am I just a complete Nubie (which I am) and somehow I've configured this new toy incorrectly and it will be perfectly find to have a bug in one controller while the others run along perfectly
I hope it's the latter, but if not, I'd love some recommendations!
Unfortunately, these aren't small systems that can be easily moved to new platforms. Some of them have hundreds of pages and a few hours outage could cost millions of dollars.
I finally decided that the ideal move was to go from classic ASP to WebApi, using CORS, so I could put the API server on a nice clean server and simply add javascript to the bottom of each page, filling in the same boxes that classic ASP used to fill in.
It has been EXCELLENT. I had all the ASP code separated with values passed down to the primary page. However, I have some questions about stability.
WebApi appears to be all one "program". I've already had several times where something worked on my dev box, then when I published it, everything went to crap. (dependancies, etc...)
When I started my testing with the API model, it was before WebApi even existed. I was using generic handlers (ashx) to produce Json for my ajax calls.
What I like about the handler thing is that, if you have 100 pages, and you put in a dumb fix on some little sub-page, publish it, then nobody is really effected except people who are trying to load that page. Even better, the result, if you're using ajax, is that it won't populate the page. No evil bad error.
I'd like to know if perhaps I'm doing something wrong with my WebApi. If I publish a controller with a bug, will the entire site crap out? These are internal ERP systems, so if the part where the warehouse picks products goes down, I have hundreds of people just standing around. Obviously, that will have to be tested and QA'd carefully. I've got other parts where the CIO does analysis on sales of certain products, sometimes calling for modifications in real time. Sometimes the page is jacked up or whatever, he doesn't care and it doesn't affect business.
So, if a failure in a controller to compile is going to blow the entire site, I'm going to have to make a couple CORS data servers on the same box. Maybe one for each module. --yuck.
OR
Do the entire thing in Generic Handlers.... which would be easy, but ... yuck.
OR
Is there a way that the WebAPI controllers can be run somewhat independantly?
OR
Am I just a complete Nubie (which I am) and somehow I've configured this new toy incorrectly and it will be perfectly find to have a bug in one controller while the others run along perfectly
I hope it's the latter, but if not, I'd love some recommendations!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
CraigWagner, Unfortunately, I've been having problems with compiled sites working fine on the dev server and then crashing after publishing to production.
David Johnson, that's probably like having a slew of generic handlers or even individual webservices. It seems unweildy, but (I believe) is probably the most stable way to go.
apeter, you think I should break the site into several distinct sub-sites. At first glance, I believe this is going to be the best solution. However, I've got a bunch of libraries that contain a lot of similar code. I'm going to have to find a way to share those libraries efficiently. Maybe a nuget package....
So.... I'm still not certain.
David Johnson, that's probably like having a slew of generic handlers or even individual webservices. It seems unweildy, but (I believe) is probably the most stable way to go.
apeter, you think I should break the site into several distinct sub-sites. At first glance, I believe this is going to be the best solution. However, I've got a bunch of libraries that contain a lot of similar code. I'm going to have to find a way to share those libraries efficiently. Maybe a nuget package....
So.... I'm still not certain.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
What I ended up doing is exactly what Craig recommended, putting together a nuget package for shared code.
I'm going to split it into several projects, but that's important for business purposes as well. I sell a lot of software, and some of the modules are necessary in all of them. Having a base Nuget + Module Class Library will make the most of shared code while enabling us to put together products for sale quite easily. (We actually already do that with our webforms projects)
Everyone here was a lot of help here and I appreciate the advice.
Thanks.
Dan
I'm going to split it into several projects, but that's important for business purposes as well. I sell a lot of software, and some of the modules are necessary in all of them. Having a base Nuget + Module Class Library will make the most of shared code while enabling us to put together products for sale quite easily. (We actually already do that with our webforms projects)
Everyone here was a lot of help here and I appreciate the advice.
Thanks.
Dan
In this scenario, if an error occurs (or an exception is thrown) it does not bring down the whole site, only that request (which ultimately will return an HTTP 500 to the caller).