We're a team of developers working on Web-based (ASP.NET, MVC, Web API, Angular) project. Up to recent time, it was purely ASP.NET, MVC. Now we want to split project into several
- Server-side
- MVC (5.2) for forms entry (may be will begone in some future)
- Angular for client-side business logic
- Web API to expose server-side logic to (1) and (2)
Currently, we deploy (1) + (2) + (3) as IIS Website, all works fine. Adding (4) creates a bit of an issue -- all pros and cons are not clear to me. We will need calls from (3) to (4) and from (2) to (4) to make transition smooth and we need to keep authentication (Windows-based) in place for (4) as requirement from IT.
- Deploy Web API as a individual appilcation in IIS. How would different developers address (2) and (4) with different configurations on different machines (e.g.: Dev1 has (1)&(2): localhost:54345 and (4) localhost:61975, Dev2 has (1)&(2): localhost:21212 and (4) localhost:33124, QA instance: (1)&(2): qa-box/QAApp1, (4) qa-box/QAAPI1; production, etc) -- how to keep track that calls to (1)&(2) and (4) have different base URLs in different instances?
- Create a "proxy controller" in (2) that will proxy calls to (4), something like here: How to set up Web API Routing for a Proxy Controller? . However, it is not clear, how to pass user's authentication
- Just incorporate (4) into (2) by means of projects-dependencies inside one .sln and deploy just one application (not preferred solution, if we may need to extend (4) to a different server, etc
What would you suggest as a better approach on separating Web API and "workable" with in different deployments?
Thanks!