mr_forlife

Варианты 1 и 2 ссылаются на вполне конкретный класс dict. Когда typing только ввели, стандартынй dict не поддерживал такую запись, поэтому создали псевдоним typing.Dict. Потом к этому типу (а также к tuple и list) прикрутили возможность вести себя как генерик. Сейчас Dict, List и Tuple потихоньку планируют выводить из употребления. Они deprecated начиная с питона 3.9.
Вариант 3 - это любой объект, который ведёт себя как словарь, не обязательно именно dict. Но с 3.9 это алиас для collections.abc.Mapping, по той же самой причине.

Так что вариант 2 и 3 имеет смысл, только если тебе нужно поддерживать питон 3.8 и младше.
Выбор между вариантом dict и collections.abc.Mapping зависит от того, что именно тебе нужно - вот прямо dict, или просто что-то словареподобное. См. список методов Mapping тут.

Связь осуществляется через сетевое соединение, а именно через сокеты и кучу разных протоколов поверх типа HTTP/WS и прочего. На стороне сервера реализуете выбранный вами протокол в виде сервиса API, который слушает сокет, а в десктопном приложении подключаетесь к серверу и взаимодействуете с API вашего сервиса.

asyncio - это, скорее, как обойтись без многопоточности.
Она хорошо работает для ситуаций, когда большая часть времени потока выполнения уходит на ожидание ввода-вывода - например, на ответ по сети. Если у тебя есть что-то, что занимает CPU, или любая другая операция, выполняемая вне рамок ввода-вывода через asyncio - это остановит выполнение асинхронной программы.
Если на пальцах, то асинхронная программа состоит из отдельных корутин. Разница с потоками в том, что потоки переключает ОС, а корутины сами отдают управление, когда уходят в ожидание события (грубо говоря, когда делают вызов с await). Это упрощает синхронизацию корутин, так как ты точно знаешь, когда твоя корутина отдаст управление - меньше шансов налететь на состояние гонки из-за внезапного переключения. Опять же, переключение корутин куда более детерминировано, чем переключение потоков, так что "плавающие" баги встречаются реже.
Тело асинхронной программы - это рабочий цикл (т.н. реактор, он же loop), который проверяет выполняемые операции ввода-вывода, и возобновляет выполнение корутины, когда её операция завершилась. Когда корутина завершится или запланирует ещё одну операцию, она вернёт управление в цикл. Вот почему "задумавшаяся" корутина остановит всю программу.
Минус в том, что в отличие от многопоточности, нельзя просто вжжжжжжух и сделать код асинхронным. Он должен писаться как асинхронный с самого начала, с прицелом на исполнение в реакторе.

А чем не устраивает официальное описание? Далее мой вольный перевод:

Чтобы сконфигурировать приложение, создайте модуль apps.py внутри приложения, затем определите тут класс - инстанс AppConfig.
Когда INSTALLED_APPS содержит путь отделенный точками к модулю приложения, по умолчанию, если Django находит только один инстанс класса AppConfig в модуле apps.py, он использует эту конфигурацию для приложения. Это поведение можно отключить установкой AppConfig.default в False.

Если модуль apps.py содержит более одного инстанса класса AppConfig, Django будет использовать тот, в котором AppConfig.default будет установлен в True.

Если никаких инстансов AppConfig не будет найдено, будет использован базовый AppConfig.

Как вариант, INSTALLED_APPS может содержать путь отделенный точками к классу, чтобы указать его явно:

INSTALLED_APPS = [
    ...
    'polls.apps.PollsAppConfig',
    ...
]

Сам Django использует по умолчанию путь до приложения:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
...

а не

INSTALLED_APPS = [
    'django.contrib.admin.apps.AdminConfig',
    'django.contrib.auth.apps.AuthConfig',
...

Поэтому если вам не нужно указывать по какой-то причине путь к инстансу AppConfig приложения явно - то можно ограничиться только путем к приложению.

https://ru.m.wikipedia.org/wiki/Diff
Раздел Универсальный формат

как минимум - так запускать надо:
python3 manage.py runserver 0.0.0.0:8000
иначе джанго слушает локалхост у себя внутри контейнера

Untiwe я доработал твой код.
Вся хитрость в 2х звёздочках **

def get_queryset(self):
        if not self.request.GET:
            return Posts.objects.all()#если нет параметров, просто возвращаем все посты
        keyword = self.request.GET.get('key')#получаем ключевое слово
        filters = Q()#создаем первый объект Q, что бы складывать с ним другие
        for key in ['author', 'name', 'text']:
                value = self.request.GET.get(key)
                if value:
                        filters |= Q(**{f'{key}__icontains': keyword})
        return Posts.objects.filter(filters)