"Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных."
Ага, а если нам нужно изменить пользовательские разрешения?
В ВУЗах еще есть такая история, что препод может отбить интерес к предмету. А еще бывают преподы, которых нужно самих учить.Также у них может быть своё предвзятое отношение к чему либо, которое перейдёт на учеников. Самообучение это хорошо если есть должная предрасположенность. Но в первую очередь — теория. Глубокая и пытливая. Потом практика. Долгая и разнообразная. Благо сейчас с доступом к качественным обучающим материалам проблем нет.
"Ключевым параметром эффективности рекламной компании является не клики или конверсии, а доход."
Мне кажется доход это ключевой параметр успешности работы компании. Клиент заинтересовался — реклама сработала. Если дальше что-то пошло не так и пользователь не сделал заказ, это не только проблема эффективности рекламы.
Вставить пароль на сайте
Всё. Зарегистрирован и авторизован.
На этой же странице пользователю предоставляется возможность указать постоянный пароль. Появляется соответствующее поле, которое не обязательно заполнять. Не хочешь придумывать пароль и помнить его — пароль одноразовый на почту. Не хочешь светить свою настоящую почту или каждый раз на неё заходить — указываешь постоянный. Повторюсь там же с формой регистрации! Какие ссылки, какой поиск настроек, какая смена паролей, какое подтверждения? Эээ! Вы о чём? Фантазия такое дело...
Статью, конечно, можно уместить в пару предложений. Или даже в одно. Почему не часто практикуется авторизация по телефону? Лично мне, как потребителю, был бы очень удобен способ с авторизацией по смс. А большинство вышеперечисленных "проблем" не вижу убедительными. Или убедительными на столько, что можно было бы отказаться от такого способа. Особенно: "Не хочу светить свой телефон."
В большинстве магазинов так или иначе прийдется засветить. Для подтверждения заказа, для доставки. Да и можно использовать 3 метода авторизации, кому как удобнее. На выбор: смс, соц.сети, пароль.
Регистрацию можно было бы провести только по смс. А при следующих заходах, заказах можно дополнительно узнать почту, имя и т.д. Возможно смс не часто практикуется из-за дополнительных издержек.
Django надо уметь готовить и уметь проектировать приложения для того чтобы достичь максимальной производительности.
Любой проект нужно уметь проектировать правильно. Только вот как ты не крути, компоненты джанги от этого быстрее не станут, например шаблонизатор, орм… Они тормознутые своей реализацией.
Вот и автор статьи пишет, что отличным вариантом было бы отказаться от ОРМ джанги в пользу иного. Но пришлось решать проблему костылями. А по уму так большинство компонентов джанги следует заменить, ибо уступают аналогичным решениям. И в итоге от неё останется микро-фреймворк с кучей мусора.
Сколько раз не сталкивался с проектами основанными на множестве отдельных компонентов с Flask внутри, все болеют одной и той же проблемой — велосипедостроительством. Как-только проект набирает массу кода, то он начинает превращаться в набор костылей с сложно отлаживаемой логикой.
Что конкретно приходилось велосипедостроить вместе с фласком, но не нужно было c джангой? Если речь идёт не о 5ти строчек кода?
Когда возникает необходимость отклониться от монолитности, универсальности джанги, когда она делает не так как нам надо, когда нам нужно расширить её функционал тут как раз и возникают костыли. Flask и др. предоставляют простоту, гибкость и аккуратность в работе, позволяя пользователю самому выбирать, как реализовать те или иные вещи.
Переписывание проекта на Django спасает проект, и код, в этом случае, получается стандартным, в котором сможет разобраться любой нормальный программист Python.
Да, джанго код стандартен. Пока нам ничего не нужно больше стандартного или немного иного. И разберется в нём джанго программист, а не "лубой нормальный python программист". Нормальный питонист не значит джангист и наоборот. :)
Flask и ему подобные хороши для маленьких проектов с простой бизнес логикой, который разрабатывается командой в 2-3 человека. Где больше трех уже стоит использовать Django.
Чем больше проект, тем больше будет требований по гибкости и нагрузкам. То есть не джанго. CMS -> Django -> Flask и др. -> python
А вообще так спорить можно до бесконечности. Давайте остановимся на этом. :) Каждому своё.
Лопата или экскаватор, результат тот же — яма. В случае с джангой результат разный. Да и сравнение не уместно. Собрать full-stack фреймворк из различных компонентов, реализующих определенный функционал, не намного дольше и сложнее, чем установить, настроить джангу. Но в итоге получаем производительность и возможности.
Может и не уместно, но не могу промолчать. У джанги не только ОРМ медленный, и шаблонизатор, и даже простой json другие фреймворки отдают быстрее. Модульная архитектура быстрее, функциональнее, гибче. Flask, bottle, Jinja2, Babel, Beaker, WTForms и т.д. и т.п. А если без ОРМ совсем никак, то SQLAlchemy. Печально, что в вебе такой язык как питон в первую очередь ассоциируется с джангой. Сугубо ИМХО.
Ну на сервере мы токен не храним. Когда пользователь к нам прийдёт с токеном, откуда мы будем знать что для него нужно выдать новый токен? Из БД?
В статье так и написано.
"Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук."
Хранить md5 нельзя ни с солью, ни без. Это очень быстрый алгоритм. А массу радужных таблиц можно найти далеко не только для md5.
"Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных."
Ага, а если нам нужно изменить пользовательские разрешения?
В ВУЗах еще есть такая история, что препод может отбить интерес к предмету. А еще бывают преподы, которых нужно самих учить.Также у них может быть своё предвзятое отношение к чему либо, которое перейдёт на учеников. Самообучение это хорошо если есть должная предрасположенность. Но в первую очередь — теория. Глубокая и пытливая. Потом практика. Долгая и разнообразная. Благо сейчас с доступом к качественным обучающим материалам проблем нет.
"Ключевым параметром эффективности рекламной компании является не клики или конверсии, а доход."
Мне кажется доход это ключевой параметр успешности работы компании. Клиент заинтересовался — реклама сработала. Если дальше что-то пошло не так и пользователь не сделал заказ, это не только проблема эффективности рекламы.
Например, у меня на сайте 2 профиля:
login1: superman
pass: qwerty
login2: batman
pass: 000000
Я запутался и ввел:
superman
000000
Может я ошибся паролем, а может и логином. Под каким профилем я хотел авторизоваться? Это только я могу знать.
Всё. Зарегистрирован и авторизован.
На этой же странице пользователю предоставляется возможность указать постоянный пароль. Появляется соответствующее поле, которое не обязательно заполнять. Не хочешь придумывать пароль и помнить его — пароль одноразовый на почту. Не хочешь светить свою настоящую почту или каждый раз на неё заходить — указываешь постоянный. Повторюсь там же с формой регистрации! Какие ссылки, какой поиск настроек, какая смена паролей, какое подтверждения? Эээ! Вы о чём? Фантазия такое дело...
РЕГИСТРАЦИЯ
1) Почта:
2) Вам на почту отправлен одноразовый пароль.
Пароль:
3) Ура! Вы зарегистрированы!
Вы можете задать постоянный пароль: (опционально)
АВТОРИЗАЦИЯ
Почта:
Пароль: (постоянный/одноразовый)
[выслать одноразовый пароль на почту]
ПИСЬМО НА ПОЧТЕ
бла бла бла
Ваш одноразовый пароль: F7ae2G8su
Вы можете задать постоянный пароль по [ссылке].
Статью, конечно, можно уместить в пару предложений. Или даже в одно. Почему не часто практикуется авторизация по телефону? Лично мне, как потребителю, был бы очень удобен способ с авторизацией по смс. А большинство вышеперечисленных "проблем" не вижу убедительными. Или убедительными на столько, что можно было бы отказаться от такого способа. Особенно: "Не хочу светить свой телефон."
В большинстве магазинов так или иначе прийдется засветить. Для подтверждения заказа, для доставки. Да и можно использовать 3 метода авторизации, кому как удобнее. На выбор: смс, соц.сети, пароль.
Регистрацию можно было бы провести только по смс. А при следующих заходах, заказах можно дополнительно узнать почту, имя и т.д. Возможно смс не часто практикуется из-за дополнительных издержек.
Любой проект нужно уметь проектировать правильно. Только вот как ты не крути, компоненты джанги от этого быстрее не станут, например шаблонизатор, орм… Они тормознутые своей реализацией.
Вот и автор статьи пишет, что отличным вариантом было бы отказаться от ОРМ джанги в пользу иного. Но пришлось решать проблему костылями. А по уму так большинство компонентов джанги следует заменить, ибо уступают аналогичным решениям. И в итоге от неё останется микро-фреймворк с кучей мусора.
Что конкретно приходилось велосипедостроить вместе с фласком, но не нужно было c джангой? Если речь идёт не о 5ти строчек кода?
Когда возникает необходимость отклониться от монолитности, универсальности джанги, когда она делает не так как нам надо, когда нам нужно расширить её функционал тут как раз и возникают костыли. Flask и др. предоставляют простоту, гибкость и аккуратность в работе, позволяя пользователю самому выбирать, как реализовать те или иные вещи.
Да, джанго код стандартен. Пока нам ничего не нужно больше стандартного или немного иного. И разберется в нём джанго программист, а не "лубой нормальный python программист". Нормальный питонист не значит джангист и наоборот. :)
Чем больше проект, тем больше будет требований по гибкости и нагрузкам. То есть не джанго. CMS -> Django -> Flask и др. -> python
А вообще так спорить можно до бесконечности. Давайте остановимся на этом. :) Каждому своё.
Лопата или экскаватор, результат тот же — яма. В случае с джангой результат разный. Да и сравнение не уместно. Собрать full-stack фреймворк из различных компонентов, реализующих определенный функционал, не намного дольше и сложнее, чем установить, настроить джангу. Но в итоге получаем производительность и возможности.
Может и не уместно, но не могу промолчать. У джанги не только ОРМ медленный, и шаблонизатор, и даже простой json другие фреймворки отдают быстрее. Модульная архитектура быстрее, функциональнее, гибче. Flask, bottle, Jinja2, Babel, Beaker, WTForms и т.д. и т.п. А если без ОРМ совсем никак, то SQLAlchemy. Печально, что в вебе такой язык как питон в первую очередь ассоциируется с джангой. Сугубо ИМХО.