Роман Башарин

Привет!)
--watch есть только у 'vue-cli-service build'
Если вам нужно запустить сборку в development режиме выставьте доп. флаг:
vue-cli-service build --watch --mode development

Уже решили вопрос?
1) На первый вопрос уже ответили
2) Вам решать, стоит ли ограничивать только ими или использовать AJAX + WS. Однократные редкие запросы лучше делать через AJAX. Если клиент открывает одну страницу, и делает постоянно какие-то манипуляции с отправкой на сервер, то можно отдать предпочтение веб-сокетам.
3) Да это уменьшит затраты на переподключения. Основная фишка в том, что сервер сам может инициировать события, без запроса от клиента, в этом главное преимущество. Так же стоит учесть, что языковые конструкции и библиотеки для работы с AJAX и WS различаются как по удобству, так и по количеству, так что стоит смотреть и на удобство разработки.
4) REST, насколько я знаю строится на HTTP, если говорить об идеологии RESTful, то прочитайте про основные принципы, их вроде бы шесть, если вы сможете соблюдать все из них, то не будет иметь особого значения какой протокол лежит в основе.

Есть одно рабочее решение и одно возможно рабочее:
1) livereload.com - Устанавливаем расширение для браузера и десктопное приложение. В случае с сублайм десктопное было не нужно, для него есть самостоятельное расширение livereload которое кстати работает пошустрее, т.к. сам сублайм отправляет запрос браузерному расширению.
В десктопном приложении добавляем интересные для отслеживания папки, открываем сайт и включаем на нём расширение LR, при этом должно быть запущено десктопное. При изменении файлов чем угодно будет идти перезагрузка страницы. Если к отслеживанию добавлены папки с тысячами или десятками тысяч файлов время от изменения до перезагрузки страницы может занимать около секунды, что раздражает.
2) Второе решение (не уверен) через расширение для VS Code https://www.browsersync.io/ но в подробности не вдавался

Скорость исполнения скриптаоколо 0,03с, а 0,27с это было ожидание при работе с БД. Сейчас скрипт на одном диске с БД, в итоге всё вместе с подключением исполняется быстрее чем за 0,1с. Базовый шаблон загружается полностью в браузере примерно за 1с.

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

array(
  'priority0' => 'id345',
  'priority1' => 'id63452',
  'priority2' => 'id23',
  'priority3' => 'id9123'
)

И при изменении приоритета какой-либо из задач мы перезаписываем весь этот массив? С точки зрения лёгкости кода хороший вариант, но массивы будут довольно большие, т.к. в реальной ситуации таблиц несколько, кол-во задач по каждому человеку может доходить до нескольких сотен. Написать легко, но думаю будут проблемы с производительностью. Мне вот интересно, данную задачу ведь решили в той же Asana, да в принципе любом tasktracker-сервисе. Мне кажется что-есть какая-то математическая модель которая данную проблему как раз и решает.
1, 3 ---
2. На словах вариант красив, но пока не понятна реализация в коде. Видимо это должен быть foreach который будет формировать новый упорядоченный массив. При условии, что у нас 500 задач, это будет 500 циклов, пока сложно сказать, каким именно образом будет идти сопоставление, есть некоторые сомнения, что это будет супер быстро. Думаю, насколько это конкурентно по быстродействию с остальными вариантами.

Нашел решение. Пока всё работает исправно.

root       "%hostdir%";
index      index.php index.html index.htm;

location / {
    try_files  $uri $uri/ /index.php?q=$uri&$args;
}

location /lp {
    try_files  $uri $uri/ /lp/index.php?q=$uri&$args;
}

Для тех кому интересно. Примерно в этой директории /usr/local/php7/etc/php-fpm.d
Создал файл с таким содержимым

; Start a new pool named 'www'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('www' here)
[поддомен.myDomain.ru]

user = www-data
group = www-data

listen = 127.0.0.1:ANOTHER_PORT

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

chdir = /

php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f robo@$pool
php_admin_value[error_log] = /var/www/dir1/dir2/temp/errors.log
php_admin_value[mail.log] = /var/www/dir1/dir2/temp/mail.log
php_admin_value[open_basedir]      = /var/www/dir1/:.
php_admin_value[upload_tmp_dir]    = /var/www/dir1/dir2/temp
php_admin_value[session.save_path] = /var/www/dir1/dir2/temp/sessions
php_admin_value[session.gc_probability] = '1'
php_admin_value[session.gc_divisor] = '10'
php_admin_value[session.cookie_domain] = 'поддомен.myDomain.ru'

В общем таким образом можно настроить php "под конкретный" домен/поддомен. Там где указано ANOTHER_PORT нужно указать порт отличный от стандартного (9007) и в настройках nginx (/etc/nginx/conf.d) в напротив "fastcgi_pass" указываете как раз этот порт (за место звездочек) -127.0.0.1:***;

Спасибо за подсказку zapimir. Viewer так и не заработал, выдает js ошибку после ввода доступов к базе, тоже самое про дампер. После ввода данных белый экран. Пробовал в разных браузерах открывать и на локальном хосте и на ВДСке, везде один результат.

Проблему практически решил.
В файле my.cnf внес в раздел [mysqld] следующий код
init_connect='SET collation_connection = utf8_unicode_ci'
init_connect='SET NAMES utf8'
character-set-server=utf8
collation-server=utf8_unicode_ci
skip-character-set-client-handshake

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