между которыми нужно настроить сложную интеграцию. Классическая реализация подразумевает бекенд, который крутится на сервере (пусть будет nodejs) и морда админки, которая крутится в браузере (пусть будет vue).
Мой извращенный замысел — написать всю реализацию на vue и запускать его на сервере, управлять через RDP.
Плюсы
— Сложные процессы легко наглядно разбить на компоненты
— Веб-интерфейс не нужно делать — он уже подразумевается
— Запускать руками какие-то обработки и следить за статусами можно прямо отсюда. В классической реализации нужно написать много-премного лишнего кода
— Код не нужно делить на фронт/бек
— Нет разделения ответственности, весь функционал в одном месте
Минусы
— Поведение браузеров (неактивные вкладки засыпают)
— Нет прямого доступа к БДшкам из браузерных библиотек, которые можно заюзать во вью
— … накидайте ещё
Почему?
Потому что для реализации такого обмена по сути из действительно работающего кода нужно написать пару десятков методов а потом ещё пару сотен, чтобы отдавать наружу полный контроль над приложением, реализовать всё то же на фронте и обеспечивать их связь.
Прошу тех кто считает что идея идиотская — высказываться аргументированно) То, что так никто не делает и для всего свои инструменты — знаю)
я свой текущий проект начал так делать
Серьёзно? Можно подробнее?
Плохо понял идею. Что такое "реализацию на vue и запускать его на сервере"? Если эта реализация будет в виде ВЕБ приложения, то она всё равно будет в браузере. тогда какая разница, этот браузер на той же машине, что сервер, или на удалённой от него.
какие подробности? на одном порту сервак, на вроторм фронт, сервак отправляет заголовок Access-Control-Allow-Origin выставленный в *
Оверинжиниринг, особенно RDP. Достаточно сервис в шифрованнй канал при необходимости. А админку можно запускать даже с локального файла index.html. Общение через API.
Вот подготовка API для всего подряд для моего проекта и есть оверинжиниринг по сути)
Обсуждают сегодня