Before we know about WSGI(Web Server Gateway Interface) and ASGI(Asynchronous Server Gateway Interface), we have to talk about what is CGI.

Let's say there's a server and a user. The user sends a request to the server, and the server responds.

If the user request a static page, for example, index.html, return it as it is.

But what if the request is dynamic?

What should we do when the value changes from time to time, such as log-in or requesting membership?

For that, web application runs on the server, processes certain actions (such as accessing the database) and returns html accordingly.

So we need to able to hand over requests that eventually come into the server to the web application.

At this time, it would be very inconvenient if each server or application language had different forms, so a common standard interface should be provided as much as possible.

And this interface is CGI, Common Gateway Interface.

However, this CGI has the disadvantage of having to start the application process again whenever a request is made.

This inefficiency is apparent in scripting languages such as Python because it requires more time than running programs in compiled languages such as C.

WSGI stands for Web Server Gateway Interface. It looks like a universal technique by name, but it's a concept used in Python.

The biggest drawback of CGI earlier is that it creates a new process every time a request is made.

It's a concept designed to compensate for these shortcomings.

For the CGI described earlier, the information about the request is treated as an environment variable or STDIN, but WSGI treats it as a callable object, function, or object.

When the server passes information about the request through the Callable object and the Callback function, the application processes the request and executes the Callback function.

Servers or applications that implement these interfaces are called WSGI compatible, especially in the case of applications, they are called WSGI applications.

In addition, WSGI Middleware is a kind of WSGI application that manages authentication and cookies.

This includes commonly used gunicorn, etc.

WSGI usually exposes a Python function named application or app to a web server.

This function receives two parameters:

• environ : a dictionary containing information about the environment variables and current requests provided by the web server

• start_response : Function used to initiate an operation that sends an HTTP response to the client

The data returned by the function constitutes the response body.

A simple application function has the following form:

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [b'Hello world']

If you use WSGI-compatible web framework, the framework itself provides an application function and all components of this function are automatically connected.

This WSGI had a drawback in asynchronous request processing.

It useOne synchronous callable received a request and returned a response, which was not suitable for connections that needed to be kept long(long-poll HTTP or web socket).

ASGI was created to improve this. According to ASGI's official description,

"ASGI is the spiritual successor to WSGI. Provides standard, asynchronous interfaces between Python Web servers, frameworks, and applications. If WSGI provided a standard for synchronization for Python apps, ASGI provides a standard for both synchronization and asynchronization."

ASGI is an interface that is compatible with WSGI and can handle asynchronous requests.

As an ASGI server, people usually use Uvicorn, etc.

On the surface, ASGI is similar to WSGI.

As with WSGI, it defines an application function object.

The difference is that it is an async function and has three parameters, not two.

• scope : A dictionary containing the information about the current request, similar to WSGI's environ, but slightly different detailed naming conventions.

• send : An async callable function that allows the application to send a message back to the client.

• receive : Async callcable that allows application to receive messages from clients.

A simple application function has the following form:

async def application(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ],
    })

    await send({
        'type': 'http.response.body',
        'body': b'Hello, world!',
    })

Like the WSGI web framework, the ASGI web framework creates its own application() function and connects as needed.

The biggest characteristic of ASGI is that it uses asynchronous metaphors across functions.

The function itself is async and sends the HTTP header and the response body in two separate await send() commands.

Therefore, the function itself and its send command do not block anything.

That is, it is possible to cross many other connections at the same time as application and send calls.

https://nitro04.blogspot.com/2020/01/django-python-asgi-wsgi-analysis-of.html

https://www.itworld.co.kr/news/245062

Before we know about WSGI(Web Server Gateway Interface) and ASGI(Asynchronous Server Gateway Interface), we have to talk about what is CGI.

Let's say there's a server and a user. The user sends a request to the server, and the server responds.

If the user request a static page, for example, index.html, return it as it is.

But what if the request is dynamic?

What should we do when the value changes from time to time, such as log-in or requesting membership?

For that, web application runs on the server, processes certain actions (such as accessing the database) and returns html accordingly.

So we need to able to hand over requests that eventually come into the server to the web application.

At this time, it would be very inconvenient if each server or application language had different forms, so a common standard interface should be provided as much as possible.

And this interface is CGI, Common Gateway Interface.

However, this CGI has the disadvantage of having to start the application process again whenever a request is made.

This inefficiency is apparent in scripting languages such as Python because it requires more time than running programs in compiled languages such as C.

WSGI stands for Web Server Gateway Interface. It looks like a universal technique by name, but it's a concept used in Python.

The biggest drawback of CGI earlier is that it creates a new process every time a request is made.

It's a concept designed to compensate for these shortcomings.

For the CGI described earlier, the information about the request is treated as an environment variable or STDIN, but WSGI treats it as a callable object, function, or object.

When the server passes information about the request through the Callable object and the Callback function, the application processes the request and executes the Callback function.

Servers or applications that implement these interfaces are called WSGI compatible, especially in the case of applications, they are called WSGI applications.

In addition, WSGI Middleware is a kind of WSGI application that manages authentication and cookies.

This includes commonly used gunicorn, etc.

WSGI usually exposes a Python function named application or app to a web server.

This function receives two parameters:

• environ : a dictionary containing information about the environment variables and current requests provided by the web server

• start_response : Function used to initiate an operation that sends an HTTP response to the client

The data returned by the function constitutes the response body.

A simple application function has the following form:

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [b'Hello world']

If you use WSGI-compatible web framework, the framework itself provides an application function and all components of this function are automatically connected.

This WSGI had a drawback in asynchronous request processing.

It useOne synchronous callable received a request and returned a response, which was not suitable for connections that needed to be kept long(long-poll HTTP or web socket).

ASGI was created to improve this. According to ASGI's official description,

"ASGI is the spiritual successor to WSGI. Provides standard, asynchronous interfaces between Python Web servers, frameworks, and applications. If WSGI provided a standard for synchronization for Python apps, ASGI provides a standard for both synchronization and asynchronization."

ASGI is an interface that is compatible with WSGI and can handle asynchronous requests.

As an ASGI server, people usually use Uvicorn, etc.

On the surface, ASGI is similar to WSGI.

As with WSGI, it defines an application function object.

The difference is that it is an async function and has three parameters, not two.

• scope : A dictionary containing the information about the current request, similar to WSGI's environ, but slightly different detailed naming conventions.

• send : An async callable function that allows the application to send a message back to the client.

• receive : Async callcable that allows application to receive messages from clients.

A simple application function has the following form:

async def application(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ],
    })

    await send({
        'type': 'http.response.body',
        'body': b'Hello, world!',
    })

Like the WSGI web framework, the ASGI web framework creates its own application() function and connects as needed.

The biggest characteristic of ASGI is that it uses asynchronous metaphors across functions.

The function itself is async and sends the HTTP header and the response body in two separate await send() commands.

Therefore, the function itself and its send command do not block anything.

That is, it is possible to cross many other connections at the same time as application and send calls.

https://nitro04.blogspot.com/2020/01/django-python-asgi-wsgi-analysis-of.html

https://www.itworld.co.kr/news/245062