If I use N ajax requests simultaneously, am I still handling these requests synchronously on the server?

Depends on the server implementation. Typically, the response method has something like public async Task<> in the declaration, which indicates that the response will be processed as a separate thread (that is, scalably).

If yes, to create an asynchronous request on both the client-side and server-side, would I need to use threaded programming on the server?

Exactly.

What are the methods of creating asynchronous requests both front-end and backend?

Assuming your application is ASP.NET MVC, using Web API 2 or not, the prototype method looks something like this:

public async Task<IEnumerable<Noticia>> GetNoticias()
{
    return await db.Noticias.ToListAsync<Noticia>();
}

• async indicates that the method runs asynchronously;
• Task is to indicate to the object that will handle your thread what kind of return will be done;
• % with% Suspends the thread until the return is committed . Thread suspension does not interrupt other streams being executed;

Imagine the following scenario: 50 users are accessing your application simultaneously. They do things there, and some of them are client requests to the server - such requests are asynchronous .

When this happens, multiple parallel and concurrent requests are sent to your server and it resolves how to handle it.

When firing more than one request (asynchronous or not) at a time to the server, the server's behavior is not necessarily based on a method you use.

Let's take a look at your question:

  

[...] would I need to use threaded programming on the server?

An asynchronous process is dispersed to threads - they are not things that should be compared because they have relatively different purposes.

So to make it clear: you do not have to do anything nothing on the server if you do not feel it is necessary. Your requests are made to the server through a method / verb and depending on the routing of an intermediary - controllers, for example - your application should react in a specific way.

Why are threads different from asynchronous processes?

Threads give an application the ability to work with competing processes. A computer can browse the internet and play music simultaneously because of them: they are parallel processes that consume processing - which is (re) used to perform multiple tasks.

Your application is one thing: what it does is its responsibility; if it will insert some information into the E database to display a message on the screen: the problem is entirely and exclusively from it - which in turn is a unique process.

The responsibility of making the database available for insertion of information and the browser that is where you will display the message is the responsibility of the operating system. Here, therefore, is where the threads . At first, you do not need and / or manage.

But what if I really want to use threads?

You can . Languages provide the means and mechanisms for this - C #, by the way, does it very well. What I'm trying to point out is that you do not necessarily need .

Environments and web languages are naturally equipped to deal with parallel processes and you can, for the most part, invest your time focusing only on your requests; on your "AJAX".