Андрей

В основном бандле (ну или манифесте) всё равно будут зашиты пути к чанкам, чтобы клиент знал, откуда их ему качать, когда понадобится. "Злоумышленник" точно так же может их найти.

Проблему надо решать с другой стороны: взаимодействие с непубличными эндпойнтами должно быть закрыто авторизацией или какими-то ключами доступа.

Вебсокеты, как и http - это протокол без состояния. То есть, после перезагрузки страницы, сервер не знает, вы это или нет.
Поэтому после подключения к вебсокетам, вам нужно отправить на сервер какой-то идентификатор, например свой id.
На сервере хранить соединения и данные о пользователях. Когда нужно будет отправить сообщение, найдете на сервере нужное соединение и отправите в него данные.

Вот тут хороший пример простого чата на вебсокетах. Без socketio, но сути это не меняет. Автор сохраняет всех клиентов в массив и работает с этим массивом.

1) 50-60k вполне реально получать со старта в Мск, при условии, что ты уже что-то можешь сделать, это не обязательно должен быть опыт разработки в продакшене. Проси тестовое.
3) Испытательный срок максимум 3 мес., но может быть и меньше, как себя покажешь
4) Сильно зависит от конкретной компании. Естественно после успешного прохождения испытательного срока, а потом это может быть полгода-год

Разобрался. Всё достаточно просто.
Я включил авторизацию на сервер по паролю, после чего сбросил пару ключей, которую генерировал при создании дроплета с помощью PuTTY по мануалу от digitalocean, после чего сгенерировал новые ключи по другому мануалу от них же, более простым и адекватным способом. Отправил их, как написано в мануале, на сервер, авторизовавшись по паролю. Теперь подключение к серверу и репозиторию через SSH проходит успешно.
Главное, о чем я ранее не догадался, ключи должны храниться в C:\Users\user\.ssh
Теперь можно отключить авторизацию по паролю.

Мы делали крупные проекты с vue, но это не было полноценным spa и не микросервисная архитектура. У нас просто было несколько entry, которые мы использовали для разных разделов.

Мое мнение, если никто из вас раньше не имел дело с микросервисами, то с ходу не беритесь. Угрохаете кучу времени просто на один каркас и не факт, что все будет работать хорошо с точки зрения надежности и безопасности.

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

На мой взгляд, самый главный плюс микросервисов в том, что уменьшается стоимость ошибки решения по архитектуре (микросервиса), ибо его легче переписать, чем править и рефакторить. Ну и еще хорошо, что обновлять можно частями, не пересобирать сразу все при каждой выкладке. В монолите, чем дальше, тем сложнее то-то глобально изменить и очень важно на начальном этапе не ошибиться.

Безболезненно переписать модуль на vue проблем нет при любых раскладах. Только если не решите на ангуляр перейти, тут я сомневаюсь, что его можно точечно использовать в проекте. У нас как то был большой легаси проект, монолит, который был на jq, мы сначала решили добавить knockout, нам не понравилось, дальше продолжали на vue.

Они нужны для:

• Реализации криптографических алгоритмов
• Реализации любых других алгоритмов требующих работу с битами
• Чтобы пользователи языка не изобретали велосипеды

Понимаете, это ведь не особенность языка - это скорее особенность наших процессоров,принципов вычислений, ассемблера. Раз уж эти операции существуют, причем именно в том виде в каком к ним привыкли то логично предположить что многие программы и алгоритмы рассчитывают на их наличие в инструментарии разработчика. Представьте что вам пришлось бы портировать некий криптографический алгоритм использующий эти операторы на js в котором их не было бы. Допустим вы реализуете его умножая/деля на два, но затем обнаруживаете, что при умножении старший бит у вас исчезает, а должен становится самый младшим. Кроме того ваша реализация на js была бы много медленней чем встроенная в язык реализация.

Глобальное подключение переменных и миксинов можно настроить в конфиге

css: {
    loaderOptions: {
        sass: {
            data: `@import "@/styles/config/env-production.scss";`,
        },
    },
},

все тоже самое, только вычитай минимальное значение,

0px = 150
300px = 50

отрезок в 1px = x = 300px/(150-50)

точка 75 равна:
300px - ((75 - 50) * х) = 225px

точка 50 равна:
300px - ((50 - 50) * х) = 300px

точка 150 равна:
300px - ((150 - 50) * х) = 0px

https://ru.vuejs.org/v2/guide/components.html#Расп...

phoneString = '+7-(777)-77-77-777';
phoneString.replace(/\D/g, '');

Проверка простая:
1. Все стандарты соблюдены?
2. Валидация проходит?
3. Кросс-браузерно (включая мобильные клиенты) отображается везде корректно?
4. Оптимизация производительности кода - максимальная?
5. Работать с кодом/разметкой (при добавлении функционала) - удобно?
Вы - НЕ больны 100% !

PS: валидация вёрстки (и не только): тут