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.
Do the entire thing in Generic Handlers.... which would be easy, but ... yuck.

Is there a way that the WebAPI controllers can be run somewhat independantly?
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!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
you should have several services where each service does one thing and one thing well.  Putting all of your apples in one barrel is a recipe for disaster. Always keep your business logic and your presentation layer separate.  Some places use graphic designers for the presentation layer
Aaron JabamaniTechnical ArchitectCommented:
Compile time error in one controller will stop your entire site. But Logic error in controller will NOT stop other controllers.
Maybe broadly classify your services(APIs) and place in the separate projects. Deploying in the same server with different sites. Since CORS is there, you can access all of them. This way you can isolate a API from others.
Craig WagnerSoftware ArchitectCommented:
I have to admit I don't really understand your questions. The code is compiled (hopefully on a dedicated build machine, but worst case on your dev box) and then assemblies are deployed. Nothing is compiled in production, in production you are running already-compiled assemblies (or at least you should be).

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).
Exploring SQL Server 2016: Fundamentals

Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.

DanielcmorrisAuthor Commented:
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.
Craig WagnerSoftware ArchitectCommented:
First, I completely disagree that breaking things up is the most stable way to go. I've developed large public-facing web sites that include WebAPI elements that are 99.9% up-time. Something is either wrong with your code, build process, or production environment (probably configuration) if you're crashing a lot in production. Unfortunately you haven't given any information to go on for making suggestions as what you might look for.

If you insist in breaking your application up into multiple projects, put the shared code in a class library project, add it to the solution, and reference that project from each of your other projects. You could go the NuGet route if you have a large team and want to control who and when changes are made to that shared library. If that's no the case, just go with a new project in the solution.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DanielcmorrisAuthor Commented:
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.  


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.