Yeldos Adetbekov

Если верить nslookup, то IP адрес с вашего скрина не совпадает с данными из DNS => что сайт открывается не с вашего сервера => там левый ssl сертификат

# nslookup portal.tggroup.kz
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   portal.tggroup.kz
Address: 178.62.251.156

О боги, этот человек на днях допытывал народ о Server-rendering. Хорошо что внял совету и пошел учить основы)))

Это dev сервер, предназначенный для разработки. Когда соберешь проект, можешь размещать его где угодно.

Но бесит, что там нет единого собранного файла 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 и никаких серверов

Напишу свои мысли:

У ваc скорее всего уже используется vuex для хранения состояния. Если нет, то стоит начать.

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

Разобрался, правильный компонент такой:

Vue.component('b-router-link', {
  template: '<li class="nav-item"><router-link :to="to" class="nav-link"><slot/></router-link></li>',
  props: ['to']
})

использование:

<b-router-link to="/phones">Телефоны</b-router-link>

Перевод в isoformat имеете в виду?

>>> import datetime
>>> now = datetime.datetime.now()
>>> now
datetime.datetime(2017, 4, 11, 11, 40, 51, 361335)
>>> now.isoformat()
'2017-04-11T11:40:51.361335'

Для того чтобы строку закодировать

>>> import urllib
>>> urllib.urlencode({'start_gte': now.isoformat()})
'start_gte=2017-04-11T11%3A40%3A51.361335'

Content-Disposition: attachment; filename="filename.ext"

Vue предполагает, что вы в скриптах используете CamelCase для названий компонентов, а в самой разметке (шаблонах) - именование-через-дефис:

<div id="root">
	<task-list></task-list>
</div>

Я проапдейтил с webpack 1 по гайду за пару часов.

По поводу SEO, Vue умеет рендеринг на стороне сервера https://ru.vuejs.org/v2/guide/ssr.html и всё будет индексироваться. По остальному не подскажу, сам недавно начал работать с ним

https://jsfiddle.net/dcwshwyv/

<a href="#" class="buy">
<p>Buy</p>
</a>

.buy {
    /* ... */
    display: block;
    text-decoration: none;
}