How to build Single Page Application on ASP.NET?

Question

ASP.NET

I'm trying to find information on the Internet how to build single page applications in ASP.NET. Specifically, which technology to use: ASP.NET MVC or ASP.NET Web API?
As far as I understand, in the first case there are two options:

• use Razor as the main "framework" and template engine (without using third-party JavaScript frameworks) - render the desired piece of the page on the server and give the client ready-made html upon request (the minus of the approach is that it takes longer due to the amount of data transferred, and the page itself is rendered on the server, not on the client, as is customary in SPA)
  
• or return only json with the necessary data, and build the page itself with some kind of Knockout or Angular (why would Views (.cshtml pages) and Razor be needed then)
  

In case of using ASP.NET Web API:

• the server will simply give the necessary json with the data, and then my client part can receive them and render the page
  

In this case, as I understand it, there will be two separate applications: a Web API project and a client written in anything. But now this violates the Web API ideology. How many such requests will I need to declare to make this application work. It seems to me wrong to build the entire work of a web application through such calls. API - it's also an API to give you limited functionality.
Help me make a choice and generally explain how to build a SPA on ASP.NET more competently. I myself tend to use the capabilities of Razor - make a request via JavaScript to the desired URL, get a ready-made piece of HTML and substitute it in the right place on the page.

Answer 1

Basically, you've described two ways of building SPA rendering: server rendering and client rendering.
The first approach has a minus in a large amount of data transferred, but a plus in simple rendering without load on the client (we simply replace part of the DOM tree with the one that came from the server). The second approach has the advantage of less data transfer, but the disadvantage of more manipulation of the DOM tree, which can affect the responsiveness of the page. But, for example, React and Angular currently work with the so-called "shadow" or "virtual" DOM ​​tree, when the tree is built in memory and simply replaced, so the second minus, in principle, is no longer a minus if you use these tools .
There is also an isomorphic approach to building a SPA: at the first request, the page is rendered on the server and given to the client, after which scripts are loaded in the background and then everything is rendered on the client, the server returns only JSON.
There are ready-made project templates for ASP.NET Core. Just a couple of commands are enough to create, for example, a project based on Angular:

dotnet new --install Microsoft.AspNetCore.SpaTemplates::*
cd <project_folder>
dotnet new angular

Read more here: https://blogs.msdn.microsoft.com/webdev/2017/02/14...

Answer 2

In general, using ASP.NET MVC for SPA applications is a so-so idea. The most ideal bundle (in an ASP.NET environment) is ASP.NET Core Web API + a separate Angular / React project that can be built into the wwwroot Web API folder of the project for production. Specifically, such an implementation option was discussed here.. In short: create a Web API project (where you keep requests that will return or write the necessary data) and create an Angular / React / Any Other Framework project that is fully responsible for the web interface; set up a proxy for requests (to pull API methods from a separate project during development); teach your builder to build the project in the wwwroot folder; profit :). As a result, we have two projects that, during development, communicate from two different ports, and in production, one project that opens the index.html page with all the logic from wwwroot.

Answer 3

We have this:
1) we get an html page
2) it loads JS scripts
3) they access ashx - which return json
4) from json we generate HTML code on the client.
As an option, generate HTML code on the server.