Pan Propan

https://docs.djangoproject.com/en/4.1/ref/models/f...

Она там не нужна. Папку в .gitignore, а вот package.json и package-lock.json в репозиторий.

Этот код не работает. Совсем.

Разумеется, всё работает. Между "не работает" и "работает не так, как бы мне хотелось" существенная разница. Допускаю, что для вас она трудноуловима, но она всё-таки есть. Попытайтесь её осознать.

test: function() {
    _.debounce(function() {
            console.log('test222');
        }, 500);
}

В debounce должен был быть обёрнут сам метод:

test: _.debounce(function() {
  console.log('test222');
}, 500)

В плане безопасности и токен, и куки равны. Под безопасностью имею ввиду сложность взлома.

Можно выделить несколько основных отличий:
1. Куки - хранятся на сервере и на клиенте, токен - хранится на клиенте
2. Куки привязываются к домену, который авторизовался, а токен нет - это даёт большую гибкость, и она становится необходимостью при разработке распределённых систем.
3. Токен можно использовать выборочно на запросах, а куки на всех запросах. В случае с куки, это может привести к XSRF атакам, т.к. после авторизации, все запросы будут считаться авторизованными. Например, ты авторизовался на сайте site.com, я отправил тебе письмо с таким тегом:

<img src="https://site.com/money?money=200&to=me />

. В результате мне перечислит 200 единиц, т.к. после авторизации с куки, все запросы считаются авторизованными и запрос https://site.com/money?money=200&to=me отработает. Способы защититься от таких атак существуют.

В последние пару лет токены стали чаще использовать, по трём причинам:
1. Они stateless, что больше соотвествуют SPA (angular, vue, react) - один из моментов SPA в том, что состояние клиента находится на клиенте.
2. Гибкость, т.к. токены не привязаны к одному домену
3. Они набрали популярность))

За последние два года лично мне не попадалось проектов с куки-авторизацией, стек .net + angular/react

https://dev.to/spukas/authentication-cookies-vs-to...
https://stackoverflow.com/questions/17000835/token...
https://www.linkedin.com/pulse/cookie-vs-token-aut...

Можно написать функцию-плагин для стора Vuex. В ней слушать события мутаций и делать что-то, например, сообщать левому классу что есть новости.

Пример: функция подписывается на мутации стора. При загрузке страницы запускается Action в сторе, который имитирует асинхронную загрузку чего-то через 1 секунду (увеличит счетчик).

Задай дочерним компонентам относительные пути. Ну и в router-link в :to лучше писать не путь, а объект с именем и параметрами, что-то типа {name: 'complete'} (и лучше навести порядок с регистрами имен :) )

Давайте, для начала, поймем ваши цели. Вы хотите создать свой API, пообщаться с существующим, или приделать свой UI для известного API?

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

Пообщаться с существующим API можно, помимо, например, Postman-а и подобных инструментов, с помощью SwaggerUI, который написан на JS и может быть размещен, например, на вашем сервере. Достаточно подсунуть ему спеку интересующего вас сервера и он, в более или менее удобной форме, позволит увидеть доступные вызовы, отправить запрос, получить ответ, ну и прочитать описание каждого вызова, если автор спеки об этом позаботился. Задача swagger - это представить машинно понятное описание api, со всеми используемыми структурами запросов и ответов, чтобы клиентский код сумел его разобрать, отправить запрос, обработать ответ, и возможно, по крайней мере теоретически, сформировать форму, чтобы пользователь мог ввести свои данные, например, для отправки их в БД. Ни для чего больше, как машинно понятное описание API swagger не предназначен.

Ну и уже должно быть понятно, что SwaggerUI не предназначен для создания собственных клиентов к API. Это скорее интерактивная документация к сервису, который описан в спеке.

В выборе средств реализации пользовательского UI вы не ограничены ни чем. Мобильное приложение, десктоп, веб с шаблонами a-la django, spa приложение, все к вашим услугам. На реализацию серверной части это ни как не завязано.

Если этот компонент выше - $emit событие.
Если этот компонент ниже - через props.
Если эти компоненты широко разнесены, но всегда находятся логически в одном родителе - provide в родителе и inject в обоих комонентах.
Eсли они они связаны общей логикой - отдельный реактивный объект
Vue.observable/Vue.reactive и, соответственно, import в обоих компонентах.
И, наконец, если компоненты никак не связаны и таких ситуаций много - Vuex.)

host = "172.22.0.2"
Замените на
server="db"
Или
host="db"
(Точно пайкопгвский синтаксис не помню)
И это вам не помешает, но явным созданием бридж сети и биндом сервисов к ней вы воспроизвели поведение по умолчанию, тоесть написали много всего лишнего.

Просто отправляешь переменную id.
"message": f"Твой id: {id}"