• Почему Python Django 1.8.4 сильно нагружает CP?

    @deliro
    Агрессивное программирование
    1) Ни разу не использовал FileBasedCache, но почти уверен, что его стоит выбросить. Кэш должен быть быстрым, а не чуть быстрее базы (к тому же, конкурировать с базой). Поставь memcached (или Redis)
    2) Поставь nginx вместо апача
    3) Ты статику раздаёшь апачем?
    4)
    Использую WSGI
    это здорово, но очевидно. Что ты используешь в качестве веб-сервера? uWSGI или Gunicorn?

    Мой блог висит на Raspberry Pi первой версии (а это 700 MHz и одно ядро) и выдерживает до 25 запросов в секунду. Я уж не говорю про DO (самый первый тариф за 5 баксов с одним ядром), где ab выдаёт ~140-170 запросов в секунду на более-менее статичных сайтах.
    Ответ написан
  • Как правильно организовать структуру SPA + Backend?

    @wearemieta
    BEWARE HIPSTERS
    Но бесит, что там нет единого собранного файла bundle.js

    В шаблоне webpack-simple все скрипты собираются как раз в один файл build.js. Обратите внимание, он подключается в сгенерированный index.html. vuejs-templates/webpack-simple.

    Этот файл недоступен в файловой системе при запуске dev сервера, потому что в режиме разработки он находится исключительно в памяти.

    так он еще создает кучи других непонятных файлов и при режиме разработки запускает ненужный 'hot-load'.


    Давайте разберемся, для чего нужен сервер в режиме разработки для Vue. При написания SPA приложения вы используете кучу библиотек, файлов в разных форматах и возможно еще обращаетесь к стороннему API(например twitter). Плюсом, вам хотелось бы использовать транспайлер, чтобы в js можно было красиво писать стрелочные функции и использовать другие вкусняшки ES2015. А еще это здорово было бы склеивать файлы одного формата в один большой для разных оптимизаций. Плюс, после того как вы измените что-то в одном файле, не пришлось бы тыкать каждый раз на перезагрузку страницы. Примерно эти вещи делает за вас dev сервер с webpack в режиме разработки.

    — с помощью webpack вы можете собирать ваши файлы каким угодно образом и складывать их в любое удобное место в фс.
    — вы можете их склеивать, минифицировать и использовать транспайлеры, препроцессоры, постпроцессоры и прочее.
    — вы можете обращаться к стороннему API с локалхоста.
    — если вам не нужен hot-load — отключите его в конфиге.

    Оставить в покое django под портом :8000, а VueJS под :8080. И в nginx как-то слушать их обоих, раздельно, таким образом четко разделить фронт от бэка. Не будет ли проблем?


    Проблем с проксированием nginx'ом? Не очень понятно что вы имеете в виду.

    Если вам нужен кастомный шаблон vue-cli то вы можете легко его разработать один раз и в дальнейшем использовать: Vue-cli custom templates

    Как правильно организовать структуру SPA + Backend

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

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

    Эта парадигма оправдана в определенных случаях, как и другие парадигмы.

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

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

    Ваше приложение схематически выглядит так:

    Клиент: хочу авторизоваться => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные для авторизации) => База данных: можно => Клиент: я авторизован

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

    Теперь, в вашем фронтенде на Vue, например, вы можете отображать нужные вам данные (а соотв. делать запросы в основную базу), только если пользователь авторизован.

    Теперь ваше приложение выглядит так:

    Клиент: хочу авторизоваться => Фронтенд-микросервис: отправляю микросервису авторизации => Микросервис авторизации: можно => Фронтенд-микросервис: я авторизован, хочу данные => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные отображения авторизованному клиенту) => База данных: данные => Клиент: я получил данные

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

    Авторизация? — микросервис — auth0.com
    SQL База данных? — микросервис — Google CLOUD SQL
    Уменьшаем размер картинок? — микросервис — AWS Lambda

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

    Конечно, это решает определенные проблемы, но и создает новые, поэтому, повторюсь, все зависит от ваших задач.

    Давайте посмотрим на ваш пример с Django. Если я все правильно понимаю, то вы хотите использовать все плюсы Django, типа ORM, API доступа к БД, etc, заменив лишь систему шаблонов на Vue?

    В таком случае, на мой взгляд, вам нужно реализовать на Django классический REST API и из SPA на Vue обращаться к endpoint'ам вашего API.

    Ссылки по теме:
    Архитектура микросервисов
    SPA-архитектура для CRM-систем: часть 1
    SPA-архитектура для CRM-систем: часть 2
    AWS Lambda и никаких серверов
    Ответ написан
  • Кто-то использовал prefix_default_language=False для удаления префикса языка?

    @javedimka
    Хочу сока
    У Джанго есть багтрекер ->
    https://code.djangoproject.com
    В форму поиска, prefix_default_language ->
    https://code.djangoproject.com/search?q=prefix_def...
    Можно приступать к изучению возможных проблем.
    Ответ написан
  • Upwork как правильно получить первого клиента?

    search
    @search
    мама говорит что я особенный
    Как исполнитель, заработавший больше 100К$ (PHP, JS) на апворке и как заказчик, потративший больше 300K$ (тоже PHP и JS), скажу, что cover letter - это 90% успеха.

    Cover letter в стиле "быстро, дёшево, качественно" - сразу отправляются в топку. Когда фрилансил, то 10 из 10 заказчиков мне отвечали и почти всегда нанимали. Просто потому что в cover letter я сразу рассказывал как буду решать их задачу и задавал дополнительные вопросы по проекту. Когда нанимал сам, то хороший cover letter, где рассказывали что будут делать и задавали правильные вопросы, я получал, примерно один раз из 20 в случае с бэкендом (PHP) и ни разу за всю практику в случае с фронтендом (JS). Вообще грамотных фронтендеров на апворке я нашел ровно 0 (предлагая 35$ в час за ПОСТОЯННУЮ неограниченную работу), поэтому пришлось отказаться от услуг фриланса.

    Еще. Мелочиться не стоит. Я обычно отфильтровывал тех кто просил меньше чем я готов дать. Потому что просто не было времени искать алмаз среди низкокачественных специалистов, у которых низкая стоимость - главный козырь.

    Такие дела
    Ответ написан
  • Best practies? Две независимые модели для пользователя и админа, Django 1.11.x?

    @immaculate
    Программист-путешественник
    Я не раз видел попытки такого разделения пользователей по классам в проектах на Django. Не знаю, почему все сразу выбирают такое решение, которое в перспективе не приносит ничего, кроме боли.

    Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

    Разделение на две разных модели никаких абсолютно преимуществ не дает, кроме тонны мусорного кода и головняков с поддержкой данной гидры.

    TLDR:
    1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
    2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.
    Ответ написан
  • Как отобразить список категорий и связаных товаров на одной странице?

    @AlexandrBirukov
    {% for category in categorys %}
    {{ category }}
    {% for book in category.category_book.all %}
    {{ book }}
    {% endfor %}
    {% endfor %}

    Это в шаблоне, а во вьюхе:

    model = Category
    context_object_name = 'categorys'
    Ответ написан