0
votes

currently if I want to work with asp.net core and angular I do the following:

  • create a client app with angular cli
  • create an asp.net core mvc app
  • connect the two with Microsoft.AspNetCore.SpaServices.Extensions (spa strategy = proxy)
  • modify the Index.html of the mvc app like this:

@section scripts {
    <script src="runtime.js"></script>
    <script src="polyfills.js"></script>
    <script src="styles.js"></script>
    <script src="vendor.js"></script>
    <script src="main.js"></script>
}
<app-root></app-root>
  • modify the _Layout.html like this:

<!DOCTYPE html>
<html lang="en">
<head>
    <base href="/">
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>App</title>
</head>
<body>
    <h2 class="bg-dark text-white p-2">App</h2>
    @RenderBody()
    @RenderSection("Scripts", required: false)
</body>
</html>

Then I start the angular server and run the mvc app too. As you can see, in this case I use the Index.html of the mvc app and projects the angular content into it. I will use the asp.net core app only for serving Rest api request, so nothing with views, etc.

I have three questions on it:

  • Is the above described a convenient way to work with angular, where the asp.net core part is acting only as a Rest api server? If not, then what is it?
  • Could I use the index.html of the angular client app too? I mean, the asp.net core part would be really only serving the api requests and the entry point of the app would be the index.html of the angular client app?

Thank you for your answer/comments.

1

1 Answers

0
votes

Approach you are following is simpler than building 2 separate application and for small projects it's fair to use it. Despite it's simpliness it has major downsides which IMO eliminate this approach from more complex solutions, e.g.

your REST API should be responsible only for serving data, and with solution you are following you are coupling it with hosting your front-end part. What will happen if you will decide to add another UI part to the system, or change framework etc? Code will have to be modified in both frontend and backend apps.

Another issue with this approach is mainaining 2 applications in one code base.

I believe that this approach is fair for small projects, but for more complex ones you should stick with separation of concerns and build 2 separate applications.