Splitting up WebApi project and FrontEnd project in Solution

I always split the API and front-end into separate projects for a few reasons:

Front-end dependencies (jquery, knockout, angular....) make the api heavier than necessary. Sifting through code for the "Other" project type can slow down development.

Source control can get a bit confusing when committing across two functionally separate projects within one project. If you change both the API and site within one commit, but then want to revert one of them to an older point in time (or promote them separately) this will become a headache.

By putting the projects together, you have to update shared dependencies all at once (upgrade to a new version of .NET?). IF your code for your API has dependencies on depreciated code, upgrading may be difficult and your website upgrade may be held back (or vise versa).

If they are within the same project, you can't easily publish just the API or Front-end. Normallythe API will be completed and stable long before you are done messing with the visual aspects of the site. You won't want to be held back by having to republish the API each time you make a minor site change.

Having both as the same project would require you to run both on the same webserver (and in the same application pool!). If you are going to have multiple sources hitting your API (usually the point of an API), then you wouldn't want the API degraded due to requests to the website. This goes both ways, if your API is being hit hard you do not want your site to become unresponsive.

Since they would run in the same application pool, they would also run as the same user. For security purposes you may want the API application pool to run as a separate service account that has integrated-auth access to your datasource. Then you could lock down the website user account and give it no access to external resources.

Since the MVC webapi template provides all the dependencies and configurations for a front-end, it may seem logical to put these together, but just because they made it easy doesn't mean it should be done that way. I usually strip down the front-end that is provided in this template and make it into a simple page to describe how to use the API.

In the end, MVC itself is all about separation of concerns and clean development. I would say that separating the project types follows this logic.

I cannot think of a technical reason to split a Visual Studio solution into a "client" solution and "service" solution. However, in my current work, we did split our solution to two because it was two separate teams working on the requirements. So, it is was purely an organiztional decision for us.