Разработка веб-приложения на Python с использованием FastAPI и Docker

Кто-то пользуется докер отдельно от docker-compose? Ведь как минимум всегда нужно прописать порты, зачем это каждый раз делать в терминале.

Странно, в документации FastAPI есть и туториал, и пример использования (и оно даже на русский язык переведено), а у вас всё равно получилось что-то иное.

Предлагаю потратить время и доработать приложение в соответствиями с тем, что пишут в документации чтобы не ограничиваться только целью лабораторной работы. И, пожалуйста, пишите юнит тесты. Они нужны этому приложению.

Вроде как лучше надо так: сначала

COPY ./requirements.txt /app

RUN pip install

А потом уже копировать исходники, чтобы не скачивать зависимости при каждом изменении исходников

познаваательно

После:

Написание веб-приложения:...
1. Создать файл main.py и запустить его

тупик. touch main.py nano main.py ?

Почему в post методе передается не объект, а поля по отдельности в качестве аргументов?

Вместо global обьявить можно так:

app.get_ids = []

И все методы спокойно могут обращаться без глобалок

    except IndexError:
        raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST, detail='item does not exists')

Здесь всего в двух строках содержится уйма проблем:
1. BAD_REQUEST здесь не подходит. Холиварный вопрос, конечно, но BAD_REQUEST обычно означает, что клиент неправильно составил запрос(к примеру, передал строку вместо числа), здесь же клиент передал число(иначе fast api сам автоматически обработает некорректные данные). И вот допустим, кто-то захочет использовать это API и задумается, почему, когда он делает GET /items/1 все нормально, а когда GET /items/2 - возвращается BAD_REQUEST. Понятно, что догадаться можно, на практике приходилось сталкиваться и с куда более ужасными API, но это все таки обучающая статья, и она должна придерживаться принятых стандартов.
2. Действительно, fast api умеет преобразовывать исключения в response c соответствующим кодом, но это сделано больше для защиты от необработанных исключений, так что это не повод возвращать любой код, отличный от 2XX. Лучше возвращать Response. Исключения на то и исключения, чтобы выражать через них только экстраординарные ситуации, которых по идее возникнуть не должно, а здесь элемент не найден - вполне стандартная ситуация. Вот пример: https://github.com/sh-vasily/nosql-2023/blob/74073a6095fe1675e12be12d0e2f2f85936dc4ee/router/students_router.py#L26
3. Тоже в тему исключений: зачем вы отлавливаете IndexError, если можно сразу вначале проверить, есть ли значение с таким индексом? IndexError это ошибка, при этом то, что если клиент запросил по индексу, которого нет, это вполне ожидаемо. Исключения нельзя использовать для выражения ожидаемого поведения, они нарушают структуру кода, создавая множество скрытых точек выхода, что затрудняет чтение и изучение кода. Может быть в реальности на очень маленьком проекте, где весь код умещается в одной функции можно забить, но в больших приложениях это чревато проблемами. И опять же я бы понял, если бы это сделал стартап, где нужно срочно успеть сделать новую фичу для инвесторов и нет времени наводить красоту кода, но здесь учебная статья, зачем учить людей писать плохой код?