Прочитав статью у меня появились вопросы к реализации.
Создав middleware вы заблокировали доступ к url с OpenApi по адресу «/docs», но это лишь часть беды. Как вы получаете доступ к регистрации пользователя, если перед созданием токенов для пользователя, в этой же middleware, идет проверка на наличие токена? Есть какая-то админская учетка, благодаря которой идет регистрация пользователя? Но тогда в чем идея, если каждый зарегистрированный пользователь может создавать других пользователей?
При написании тестов на Python в библиотеке unittest есть реализация mock-объекта, разработчик может создать mock-объект для условного requests.get, это позволит не поднимать сторонние сервисы, уменьшит время на поддержание актуального состояния mock-сервиса и даст возможность писать реализацию в коде)
Важно отличать подходы EAFP(Проще просить прощения, чем разрешения) и LBYL(Смотри, прежде чем прыгать). LBYL стоит применять когда ты работаешь со статическими данными, например: обработка результата функции, проверка ключа в словаре и т.д. EAFP используется когда работа ведется с динамически изменяемой средой, например: проверка доступности удаленного сервера не дает тебе гарантию, что сервер не сломается сразу после ответа на проверку, или файл не будет удален после открытия в приложении и т.д.
Хороший пример EAFP метод raise_for_status библиотеки requests, который поднимает ошибку, а не генерирует ответ с результатом валидации статуса ответа.
Отлично, что по моим вопросам уже есть решение, вероятно стоило описать это в статье, тогда некоторые вопросы сразу бы отпали
Прочитав статью у меня появились вопросы к реализации.
Создав middleware вы заблокировали доступ к url с OpenApi по адресу «/docs», но это лишь часть беды. Как вы получаете доступ к регистрации пользователя, если перед созданием токенов для пользователя, в этой же middleware, идет проверка на наличие токена? Есть какая-то админская учетка, благодаря которой идет регистрация пользователя? Но тогда в чем идея, если каждый зарегистрированный пользователь может создавать других пользователей?
При написании тестов на Python в библиотеке unittest есть реализация mock-объекта, разработчик может создать mock-объект для условного requests.get, это позволит не поднимать сторонние сервисы, уменьшит время на поддержание актуального состояния mock-сервиса и даст возможность писать реализацию в коде)
Важно отличать подходы EAFP(Проще просить прощения, чем разрешения) и LBYL(Смотри, прежде чем прыгать). LBYL стоит применять когда ты работаешь со статическими данными, например: обработка результата функции, проверка ключа в словаре и т.д. EAFP используется когда работа ведется с динамически изменяемой средой, например: проверка доступности удаленного сервера не дает тебе гарантию, что сервер не сломается сразу после ответа на проверку, или файл не будет удален после открытия в приложении и т.д.
Хороший пример EAFP метод raise_for_status библиотеки requests, который поднимает ошибку, а не генерирует ответ с результатом валидации статуса ответа.