Простим душность комментатора, но одно не простим, почему он не почитал статью внимательно, где сказано, что мне есть много еще о чем рассказать в контексте DRF и не хотелось бы раздувать статью в лонгрид
Рад, что на хабре есть "неповторимый ориганал", который можно перечитывать после мастер-класса в комментариях
Интересная характеристика по поводу моих знаний. Да, может я не нишевый специалист, но работал в различных секторах, где используют фреймворк и видел, как делают хорошо, а как делают плохо.
Откуда информация что View, представленная в коде - конечная реализация? Это вырванный контекст, который создан лишь для того, чтобы продемонстрировать работу с query и path параметрами запроса.
В статье "появился" DRF, чтобы читатели понимали, что я говорю о Django как backend разработчик, а не fullstack или разработчик проектов для портфолио фотографа. Более того, упоминания не фигурируют в тезисах.
Причем здесь готовый template, когда для новичков классический тутор представлен на базисе предложенной структуры, и она не меняется годами и все ещё диктует особые правила? Если у вас свой подход по разработке, это решение уместно, конечно, вдобавок когда у вас однотипные проекты.
А разве из названия статьи сложно догадаться, что тут никаких предложений не будет, потому что речь идёт об устоявшемся фреймворке, иначе бы статья именовалась как "я ушел с фреймворка, и начал кодить так" или "как делать не надо, а как надо".
В сухом остатке получаем поиск статей и докладов по расчистке Джанги и сеньоров, которые после громких бигтехов не слышали про типизацию, асинхронку и паттерны проектирования.
Верно. Посыл в том, что Django - швейцарский нож, но во многих случаях его не стоит использовать. Посмотрите на курсы или ит-бизнес, везде суют фреймворк где надо и не надо. Плюсом речь о том, что если использовать фреймворк как базис для того же drf можно нахватать много плохих практик, и % poop-кода в бэкенде преобладает на Django, как мне кажется. Приложение, ограничивающееся админкой и базовым функционалом - идеальное решение для Django, совсем не спорю.
Простим душность комментатора, но одно не простим, почему он не почитал статью внимательно, где сказано, что мне есть много еще о чем рассказать в контексте DRF и не хотелось бы раздувать статью в лонгрид
Рад, что на хабре есть "неповторимый ориганал", который можно перечитывать после мастер-класса в комментариях
Интересная характеристика по поводу моих знаний. Да, может я не нишевый специалист, но работал в различных секторах, где используют фреймворк и видел, как делают хорошо, а как делают плохо.
Откуда информация что View, представленная в коде - конечная реализация? Это вырванный контекст, который создан лишь для того, чтобы продемонстрировать работу с query и path параметрами запроса.
В статье "появился" DRF, чтобы читатели понимали, что я говорю о Django как backend разработчик, а не fullstack или разработчик проектов для портфолио фотографа. Более того, упоминания не фигурируют в тезисах.
Причем здесь готовый template, когда для новичков классический тутор представлен на базисе предложенной структуры, и она не меняется годами и все ещё диктует особые правила? Если у вас свой подход по разработке, это решение уместно, конечно, вдобавок когда у вас однотипные проекты.
А разве из названия статьи сложно догадаться, что тут никаких предложений не будет, потому что речь идёт об устоявшемся фреймворке, иначе бы статья именовалась как "я ушел с фреймворка, и начал кодить так" или "как делать не надо, а как надо".
В сухом остатке получаем поиск статей и докладов по расчистке Джанги и сеньоров, которые после громких бигтехов не слышали про типизацию, асинхронку и паттерны проектирования.
Верно. Посыл в том, что Django - швейцарский нож, но во многих случаях его не стоит использовать. Посмотрите на курсы или ит-бизнес, везде суют фреймворк где надо и не надо. Плюсом речь о том, что если использовать фреймворк как базис для того же drf можно нахватать много плохих практик, и % poop-кода в бэкенде преобладает на Django, как мне кажется. Приложение, ограничивающееся админкой и базовым функционалом - идеальное решение для Django, совсем не спорю.