Хм, не буду спорить, потому что на питоне в крупных проектах не участвовал. Но конкретно при работе с массивом я бы предпочел все таки if'ом индекс проверить)
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 это ошибка, при этом то, что если клиент запросил по индексу, которого нет, это вполне ожидаемо. Исключения нельзя использовать для выражения ожидаемого поведения, они нарушают структуру кода, создавая множество скрытых точек выхода, что затрудняет чтение и изучение кода. Может быть в реальности на очень маленьком проекте, где весь код умещается в одной функции можно забить, но в больших приложениях это чревато проблемами. И опять же я бы понял, если бы это сделал стартап, где нужно срочно успеть сделать новую фичу для инвесторов и нет времени наводить красоту кода, но здесь учебная статья, зачем учить людей писать плохой код?
Первый раз слышу про проблему с дополнительными терминалами. Понимаю ещё если бы их было десятки, но здесь их два всего лишь. Даже на Винде есть терминал, где можно сразу несколько разных терминалов внутри открыть, про Линукс и мак ось я вообще молчу. Но меня больше беспокоит даже не это.
Во-первых, точно ли нельзя из браузера запросы делать к апи Яндекса? Я как-то использовал также апи, там можно было.
Во-вторых, хорошо бы ещё хранить в бд результаты запросов, т.е. сделать из бэкенда кэширующее прокси, чтобы обойти ограничение на количество запросов.
И третье - самое важное: какую проблему вы решаете? Два терминала это не проблема. Как раз таки проблему вы создали скорее своим решением. Для локальной разработки этот вариант не подойдёт, потому что нужно каждый раз собирать фроненд проект и все фишки node js для отладки пропадают, для поставки на сервер, лучше nginx использовать.
Хм, не буду спорить, потому что на питоне в крупных проектах не участвовал. Но конкретно при работе с массивом я бы предпочел все таки if'ом индекс проверить)
Здесь всего в двух строках содержится уйма проблем:
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 это ошибка, при этом то, что если клиент запросил по индексу, которого нет, это вполне ожидаемо. Исключения нельзя использовать для выражения ожидаемого поведения, они нарушают структуру кода, создавая множество скрытых точек выхода, что затрудняет чтение и изучение кода. Может быть в реальности на очень маленьком проекте, где весь код умещается в одной функции можно забить, но в больших приложениях это чревато проблемами. И опять же я бы понял, если бы это сделал стартап, где нужно срочно успеть сделать новую фичу для инвесторов и нет времени наводить красоту кода, но здесь учебная статья, зачем учить людей писать плохой код?
Почему в post методе передается не объект, а поля по отдельности в качестве аргументов?
Интересно было бы сравнить такой вариант по скорости с dapper
Первый раз слышу про проблему с дополнительными терминалами. Понимаю ещё если бы их было десятки, но здесь их два всего лишь. Даже на Винде есть терминал, где можно сразу несколько разных терминалов внутри открыть, про Линукс и мак ось я вообще молчу. Но меня больше беспокоит даже не это.
Во-первых, точно ли нельзя из браузера запросы делать к апи Яндекса? Я как-то использовал также апи, там можно было.
Во-вторых, хорошо бы ещё хранить в бд результаты запросов, т.е. сделать из бэкенда кэширующее прокси, чтобы обойти ограничение на количество запросов.
И третье - самое важное: какую проблему вы решаете? Два терминала это не проблема. Как раз таки проблему вы создали скорее своим решением. Для локальной разработки этот вариант не подойдёт, потому что нужно каждый раз собирать фроненд проект и все фишки node js для отладки пропадают, для поставки на сервер, лучше nginx использовать.