How to structure code to have 2 web apps deployed to the same Azure App Service

Question

I am starting a new project (let's call it MyWebProject) which will have

1. MyWebProject: a front-end app with AspNet Core serving a SPA with Angular2
2. MyWebProjectAPI: a back-end app with AspNet Core connected to a DB and exposing RESTful API

They don't have inter dependencies since MyWebProject access MyWebProjectAPI through http requests only. So we could say they are independent.

I have a single domain www.mywebproject.com linked to a single Azure App Service mywebproject.azurewebsites.net and I want to have both projects (front-end and RESTful API) deployed under the same Azure App.

If I access with a web browser www.mywebproject.com I want to access the front-end. I don't mind where the RESTful API is deployed (I'm guessing in a virtual directory under the same App Service IIS?)

I am also planning to have continuous deployment where pushing changes to a master branch in a Git repository would trigger a new deployment (ideally both deployments are configured separately but I don't mind that much)

The question is:

How to structure my solution/projects and what approach should I follow?

I am considering One single solution with the 2 main projects (front-end and back-end) plus library projects required by the back-end project, and therefore I am assuming they all would have to be in the same Git repository?. Would that be a problem? or is it better to have them in separate Git repositories and separate solutions? (this option would also be ok)

What would be the approach to follow when deploying into the same Azure App service? To use a virtual directory because they both are web projects (both have a wwwroot)?

Another option could be one single project for both RESTful API and front-end with one of the controllers simply serving the SPA and the other controllers acting as the API resources. This would certainly simplify everything, but somehow I wanted to have both projects independent.

Any reference, article or opinion would be appreciated.

Answer 1

I work with an app where we have one solution that two different Web Projects, both living at the same domain and both being deployed using continuous deployment. It works out fine. Here is how it works:

• Have one Visual Studio Solution
• Under that solution have the two web projects
• In the Azure Application settings for your App Service, scroll to the bottom under "Virtual applications and directories" and set up a Virtual Directory for MyWebProjectAPI. Virtual directory would be "/MyWebProjectAPI" and Physical path would be "site\wwwroot\MyWebProjectAPI"
• Create the deploy.cmd for doing the continuous deployment in the solution folder, just like normal
• Edit the deploy.cmd to also deploy the second web project.

You'll find a line for the first project that looks like:

call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProject\MyWebProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
IF !ERRORLEVEL! NEQ 0 goto error

Copy that code and update it to build the API project into the virtual directory (notice the first path changed as well as the PackageTempDir):

call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProjectAPI\MyWebProjectAPI.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%\MyWebProjectAPI";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" 
IF !ERRORLEVEL! NEQ 0 goto error

After you deploy, your front end will be at www.mywebproject.com and the api will be at www.mywebproject.com/mywebprojectapi (of course you can rename everything).

Is this the right way to go? There are pros and cons. In our case we needed to do it this way because the 2nd Web Project came from a third party and had to live at the same domain. And that's a big pro - you avoid any possible cross domain issues. Also you have a lot of consolidation with only one DNS entry to worry about (including SSL certificates) and only one App Service to pay attention to.

I could argue, though, that it would be better to let your code run in two apps to get more distinct monitoring and scalability. You said you only want one App Service right now, so either way you don't get the ability to scale. But if you set up two projects as different apps, you could eventually move them to separate App Services later if you needed to scale one and not the other.

If you did want two separate apps with different DNS entries, you could still have just one solution file. I don't have an exact example of doing this, but you would have both apps monitor that branch. So a build would kick off in both apps when you pushed. But you would add a setting in your Azure Application Settings saying which project should be built, and you'd modify your deploy.cmd file to look for this parameter to build the right one.