Выбор архитектуры: web или desktop?
Добрый день!
Разрабатываю сервер для работы с оборудованием к которому будут подключаться пользователи (физически подключать свой ноут к серверу, не через инет). Встал вопрос выбора типа сервера: web-сервер к которым пользователи будут работать через браузер или сервер к которому будут подключаться через десктопное приложение.
Подскажите, пожалуйста, на какие критерии ориентироваться при выборе? Есть ли какая-либо литература для понимания этих критериев?
upd1: Система предназначена для обработки деталей. Сервер передаёт пользователю видео с видеокамер на которых отображается деталь. Пользователь щёлкая по изображению детали запускает процесс её обработки оборудованием. То есть, будет потоковое видео и его обработка, других вычислений не будет.
Работа через Интернет не предполагается т.к. нужно физическое присутствие человека в процессе обработки детали (установки детали в зажимы и т.п.). То есть достаточно простого подключение по локальной сети (без аутентификации и т.п.)
Дополнительно:
Что должна делать программа с оборудованием?
Какой объем трафика между оборудованием и программой предполагается?
Будут ли в программе какие-то тяжелые вычисления на основании данных, полученных от оборудования?
физически подключать ноут к серверу это как? Если вас интересует веб, то, видимо, физически предполагается подключать в ту же сеть, где находится ваш сервер. Сеть это может быть и ВайФай, а там никакого физического подключения нет. Если есть сеть, то почему тогда интернет отметается сразу? Большая часть программ, работающих по локальной сети, будут нормально работать и через интернет. Некоторым надо создать тепличные условия, например ВПН.
Работа через Интернет не предполагается т.к. нужно физическое присутствие человека в процессе обработки детали (установки детали в зажимы и т.п.). То есть достаточно простого подключение по локальной сети (без аутентификации и т.п.)
Пользователь щёлкая по изображению детали запускает процесс её обработки оборудованием.
если положение камеры фиксировано то значит ли это что позиция деталий на экране будет постоянной а значит суть программы - показывать фоном видео с камер и отсылка нажатий на место нажатия, а на сервере (или сразу на клиенте) забиты списки зон и соответствующие им команды запуска нужной фазы обработки?
в данном случае веб идеален, поддержка проигрывания видео (особенно не привязываясь к его формату, точнее поддержка большинства популярных), полупрозрачные накладываемые поверх изображения и сетевая коммуникация.
да, то же самое можно сваять за пару дней на том же .net в visual studio, паод вопросом будет только проигрывание видео, список поддерживаемых форматов будет определять наличие кодеков в операционной системе.
если положение камеры фиксировано то значит ли это что позиция деталий на экране будет постоянной а значит суть программы - показывать фоном видео с камер и отсылка нажатий на место нажатия, а на сервере (или сразу на клиенте) забиты списки зон и соответствующие им команды запуска нужной фазы обработки?
Да, всё так.
в данном случае веб идеален, поддержка проигрывания видео (особенно не привязываясь к его формату, точнее поддержка большинства популярных), полупрозрачные накладываемые поверх изображения и сетевая коммуникация.
да, то же самое можно сваять за пару дней на том же .net в visual studio, паод вопросом будет только проигрывание видео, список поддерживаемых форматов будет определять наличие кодеков в операционной системе.
Спасибо большое!
да, то же самое можно сваять за пару дней на том же .net в visual studio, паод вопросом будет только проигрывание видео,
А что, вообще, можно "сваять" за пару дней? Макет пользовательского интерфейса и готовый к использованию продукт - не одно и то же.
Ответы:
Web - на два порядка проще (читай дешевле) для разработки за счет повышенного требования ресурсов на клиентской стороне.
Десктоп - возможно создание очень эффективных приложений но за счет очень дорогой поддержки всего разнообразия устройств и операционных систем (в веб этим занимается браузер и даже в этом случае приходится напрягаться)
И главное, из веб приложения достаточно легко (например с помощью electron) можно сделать десктопное приложение.
p.s. как бы я не нелюбил веб, который тянут даже туда где не надо, но его плюсы неоспоримы а страдающие клиенты от тормозов приложений, требующих топовое железо для простого чата... кто нас слушает?
Кстати, один момент, тормозные веб приложения это не потому что веб такой плохой, это потому что разработчики ленятся делать все как следует. Рынок заполонили низкокачественные разработчики на основе веб. Помни об этом!
веб проще и эффективнее всего остального
но всё зависит от того какие языки ты знаешь
если делать с нуля и надо изучать языки - веб лучший вариант
потому что раз в 100 проще всего остального
в 10 раз проще обычного
и в 100 раз проще если использовать небольшое подмножество языков js css html php
web-сервер от "не веб" отличается только умением работать через протокол Http
Фактически это и есть обычный сервер, только протокол связи стандартизован, так чтобы с ним умел общаться браузер. Но точно так же с ним может общаться любой другой клиент.
То есть выбор стоит так "использовать мне стандартный протокол или нестандартный". И тут сами выбираете.
Сервер передаёт пользователю видео с видеокамер на которых отображается деталь. Пользователь щёлкая по изображению детали запускает процесс её обработки оборудованием. То есть, будет потоковое видео, тяжёлых вычислений не будет.
Тут в веб тоже есть стандарт - WebRTC, но не слишком удобный, смотрите уже с чем клиент умеет работать.
-
То есть выбор стоит так "использовать мне стандартный протокол или нестандартный".
при использовании desktop решения никто не запрещает программе общаться с сервером по тому же http протоколу. так что выбор состоит не в этом.
- Сергей delphinpro, совершенно верно, и выбор как раз в этом
Есть много вопросов к тому что из себя будет представлять конечный программно-аппаратный комплекс и для каких условий работы он предназначен. Одно дело, когда он расположен где-то в "тепличных" условиях в офисе/дома. И совсем другое дело, когда находится в шумном и пыльном цехе, где по кнопкам и экрану будут тыкать грязными руками. Ко второму должны предъявляться совсем другого уровня требования по надежности и не только.
физически подключать свой ноут к серверу
В смысле? Пойдут в серверную и будут подключать ноут к серверу кабелем? Что за бред? Если не бред, то по какому протоколу? И этот ноутбук нужен для постоянной работы с оборудованием? Или "сервером" будет достаточно мощный ПК? ПК и ноутбук в цехе? Серьёзно?
с видеокамер на которых отображается деталь
Это видеокамеры со встроенными экранами? Или же без, а изображение должно передаваться по кабелю на сервер?
будет потоковое видео и его обработка
К потоковой обработке видео, я полагаю, есть достаточно высокие требования и к железу и к коммуникациям (ширина канала, задержки, кабели, маршрутизаторы и т.д.). Должен быть чип DSP (если встраиваемое оборудование) или достаточно мощный процессор на ПК/сервере, который потянет обработку.
web или desktop
Десктоп - настольное оборудование, web - передача данных преимущественно по HTTP. Одно другому не мешает. Наверное, речь больше про выбор клиент-серверной технологии, таких как терминал-сервера с терминал-клиентами (Citrix и др.) или же комбинированного оборудования с периферией (допустим, ПК с подключеннами экраном, веб-камерой и другими устройствами). Из-за необходимости обработки видео терминал-сервер, похоже, не подходит.
Если, скажем, брать (промышленный) вариант ПК, тогда обработка видео будет происходить на нём и по сети гонять ничего не надо. Тогда настольное приложение может состоять из модулей обработки видео, бизнес-логики и пользовательского интерфейса - всё в одном. Для настольных приложений обычно берут C# (WPF), C++ (Qt), Delphi, Java (Swing, JavaFX). Модуль обработки видео можно использовать, подключив как библиотеку (SO, DLL), реализованную на любом высокопроизводительном ЯП.
Веб-технологии пока достаточно специфичны и ограничены. У меня нет пока представления как происходит пакетная обработка видео в вебе. WASM едва только пробует войти в веб и мало распространён. Одно дело на веб-приложении крутить фильмы, а нечто другое - обрабатывать на лету и встроить в пользовательский интерфейс. Так что к настольным веб-приложениям я пока несколько скептически отношусь. Они пока не предназначены для промышленного использования.
Я бы тут ещё попробовал ответить на следующие вопросы:
- Какие требования к срокам выпуска приложения?
- Как часто будет меняться приложение?
- Какой перечень клиентского оборудования и операционных систем? Будут ли это планшеты на iOs, например. Если только ноуты с одинаковой операционкой — то почему?
- Какая интеграция с десктопом потребуется? Например, запуск в режиме киоска (без элементов операционной системы), горячие клавиши, локальная БД, интенсивные вычисления, лимиты памяти, нестандартные элементы управления (джойстики и т.п.), внешние динамики/мигалки/дисплеи, контроль активности пользователя.
- Много ли экранных форм и насколько они разнообразны?
- Какой опыт у разработчи(ка/ков)
Суть в том, что для работы с оборудованием, например, комфортнее десктоп (хотя и с веб это возможно). Для некоторых типов приложений мне, например, быстрее также использовать десктоп, потому что есть библиотеки, с которыми я могу простое готовое приложение сделать за часы (с валидацией и т.п.). С юнит-тестами в той среде, в которой с работаю (.Net) проще с десктопным кодом, чем с JS. Но веб, по понятным причинам, убирает многие границы (разные операционки, доставка приложения и т.п.). Опять же веб подразумевает серверную часть. В ряде случаев это подразумевает два языка программирования, две валидации ввода, две обработки ошибок.
В общем, простой ответ дать по описанию только предметной области не получится. Возможно, все ответы вместе дадут намек на решение.
Удачи!
Есть много вопросов к тому что из себя будет представлять конечный программно-аппаратный комплекс
Архитекутра достаточно простая: видеокамера передаёт видео детали на сервер (мощный комп с видеограббером). Сервер анализирует поток, корректирует его и транслирует клиенту. Клиент щёлкает по выбранной части изображения детали и аппаратура для работы с деталью производит операцию.
для каких условий работы он предназначен. Одно дело, когда он расположен где-то в "тепличных" условиях в офисе/дома. И совсем другое дело, когда находится в шумном и пыльном цехе, где по кнопкам и экрану будут тыкать грязными руками.
Весь комплекс (включая сервер) будет использоваться только в "тепличных" условиях, для исследовательских целей.
В смысле? Пойдут в серверную и будут подключать ноут к серверу кабелем? Что за бред? Если не бред, то по какому протоколу? И этот ноутбук нужен для постоянной работы с оборудованием? Или "сервером" будет достаточно мощный ПК? ПК и ноутбук в цехе? Серьёзно?
Сервер не будет находиться в серверной. С комплексом можно работать только находясь с ним рядом (т.к. надо будет устанавливать деталь). Многопользовательский и удалённый доступ к нему не нужны. Конечные пользователи будут подключаться с ноутбука пачкордом по Ethernet.
Наверное, речь больше про выбор клиент-серверной технологии, таких как терминал-сервера с терминал-клиентами (Citrix и др.) или же комбинированного оборудования с периферией (допустим, ПК с подключеннами экраном, веб-камерой и другими устройствами). Из-за необходимости обработки видео терминал-сервер, похоже, не подходит.
Если, скажем, брать (промышленный) вариант ПК, тогда обработка видео будет происходить на нём и по сети гонять ничего не надо. Тогда настольное приложение может состоять из модулей обработки видео, бизнес-логики и пользовательского интерфейса - всё в одном.
Необходимо выбрать как предоставлять доступ конечным пользователям - писать клиентское приложение (C++/Qt) или предосталять его через web. Можно бы производить доступ сразу на серверном ПК, но заказчик не хочет по ряду причин.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Выбор архитектуры (web или desktop) зависит от конкретных потребностей и задач проекта. Обе архитектуры имеют свои преимущества и недостатки, поэтому перед принятием решения необходимо проанализировать ряд факторов.
Web-архитектура подходит для проектов, которым требуется доступ из любого места и с любого устройства, так как веб-приложения работают через браузер. Они также обеспечивают легкость обновлений и масштабируемость. Однако веб-приложения могут иметь проблемы с производительностью и доступом к некоторым функциям устройства, таким как камера или датчики.
Desktop-архитектура, напротив, работает на устройстве пользователя и обеспечивает полный доступ к ресурсам устройства. Это может быть полезно для проектов, требующих высокой производительности или работы в оффлайн-режиме. Однако такие приложения требуют установки на каждом устройстве и обновления могут быть сложными.
При выборе архитектуры необходимо учитывать такие факторы как бюджет проекта, требования к производительности, безопасности, масштабируемости, доступности и удобству использования для конечных пользователей. Также стоит учитывать опыт разработчиков и возможность поддержки и обновлений в будущем.
Наконец, важно помнить, что не всегда необходимо делать жесткий выбор между web и desktop архитектурами. Можно также использовать комбинированный подход, например, разработав web-приложение с возможностью установки на устройство пользователя.
Выбор между веб- и десктоп-архитектурой зависит от конкретного проекта, его целей, требований и аудитории. Обе архитектуры имеют свои преимущества и недостатки, поэтому необходимо внимательно взвесить все аспекты перед принятием окончательного решения.
Веб-архитектура предлагает доступность приложения из любой точки мира, что делает его удобным для работы удаленных сотрудников и пользователей. Благодаря веб-интерфейсу приложение может быть запущено на любом устройстве с доступом в Интернет, что увеличивает его универсальность. Кроме того, веб-приложения легче масштабировать и обновлять, так как изменения вносятся на серверной стороне.
Однако веб-приложения могут столкнуться с проблемами производительности из-за зависимости от скорости Интернет-соединения. Также веб-приложения не могут полностью использовать возможности операционной системы, что может быть ограничивающим фактором для некоторых проектов.
Десктоп-архитектура, с другой стороны, предлагает более высокую производительность и возможность полного использования ресурсов операционной системы. Десктоп-приложения могут работать оффлайн и обеспечивать более богатый пользовательский интерфейс.
Однако десктоп-приложения требуют установки на каждом устройстве, что может быть неудобным для пользователей. Также обновление программы может потребовать повторной установки, что может быть затратным и неудобным процессом.
В итоге, выбор между веб- и десктоп-архитектурой должен быть обоснованным и основан на требованиях проекта. Необходимо учитывать потребности пользователей, цели проекта, доступные ресурсы и другие факторы перед принятием окончательного решения.