Comments 16
Если кто-то планирует задействовать DRF для долгоживущего и очень highload проекта (десятки тысяч rps), то я бы обязательно упомянул два основных недостатка, на мой взгляд.
Первый недостаток. Отсутствие встроенного генератора документации. Все эти нашлёпки, ставящиеся сбоку, периодически валятся с непонятными симптомами, как только API чуточку усложняется. Конкретные примеры сейчас не приведу. Но это постоянный источник небольшой, но заметной боли (если говорить про годы поддержки и развития API).
Второй недостаток. Когда всё начинает тормозить (понимаю, что 99% проектов с этим не столкнётся), и начинаешь исследовать тормоза в профайлере и дебаггере, то там творится какая-то дичь. Данные десятки, если не сотни, раз преобразовываются из одного типа в другой, json'ы сериализуются, десереализуются, и сериализуются снова, всё это передается через лабиринт вызовов вверх и вниз по стеку. Когда начинает играть роль каждая микросекунда, выясняется, что этот монстр жуёт жвачку из данных, как корова, очень долго, и ускорить этот процесс без переписывания без DRF, никак нельзя.
А альтернативы какие?
Яндекс думает, что самописное все на плюсах. Как показывает их опыт - это вполне себе вариант
Честно говоря, сам ещё не определился. В конкретных ручках, где важны сотни и десятки миллисекунд, делаю по самому простому brute force варианту: заменяю всю машинерию DRF на закат солнца вручную: ручная десериализация и сериализация.
Если можно легкой кровью вынести часть ручек в отдельный микросервис, выносится в микросервис на FastAPI или Go.
Но повторюсь: большинство с этим не столкнётся. Однако, если вдруг сталкиваешься, то положение плачевное. DRF - всё-таки наверное одна из самых тяжёлых реализаций REST. Хотя бенчмарки не проводил, но по результатам профилирования возникали мысли, что оно всё переусложнено на порядок, а то и два.
Первый недостаток хорошо закрывается drf-specracular
Проблема всех этих проектов, что они - сторонние. Их авторы не всегда успевают или хотят синхронизироваться с версиями DRF, или иногда вообще забрасывают свои творения на полдороге (как было с drf-yasg, или чем-то похожим, копаться и вспоминать сейчас некогда).
Я бы с таким настроением предложил вообще код перестать писать) Ну, или писать абсолютно всё самому (тут просто пожелаю удачи).
Во-первых, у вас всегда будет что-то стороннее. Во-вторых, стороннее - необязательно плохое и не всегда умирает. Сам drf тоже, по сути, сторонний для джанги, но в целом всё даже ок (ну, кроме отсутствия поддержки асинка).
В третьих, не стороннее не даёт вам никаких гарантий. В дрф же есть встроенная генерация опенапи, но кто-то ей пользуется?)
Полноценное API
создадим API, которое будет
Так пишет Опытный python разработчик с многолетним стажем.
Печаль
Слово “API” (Application Programming Interface) в русском языке обычно используется как среднего рода. Например, можно сказать “это API”, “новое API” или “полноценное API”. Однако, если быть точным, “интерфейс” — это слово мужского рода. Но я предпочитаю использовать тот вариант, который чаще встречается в реальной жизни.
Теперь хотелось бы понять, как эта ошибка указывает на мою неопытность?
Что касается кода моего полноценного API, есть ли там какие-то ошибки? Или вы не работаете с кодом?
лучше писать и говорить правильно, чем неправильно
Как использование слова “оно” в отношении API указывает на мою неопытность как программиста? Я и в повседневной жизни так говорю. Мы с вами не работаем вместе, вы меня не знаете, но решаете, что можно делать выводы о моем опыте. Ваш комментарий сначала показался мне написанным подростком, а теперь оказывается, что вам за 50. Как это вообще возможно? Если я ошибся, скажите об этом. API - мужской род, исправьте. Зачем упоминать мой статус и опыт здесь?
Полноценный API на Django REST Framework: легкая разработка, автодокументация и быстрый деплой