Are two .net web applications necessary?

Question

We have one single internal website.
Underneath this website (in IIS) we have two web applications:

1-Main web application
2-Web services (created using the visual studio web api project template)

The webservices are called by the pages in the main application.
They are also called by our database in some SQL CLR functions.
They are not called by any other applications.

A - Can these two web applications be merged into one?
Meaning merged into one web application project in Visual Studio.

B - If they can be merged into one, should they be?
Arguments for no they should not be merged:
1- for the day we create another application that consumes the services
2- security

Thanks

Answer 1

Just two? These days, microservices are "in," and it is not uncommon for a solution to be made up of not 2 or 3 but sometimes dozens of separate services. I'm working on a solution that has around 45 at the moment.

Separating the services in this manner allows several advantages: You can version and deploy each one, for example, so the test and release cycle for a small change can be much shorter, and the deployments are much less risky.

You also get more flexible scaling options; for example, if one particular service gets a lot of traffic you can spin that specific service up on more nodes (by adding machines to your load-balanced web farm, or by spinning up a higher capacity Cloud configuration).

If it were me, I would have absolutely no problem separating the web services from the web site, as you have in your question. That way, for example, changing the format of a page won't require you to regression test your services too, since they are independent code bases and independent processes.

There are not many reasons to keep them together. There are quite a few to make them separate, and everyone is doing it these days.

Answer 2

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

1. Is the main application: MVC (Controller) but and the Web services are different: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

6. Like [5], how many platforms and languages are you working with over the lifetime of the project? You might find that in 5 years, your company wants to move away from C# on onto NodeJS/Go-Lang. You're building new areas to this collection of systems. You simply create a new project, which is deployed to its own (set of) subdomains (or virtual folders), and with the magic of web standards you can interoperate. You're still using HTML/CSS/JS on the client side, no user sees the backend. So even if you start with a single "solution" with a single "project", you should not be closed to federating to additional "projects", in fact such a closed-minded approach can work against you.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...