F
Я работал с несколькими серверными фреймворками, включая Django, Node.js + Express и Flask. Django - мой любимый фреймворк. Я не пытаюсь атаковать фреймворк или сообщество трудолюбивых людей, которые создали и поддерживали его. Однако я действительно думаю, что фреймворк начинает показывать свой возраст, и что, как разработчики Python, мы должны серьезно подумать о том, каким мы хотим видеть будущее веб-разработки Django и Python в более широком смысле.
Django был разработан в 2005 году (16 лет назад). Его обширный набор функций и подход «с включенными батареями» сделали его чрезвычайно эффективным для быстрой полнофункциональной веб-разработки, что позволило ему стать фаворитом миллионов разработчиков по всему миру. Я сам являюсь одним из этих разработчиков и благодарен Django и всем проектам, которые он позволил мне успешно реализовать.
Тем не менее, 2005 год был давно, и сказать, что с тех пор Интернет сильно изменился, было бы преуменьшением. Требования и ожидания внешнего интерфейса стали невероятно сложными, часто требующими таких фреймворков, как React. Также стало стандартной практикой отделять внешние и внутренние интерфейсы, чтобы способствовать разъединению и обслуживанию. В этой новой среде Django чаще всего берет на себя роль серверной части. Обычно он действует как конечная точка API (в сочетании с DRF или Graphene) для отдельного внешнего приложения, обычно создаваемого с помощью инфраструктуры JavaScript.
Несмотря на существенные сдвиги в том, как люди обычно используют Django, фреймворк сохраняет все предположения и функции, с которыми он был построен в 2005 году. Шаблоны, на мой взгляд, являются самым большим недостатком, потому что они являются основной функцией Django (а не просто побочной функцией, но основной компонент MVT), хотя они не служат никакой цели в API, что (из моего не безошибочного понимания) является тем, как большинство людей используют Django. Помимо шаблонов, некоторые другие потенциально устаревшие функции включают аутентификацию на основе session, которую, вероятно, следует заменить более безопасной аутентификацией на основе JWT.
Дело в том, что Django начинает показывать свой возраст. Его части, которые когда-то были ядром фреймворка, теперь используются редко. Если расхождение между стандартными практиками веб-разработки и идиоматическим Django продолжит расширяться, фреймворк скоро устареет.
Решение о том, что с этим делать, должны решать Django и более широкое сообщество Python. У каждого будет свое мнение, но я лично считаю, что мы должны подтолкнуть Django к тому, чтобы стать лучше в том, что он уже лучше всего и наиболее предпочитает, а именно в том, чтобы быть мощным фреймворком. Это может означать удаление старых функций, которые больше не играют очевидной роли в создании звездной структуры BACKEND, например, Templates. Это также может означать лучшую поддержку DRF и Graphene (возможно, даже сделать их встроенными частями фреймворка). GraphQL, в частности, нуждается в доработке, потому что он позволяет разрабатывать очень мощные серверные функции и, тем не менее, пока остается в недостаточно развитом состоянии с плохой документацией в мире Python.
При этом я определенно признаю, что шаблоны уже являются неотъемлемой частью очень многих проектов, поэтому этого, скорее всего, не произойдет, и даже если бы это произошло, это разозлило бы многих людей. Также, похоже, есть серьезные разногласия с мнением о том, что разделение fronend / backend части - лучшая идея. Меня всегда учили ценности этого типа дизайна (разделение проблем, чистый код и прочее), поэтому я искренне удивлен, услышав такую критику.
Я думаю, что окончательный / лучший результат, который я хотел бы увидеть, - это новая веб-платформа Python, которая использует лучшие части Django, DRF и Graphene для обеспечения взаимодействия с серверной частью с батарейками без некоторых менее удачных - старые функции стандартные в Django.
Django был разработан в 2005 году (16 лет назад). Его обширный набор функций и подход «с включенными батареями» сделали его чрезвычайно эффективным для быстрой полнофункциональной веб-разработки, что позволило ему стать фаворитом миллионов разработчиков по всему миру. Я сам являюсь одним из этих разработчиков и благодарен Django и всем проектам, которые он позволил мне успешно реализовать.
Тем не менее, 2005 год был давно, и сказать, что с тех пор Интернет сильно изменился, было бы преуменьшением. Требования и ожидания внешнего интерфейса стали невероятно сложными, часто требующими таких фреймворков, как React. Также стало стандартной практикой отделять внешние и внутренние интерфейсы, чтобы способствовать разъединению и обслуживанию. В этой новой среде Django чаще всего берет на себя роль серверной части. Обычно он действует как конечная точка API (в сочетании с DRF или Graphene) для отдельного внешнего приложения, обычно создаваемого с помощью инфраструктуры JavaScript.
Несмотря на существенные сдвиги в том, как люди обычно используют Django, фреймворк сохраняет все предположения и функции, с которыми он был построен в 2005 году. Шаблоны, на мой взгляд, являются самым большим недостатком, потому что они являются основной функцией Django (а не просто побочной функцией, но основной компонент MVT), хотя они не служат никакой цели в API, что (из моего не безошибочного понимания) является тем, как большинство людей используют Django. Помимо шаблонов, некоторые другие потенциально устаревшие функции включают аутентификацию на основе session, которую, вероятно, следует заменить более безопасной аутентификацией на основе JWT.
Дело в том, что Django начинает показывать свой возраст. Его части, которые когда-то были ядром фреймворка, теперь используются редко. Если расхождение между стандартными практиками веб-разработки и идиоматическим Django продолжит расширяться, фреймворк скоро устареет.
Решение о том, что с этим делать, должны решать Django и более широкое сообщество Python. У каждого будет свое мнение, но я лично считаю, что мы должны подтолкнуть Django к тому, чтобы стать лучше в том, что он уже лучше всего и наиболее предпочитает, а именно в том, чтобы быть мощным фреймворком. Это может означать удаление старых функций, которые больше не играют очевидной роли в создании звездной структуры BACKEND, например, Templates. Это также может означать лучшую поддержку DRF и Graphene (возможно, даже сделать их встроенными частями фреймворка). GraphQL, в частности, нуждается в доработке, потому что он позволяет разрабатывать очень мощные серверные функции и, тем не менее, пока остается в недостаточно развитом состоянии с плохой документацией в мире Python.
При этом я определенно признаю, что шаблоны уже являются неотъемлемой частью очень многих проектов, поэтому этого, скорее всего, не произойдет, и даже если бы это произошло, это разозлило бы многих людей. Также, похоже, есть серьезные разногласия с мнением о том, что разделение fronend / backend части - лучшая идея. Меня всегда учили ценности этого типа дизайна (разделение проблем, чистый код и прочее), поэтому я искренне удивлен, услышав такую критику.
Я думаю, что окончательный / лучший результат, который я хотел бы увидеть, - это новая веб-платформа Python, которая использует лучшие части Django, DRF и Graphene для обеспечения взаимодействия с серверной частью с батарейками без некоторых менее удачных - старые функции стандартные в Django.
