#django #django-rest-framework
#джанго #django-rest-фреймворк
Вопрос:
Я создаю приложение, основанное на API, с помощью Django REST framework, поэтому оно вообще не имеет HTML-представлений и использует только аутентификацию на основе токенов. В то же время я хотел бы использовать интерфейс администратора Django, что не является проблемой, но меня беспокоят затраты на производительность, поскольку это зависит от множества приложений (сеансов, стандартной аутентификации, сообщений, csrf и т. Д.), Которые не нужны в основном приложении, но будет выполняться при каждом запросе.
Есть ли способ настроить промежуточные программы, зависящие от администратора, для запуска только в интерфейсе администратора?
Я знаю, что могу подклассировать их и вызывать MiddlewareNotUsed для всех запросов, кроме тех, которые отправляются на сайт администратора, но, может быть, есть какое-то встроенное или хорошо известное решение для этого?
Комментарии:
1. вы параноик без причины. вы уже создаете первое приложение с API, и максимум, что вы будете делать с администратором Django, это, вероятно, отладка или просто просмотр вашей базы данных. Не беспокойтесь о производительности. Не переусердствуйте.
2. @Sahil Это именно та проблема. независимо от того, как я собираюсь использовать администратора, все приложения, от которых он зависит, будут запускаться при каждом запросе, включая запросы от пользователей api
Ответ №1:
Отвечая на ваш вопрос, нет, я не думаю, что существуют встроенные решения, которые удовлетворяют этим требованиям. Но это, вероятно, потому, что ваша цель не очень подходит для дизайна и философии Django.
Я согласен с комментарием Сахила по этому поводу. Раньше я тоже был параноиком по поводу производительности, но я понял, что недооценивал скорость Django (даже со всеми этими базовыми промежуточными программами), и что, если производительность была настолько критичной, мне, вероятно, вообще не следовало использовать Django. Я предполагаю, что отключение этого промежуточного программного обеспечения сэкономит время отклика приложения не более чем на незаметные миллисекунды; неизбежные колебания сети могут быть даже более значительными. Время разработчика стоит дороже, чем дополнительное оборудование, которое может быть использовано при возникновении любых проблем с производительностью и / или масштабируемостью.
Но если вы все еще хотите сэкономить на обработке промежуточного программного обеспечения, у меня есть альтернативная идея: функциональность удобства, предоставляемая администратором Django (то есть операции CRUD), может быть довольно быстро реплицирована с помощью наборов представлений DRF. Возможно, вы могли бы создать соответствующий клиент API, используя какую-нибудь быстроразвивающуюся интерфейсную платформу для своих пользователей. (Я собирался сказать, просто используйте DRF browsable API, но я вспомнил, что он также использует практически то же базовое промежуточное программное обеспечение, что и Django admin.)