Т.е. не валидацию на js, а js должен отправить форму в бакенд, и подставить в поля ошибки, например, если они есть. Вроде не сложно, но какжется что для такой типовой задачи должны быть какие-то готовые штуки.
Возможноисть использование форм исключает не DRF, а то что они расположены в попапе, т.к. надо вадидацию и отправку делать на js. Понятно что можно хоть на ангуляре, хоть на голом js писать, но это будет куча однотипного кода, либо самому писать какое-то универсальное решение. Интересуют готовые библиотеки под эту задачу.
Если не используем pooling устанавливается только одно соединение с базой. Нода не блокируется, но второй ответ не сможем отправить, пока не получим ответ на первый. Если мы хотим чтобы запросы к БД выполнялись параллельно, нужно использовать пул соединений - смотри раздел "Pooling connections". Можешь сам проверить как это все работает выставив задержку на стороне базы например так "select sleep(1), id from mytable limit 1;" и поиграв с количеством соединений в пуле.
Дмитрий Филимонов: нет, вы меня не правильно поняли. Речь не про ORM. Если у вас в приложении требуется писать изощренные запросы с кучей джойнов, подзапросов и прочим, то это все будет работать медленно и плохо, поэтому так лучше вообще не писать. Если в алхимии можно писать запросы, которые в практике использовать вообще не следует, то я бы не стал считать это преимуществом. Это примерно как php позволяет выполнять запросы к БД из шаблонов, но это не значит, что эту возможность следует применять.
Дмитрий Филимонов: если вы пишите сложные запросы, которые Джанга не позволяет, то кажется у вас архитектурные проблемы, которые при нагрузке превратятся в проблемы с производительностью. Что касается Jinja2, во первых вы межете юзать ее с Джангой если хочется. Но я бы не сказал что Jinja2 однозначно лучше джанговских шаблонов. В Джангговских шаблонах легко писать шаблонные теги, и это во-первых очень удобно, во-вторых есть куча готовых библиотек, та же mptt использует их для рендера дерева.
Mikhail: кастомизировать пользователя в Джанге можно уже как несколько лет, и бакэнд авторизации можно написать свой если надо. У меня куча проектов, где используется стандартная адмикна. Для кастомизации бывают пишутся свои виджеты и вьюхи, но в целом проблем не возникает. Пару вьюх своих написать это не всю админку с нуля написать с десятками сущностей. Самому писать очередой CRUD это довольно уныло и утомительно. В большинстве случаем смысла в этом нет.
>Особенно с приходом популярности REST API и мобильных приложений, все эти компоненты Джанги - пыль...
Как будто сайты с приходом мобильных приложений делать перестали ...
А что касается REST API, ты наверно имеешь ввиду модные Single Page Application. Кое-то так конечно сайты делает, но кажется с этим больше проблем, чем профита.
Мне тут ребята рассказывали, как они закостылили редактирование данных через гугл-докс. Это довольно забавно. В их фреймфорке как ты наверно догадался, админки нет.
Это не лень, а здравый смысл и best practices, про DRY не слышал? Выбирать компоненты нужно с умом и порой действительно писать свои, но на фласке выбирать просто не из чего.
структура такая же как у джанговских тестов, какие файлы использовать для тестов можно прописать в pytest.ini по умолчанию там запускаются файлы test_*.py
index0h: статьи интересные, но я не уверен, что все так как там описано. Во первых вставлять синхронный sleep и делать из этого какие-то выводы, довольно сомнительная штука. Во вторых, я попробовал сам. 100 запросов с mysql (каждый из который выполняется 1 секунду) выполняются меньше двух секунд. Если бы они выполнялись последовательно было бы больше 100 секунд. Вот мой тестовый код pastebin.com/vjt1TQM6
yield это хорошо, но это просто генератор. Еще бы в каком-нибудь экспресе через него асинхроность сделали, вот тогда было бы круто. И конечно это ни разу не yield from. Ну и насчет экспреса. В ноде нет полноценных фреймворков. всякие экспресы - совсем простые и низкоуровневые, а типа сэйлз - сырые и глючные.
Блин, я думал хайлоэд. 10к в день хоть на Джумле пиши, тока кеш настрой. С++ тут точно не нужен. Любой язык справится. Асинхронность тут точно не нужна.
