Splitting up WebApi project and FrontEnd project in Solution

Question

I have a solution for a mobile application I'm building - so far this consists of two projects:

   1) WebAPI for API / DAL / SQL etc
   2) Web for single-page front-end

The Web project makes calls to the WebAPI project. The plan is to create another project for a Windows 8 application, another for a WP8 app, etc.

This has worked alright while developing, but it has become quite complicated with CORS, deployments, etc (Web is served up from a different endpoint than WebAPI - two Azure Web Sites). My question is - when architecting a solution that's backed by a REST-ish API, when is it wise/unwise to split up the solution into multiple projects?

Answer 1

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. Normally the 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.