С Django мы все дальше от Бога

[Fox_exe]

Вообще не понял, зачем вам Django, если вам нужен ТОЛЬКО API (для чего и существует FastAPI)?

Django - это про управление данными в БД благодаря его админке и отображение этих данных. Отсюда и упор в шаблонизатор.

Прошу, не надо забивать гвозди микроскопом...

[nutsdonuts]

Верно. Посыл в том, что Django - швейцарский нож, но во многих случаях его не стоит использовать. Посмотрите на курсы или ит-бизнес, везде суют фреймворк где надо и не надо. Плюсом речь о том, что если использовать фреймворк как базис для того же drf можно нахватать много плохих практик, и % poop-кода в бэкенде преобладает на Django, как мне кажется. Приложение, ограничивающееся админкой и базовым функционалом - идеальное решение для Django, совсем не спорю.

[VskripnikV]

А бывает и наоборот. Делаешь какой то простой api, а получается на выходе подобие джанго

[bbc_69]

Джанга... Все её не любят, но продолжают ей пользоваться.

Команде нужно дорасти до TDD, но я также считаю, что работать с Django может только сильная команда, которая знает все тонкости фреймворка (а их настолько много, что грамотно стартануть не получится)

Всегда думал, что джангу выбирают из-за новичков. Там всё настолько стандартизованно, что новичку будет сложнее накосячить. Хотя обилие тонкостей меня при этом тоже всегда смущало. Но я джангу тоже не люблю - просто не понимаю, для кого она придумана.

Конечно, не беда. Ведь есть Django Rest Framework! Однако чтобы с ним работать, нам потребуется вся родословная Django с ее кучей инструментов, которые лягут мертвым грузом при разработке API.

Того, кто додумался в сериализаторе DRF сделать метод save, готов забить микроскопом по заднице!

[ovalsky]

На сколько я знаю, в сериализаторе метод save появился на стадии прототипа сериализатора, было удобнее для мелкого переоределения/валидации. Но никак не для бизнес логики. Это потом допилили остальные методы и этот остался как рудимент.
Вот почему не выпилили - непонятно

[bbc_69]

Да понятно, что это сделали для удобства. Но он же позиционируется как будто для новичков - а тут такой антипаттерн. У себя в проекте выпилил это ибо нефиг.

[tonyP]

Во многом соглашусь с автором. Как-то не задалось у меня с Джанго с самого начала. Ты создаёшь проект, а в нем уже кто-то намусорил, и с ходу разобраться что здесь нужно, а что нет тяжело. Предпочитаю более низкоуровневые библиотеки и фреймворки вроде flask или aiohttp, хотя в последние годы набрал популярность fastapi, но я уже не пишу на python.

[Andrey_mazo]

про что статья?

[Mhapach]

Laravel и ты станешь ближе к ...

[Acidter]

... археологии. Извиняюсь за такую шутку. Не помню уже когда видел PHP вне WordPress.

[danilovmy]

Да, автор. А ведь ты так и не понял Django. Как и её GCBV. Я бы тоже не засчитал detail view API построенное на View, один в один прям как однотипные неправильные ответы индусов со stackoverflow.

Каким-то образом в статье появился DRF (сторонняя библиотека) и пропал по тексту далее. Зачем тогда упоминалось? Кстати, у Тома, которого я знаю лично, есть несколько библиотек, одна из них входит в Django как dependency, вторая в FastApi, а третья - во все остальные.

``Django-admin startproject my_project, имеет дополнительный параметр --template, позволяющий иметь бесконечное количество разных готовых матрешек. Но автору всего этого "настолько много, что грамотно стартануть не получится".

В итоге получаем, что если по верхам прыгать, то ни один Frаmework не подойдет, там читать надо, да разбираться. А что полезного автор предлагает - я так и не понял.

Вспоминая, что "критикуешь - предлагай", предложу поискать записи моих докладов по raw Django RestAPI. Кому то будет полезно увидеть, что в современной Django DRF устанавливать уже не надо.

[nutsdonuts]

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

Откуда информация что View, представленная в коде - конечная реализация? Это вырванный контекст, который создан лишь для того, чтобы продемонстрировать работу с query и path параметрами запроса.

В статье "появился" DRF, чтобы читатели понимали, что я говорю о Django как backend разработчик, а не fullstack или разработчик проектов для портфолио фотографа. Более того, упоминания не фигурируют в тезисах.

Причем здесь готовый template, когда для новичков классический тутор представлен на базисе предложенной структуры, и она не меняется годами и все ещё диктует особые правила? Если у вас свой подход по разработке, это решение уместно, конечно, вдобавок когда у вас однотипные проекты.

А разве из названия статьи сложно догадаться, что тут никаких предложений не будет, потому что речь идёт об устоявшемся фреймворке, иначе бы статья именовалась как "я ушел с фреймворка, и начал кодить так" или "как делать не надо, а как надо".

В сухом остатке получаем поиск статей и докладов по расчистке Джанги и сеньоров, которые после громких бигтехов не слышали про типизацию, асинхронку и паттерны проектирования.

[ink_off]

А можно получить ссылку на такой доклад? Буду благодарен.