Архитектура софта: веб-сервис, тонкий или толстый клиент, что лучше? : Операционные системы и программное обеспечение

Ты почитай все же с начала темы... FinSoft настаивает, что все это как раз несоизмеримо больше.
А это вообще ты просто жертва моды и ничего не понимаешь, работает и зарабатывает - значит хороший продукт.

Если оставить ядром тот же десктопный софт, и пытаться прикрутить к нему вэб морду, то, возможно, он и прав - придётся, ведь, поддерживать и обновлять, по сути, два софта, и штат сотрудников держать удвоенный.

Будущего у такого продукта нет. Когда бабушки и дедушки, которые его используют, уйдут на пенсию, денежный ручеёк иссякнет.

Я приведу конкретный пример из практики. Есть система электронных заказов для оптовиков и производственников. Это типа навороченного интернет магазина, но с другой заточкой функционала. Вначале клиент заказал интернет магазин в веб студии. У меня такого решения на тот момент не было, решили, что проще заказать на стороне и интегрировать с учетной системой. Это работало определенное время в базовом функционале. Денег студии заплатили так прилично. Потом подумали, решили сделать настольное приложение для крупных покупателей, у которых накладные под сотню строк. Быстро собрал, показал, клиенту понравилось, запустили в работу. Еще через некоторое время был разработан так называемый веб модуль. Написан на php, данные хранятся в sqlite, скрипт на хостинге крутится в практически необслуживаемом режиме. Действительно, для данного функционала применение веб технологий легло как сыр на масло. Закидываем на хостинг php-файлики, настраиваем утилиту для обмена по расписанию. Всякую аналитику, различные автоматически рассылки делаются в учетной системе. Хотя настольное приложение нравилось пользователям и скорость подготовки заказов была существенно выше, чем в вебе, я сознательно не стал активно предлагать новым пользователям. Оставили только у самых крупных. Соотношение у этого клиента было примерно 10 контрагентов работали на настольной системе, около 290 в веб модуле. Это уникальные контрагенты, присылавшие от одного до нескольких заказов в месяц. Всего контрагентов было около 450. С настольным приложением поддерживать было сложнее, так как то антивирус или брэндмауэр мог заблокировать, то какие-то айтишники накосячить. С вебом намного проще в плане поддержки. Но не лучше для пользователей (время работы над заказами увеличилось). И надо отметить, что выполняемый веб модулем функционал это крошечка функционала учетной системы.

Если речь идет про разработку большой учетной системы, то тут другая картина. И разработка в вебе не просто дороже, а намного дороже, чем разработка настольных систем. Вначале только надо уточнить, что речь не идет о клиент-серверных системах, в которых логика пишется на скриптах. При терминальном доступе клиент-сервер нужен только когда один терминальный сервер не справляется с нагрузкой, и надо поднимать ферму. А это где-то более 50 конкурентных пользователей на простом железе, на современных серверах затрудняюсь сказать, там сейчас характеристики какие-то нереальные. Я не просто говорю, что настольные учетные системы разрабатывать проще и дешевле, уже писал, по каким причинам.
1. Это наличие компилятора, преобразующего текст программы в машинный код, в результате чего сразу выполняется глубокая верификация кода, не доводя до конечных пользователей. Самые навороченные интерпретаторы скриптов, преобразующие текст в байт код, такой проверки не обеспечивают. Поэтому для компилированных настольных учетных систем юнит тестирование, как таковое, не является критичным. Не надо писать программы, которые проверяют работу другой программы. Точнее, определенные юнит тесты тоже делаем, но нагрузка на них несопоставима.
2. Строгая типизация данных. Если почитать людей, которые разрабатывают большие системы (в плане функционала), все в один голос подтверждают важность этого дела, позволяющего существенно минимизировать трудно находимые ошибки. MS для веба даже озаботилось и придумало true script - язык со строгой типизацией, которые затем транслируется в javascript. Но, насколько я знаю, широкого распространения язык не получил, видимо из-за того, что львиная доля веб приложений реализуют очень простой функционал.
3. Программирование в вебе это, как правило, смесь нескольких скриптовых языков - html, css, javascript и часто php. Какие бы генератора и фреймворки не придумывали, все равно к коду приходится обращаться. Такая смесь сложна для восприятия по объективным причинам, а значит, повышается вероятность ошибиться. Большие фреймворки для упрощения разработки хорошо работают на простых задачах, но шаг в сторону, надо представлять, как оно работает внутри. А для этого уровня простого автоматизатора недостаточно. У него основные знания в предметной области, а программирование вторично. Получаем команду с разделением на прикладников, кодировщиков и тестировщиков. Между ними появляются накладные расходы на согласования. Понятно, что стоимость и время разработки вырастает, и вырастает значительно.
4. Работа в броузере строится вокруг многоуровневого дерева, на ветках которого располагаются блоки html контента. Javascrip манипулирует деревом. Работа с многоуровневыми деревьями объективно сложна на восприятие, часто может потребовать рекурсии и т.п. В настольных приложениях обычно обходятся реляционными структурами, что проще и надежнее.
Я не знаю, за счет чего можно выжать производительность разработки в вебе. Хороший фреймворк для настольных систем позволяет писать минимум кода. И, как правило, этот код оприори выходит отлаженным. Возможно, я что-то непонятное пишу для тех, кто не знаком с настольными фреймворками, автоматической регенерацией кода и т.п. Ну, тут книгу писать можно, в одном посте не охватишь.

К минусам веб приложений можно отнести, кроме высокой стоимости разработки, гораздо большее время отклика (производительность работы падает по сравнению с настольными приложениями), менее функциональный интерфейс (не путать с оформительскими возможностями, которые в вебе развиты больше), вопросы безопасности, требующие постоянно обновлять сопутствующее ПО.

С другой стороны вопрос, а что не так с терминальным доступом? Работает быстро, даже через интернет информация на экране обновляется быстрее, чем в вебе. Во всяком случае, я такое наблюдаю. Работать можно с любого устройства и с любой точки мира. Хорошо обкатанные технологии, которыми пользуется огромное количество людей. При желании, можно и в веб броузере работать. Сложнее поддерживать небольшие приложения, это факт. Речь не про них, такие как раз и надо выносить в веб. Если терминальными системами пользуются миллионы людей здесь и сейчас, то называть это легаси, ну, как-то предвзято выглядит.

В общем, как-то так. Я не написал ничего нового, просто подтвердил то, что достаточно часто и другие пишут. Ничего военного и необычного тут нет.

Если кому-то интересно, могу показать, как работает фреймворк для настольных приложений. Может, я действительно на своей волне, а дети интернета не представляют, о чем речь.

Кстати, маэстро без проблем вписывается в облачные технологии. Он же написал, что поднимет на базе win xp терминальный сервер. Если только облако делать на хостинге у провайдера, который не предоставляет xp/win2003. Но не факт, надо этот вопрос смотреть. Сейчас модно облако на домашнем компьютере поднимать, тогда вообще без проблем.

Вспомнил еще про один минус веба - высокие требования к рабочим станциям. При терминальном доступе можно ставить либо слабые старые компьютеры, либо бездисковые станции с большим сроком службы и малым потреблением электроэнергии. У меня один клиент даже когда-то покупал 2-3 такие станции. Но оказалось, что проще старые компы использовать, которых много дешевых б/у вариантов. Они работают лет по 15 до полного издыхания. Конечно, когда выход в веб не требуется. В некоторых конторах его, кстати, специально запрещают или ограничивают, так как сотрудники начинают злоупотреблять вместо работы.

.NET в помощь. И компиляция, и юнит тесты, и мультиплатформенность, и множество уже готовых библиотек, избавляющих от необходимости изобретать велосипеды. Ну, на крайний случай, Java.

TypeScript. Да. Замечательная вещь, как оказалось. Реально выручалочка.

Программирование в вэбе - это немного оффтоп. Программирование ДЛЯ вэба - это совсем не сложно, если есть хоть какие-то базовые знания в области.
Почти весь этот абзац - яркий пример незнания современных браузеров, UI фрейморков, и неумения готовить простейший javascript.
Ну, и ещё вспомним, как расшифровывается PHP, и подумаем, стоит ли использовать его для огромных систем энтерпрайз уровня.

В большинстве случаев достаточно будет, например, связки Laravel + Vue + PrimeVue. Отдельно - API на пыхе, отдельно - фронт-енд. И не надо сильно думать, что там в DOM происходит, как данные правильно байндить, какие хэндлеры вешать, и тому подобное. С точки зрения CSS тоже трогать ничего не надо - из коробки всё выглядит и работает красиво, и грамотно подогнано. И создание, например, формы ввода данных заключается в паре простых шагов: дюжиной строк описываем форму; генерируем описание DTO на TypeScript из похапе/.net/java (нужное подчекрнуть); используем их при запросах к API. Всё.

Вопросы безопасности вэб приложений стоят не острее, чем в RDP. Время отклика тоже не аргумент, ибо зависит от тех же сетей связи. И зарплаты разработчиков под вэб не выше, чем у сишников, например. Функциональность интерфейса зависит исключительно от умений разработчиков. А на extJS, например, можно собирать интерфейсы, которые десктопным приложениям и не снились.

Влючу еврея:
Как обеспечить терминальный доступ трёх сотен человек к RDP на единственном ящике с 64-мя гигабайтами оперативной памяти? Получают ли удовольствие от его использования люди, вынужденные тыкать пальцем в пятидюймовый экран телефона? Во сколько обходится такой пакет терминальных лицензий?

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

ЗЫЖ Разработкой вэб приложений я занимаюсь уже 15 лет (ну, начинал, конечно, с простых сайтов). Намучался в своё время с ишаками (особенно с восьмым), наблюдал расцвет jQuery (и вижу его угасание сейчас), перепробовал (и поддерживал совместимость с) множество различных браузеров, и с радостью отмечал улучшение их дружественности к разработчикам. Так же довелось попробовать различные UI фреймворки, включая jQuery UI (тьфу ты мерзость), Angular и extJS - каждый со своим подходом. Да, большую часть времени кодил именно на похапе, ибо деплоить такое крайне дёшево (линуксовые коробки можной найти по цене стакана семечек). Последние четыре+ года увяз в .NET - в частности, в .NET Core. На текущем месте работы занимаюсь плавной миграцией вэб приложения c Asp.Net на .NET Core. Довольно большая часть логики этого приложения является тяжёлым наследием ещё десктопного приложения, написанного на VB более 25(!) лет назад. И миграция эта необходима не только из экономических соображений, но и для сохранения конкурентоспособности. Текущая зависимость от .Net Framework - это полная зависимость от МС и их ценовой политики. Слезание с этой иглы - важная цель, достижение которой освободит огромное количество ресурсов.
Десктопные приложения отмирают. Заказчикам и пользователям нужна мобильность и адаптируемость интерфейса под разные типы экрана, да и UI должен обладать одинаковым функционалом и хорошим юзабилити в любой систем, на любом устройстве. Десктопное приложения такое не даст. Ну, МC пытались там что-то с UWP, но оно не взлетело. Смею предположить, по той же причине, по которой вообще ведётся этот спор - прикладники считают вэб (а в случае с UWP - мобильные приложения) детской игрушкой, фактически зарывая голову в песок (в энгри бёрдс на гейпаде, наверное, играют), и обрекая себя на тихое забвение.

ЗЗЫЖ Просто беглый осмотр вакансий девелоперов (или требований заказчиков ПО) даст статистику, в которой самыми частыми словами будут REST, React/Angular и Web.

Это, типа, Xojo?



Так, и любой уважающий себя Web UI фреймворк обладает такими билдерами. Тот же extJS (Sencha Architect), например.

Про масштабираемость я уже спросил выше.

Сказки. С вэб приложениями (а не с сайтами, забитыми рекламой) отлично справятся и дешманский лаптоп, и Core2Duo на двух гигах ОЗУ, и даже тормозной смартТВ. Про современные самртфоны и хромбуки даже заикаться не буду.

Self-hosted вэб приложение не требует выхода в интернет. Госструктуры именно так их и используют.

.Net и java не имеют компилятора в машинный код. У них jit компиляция в байт код. Странно, что не видите разницу, я про это только что написал.

extJS - приходили такие товарищи, рекламировали. Закрытая была среда. Некоторым понравились, некоторые поржали. Насколько я знаю, давно умерло. Там какая-то мутная история была, писали, что типа кинули всех пользователей. Может, конечно, восстали из пепла.

"Яркий пример незнания современных браузеров, UI фрейморков, и неумения готовить простейший javascript" - да куда уж там, сокральные знания, весь ютуб роликами забит.

Я сразу область применения обозначил - комплексные учетные системы для предприятий, как правило, 10-30 конкурентных пользователей. А тут опять, а вот что будете делать, когда 300 пользователей. Это все забавно, но слегка утомляет в больших дозах.

У меня среда так выглядит.







Редактор окошка я увидел. А теперь в 2 клика несколько готовых окон с работающим функционалом и без единой строчки кода могешь?

Разницу не вижу. PHP, Python, Perl - интерпретируемые языки, а .NET предлагает россыпь компилируемых языков (F#, C# и VB). Вот здесь есть разница. Языки из первой пачки компилируются при каждом запросе и каждом проходе через код (например, в циклах), а байткод компитирается лишь один раз - при первом обращении. Ну и ключевой момент - отловить ошибки ещё на этапе сборки приложения, а машинный код будет на выходе компилятора или какой байткод - уже вторично. Плюсом байткода, конечно, является полная независимость от железа. Будет JIT компилятор под Ti-84, можно будет и на нём хостить.

Никуда они не пропадали. И продукт у них вполне юзабельный, был приятен в разработке и хорош в работе. И не среда это, а офигенных характеристик JS фреймворк для разработки вэб приложений. Плюсов у него много, на самом деле, особенно для энтерпрайза. Хотя, наверное, пока не распробуешь, не поймёшь, а продажники сами не знают, что впаривают. Но, создать приложение, показанное в дизайнере форм на скриншотах на нём можно запросто. И приложение будет выглядеть чётко и совершенно одинаково хоть на линуксе, хоть на яблоке, хоть в браузере пятой плойки. Особенно доставляли сторы и простейший дата байндинг - ни строчки кода - только немного конфигов.

На сакральных знаниях из ютьюба дальше странички хэллоу ворлд не уедешь (да и то у неё будет индийский акцент). А, не... Список покупок/дел, вроде, крайне популярен. Но этот рынок уже захламлён.

О! Всё встало на свои места. У вашего продукта тоже, значит, крайне узкая ниша, и когда (а не если) появится какой-либо игрок, дающий тот же функционал в браузере, придётся засучивать рукава и затягивать пояса. Одновременно. Хотя будет уже поздно.
10-30 одновременных пользователей - это уровень шиномонтажа на хайвее. И пусть компутеры у пользователей - УГ, но зато сервер такой, что стОит как оборот этой конторы за полгода. Ну, просто чтобы терминальные сессии могли хотя бы калькулятор запустить.
Ответы на вопросы про мобильный доступ и стоимость терминальных лицензий ждать не буду.

А, ну да. Конструктор интерфейсов Кларион шестой версии. Сколько ему? 15 лет? Скоро 20? Т.е., примерно столько же, сколько и понятию "вэб приложение". Только у последнего только-только наступает бум (технологии позолили лишь относительно недавно). GMail, Google Docs/Sheets/Slides, Outlook, Word, Excel - всё это работает в вэбе. И работает хорошо, а порой даже лучше, чем на пека (тот же аутглюк, например). Аудио редакторы, видео редакторы, CAD - всё в вэбе. Но они все, наверное, ошибаются...

Нет. Уверен, и кларион не может. Но то, что я увидел на этих скриншотах - это не программирование. Программированием занимались те, кто создал кларион. А с показанной задачей справится даже менеджер среднего звена - это как магазин в Shopify (PaaS, кстати) создать - мышой клац-клац, и готово.
И, да, ExtJS это умеет:



Я понимаю, трудно поверить, что за вэбом будущее ВСЕХ массово используемых приложений. Но это так. Просто потому что их действительно проще и дешевле разрабатывать, сопровождать и обновлять.

В 2007-2009-м годах я разработал систему онлайн-заказа фотографий и фотокниг для одной Чебоксарской конторы. Понятие вэб-приложение тогда нам было ещё неведомо. Были просто сайты. И скорости интернетов были не ахти какие. Так вот, был сайт, написанный на похапе, и к нему был прикручен небольшой API, с которым работало десктопное приложение (какой такой REST? всё своё, кривое), задача которого была простая - загрузить фотографии на сервер, собрать информацию пользователя, и разместить заказ. JS тогда был ещё крайне куцый. jQuery был, конечно, отличным инструментом, но создать подобное приложение под браузер не представлялось возможным, потому что движков на рынке браузеров было несколько (да ещё и разных версий), каждый со своими причудами, и ещё нужно было поддерживать шестого ишака, который был хромым на все четыре ноги и оба уха. Да и не хватало функционала браузеров всё равно. Это как бы подкрепляло уверенность, что любые более-менее серьёзные действия пользователь должен совершать на локальной машине, в специализированном приложении.
В 2012-м, уже в штатах, мне удалось создать вэб-приложение с подобным (но более широким функционалом). Стало значительно проще, потому как стандартизация как-то устаканила разработчиков браузеров, и самым хромым, который надо было поддерживать, был IE9, который - не к обеду будет сказано - был просто шикарен (в сравнении с 6-м, конечно). В этом же году контора, в которой я сейчас работаю, выпустила первую вэб версию своего приложения. Причём, переделывать пришлось только морду с WinForms на Web Forms, и допилить логику загрузки-выгрузки файлов на работу с браузером. Тут помогла изначально грамотная модульная архитектура проекта. Клиентам больше не надо было держать эникейшиков, бегающих по этажам с флешкой, чтобы установить новую версию ПО - обновление сервера автоматически обновляло экспириенс всех пользователей.
В этом (2023-м) году нам доступны вещи, о которых ещё десять лет назад приходилось только мечтать: web workers, localStorage, File API, web сокеты, fetch, Push API, кастомные события, поддержка мультимедиа, и множество прочих вещей, без которых было невозможно воссоздать уровень десктопа в вэб приложениях. Ну, без кривых прокладок типа Adobe Flash и MS Silverlight (и где они оба сейчас мы все прекрасно знаем). Сейчас основным приложением любой операционной системы стал браузер. И не только для разглядывания картинок с кошечками. Discord, Spotify, VS Code, Twitch, Skype, Slack - все используют Electron - по сути, браузер, который идёт в комплекте с вэб приложением.
В общем, мне тоже видение вэб приложений как основных и единственных продуктов разработчиков не сразу в голову загрузилось. Осознание пришло постепенно, пока функционал браузеров рос, а доступ в интернет становился всё распространённе и быстрее. Но вывод однозначный. И повторять его ещё раз я не буду.

Странное ощущение, вроде умные слова пишешь, а видно, что плохо понимаешь. Байт код это набор инструкций для интерпретатора. Таким образом, речь не идет о компиляторах, просто маркетологи путают понятия - интерпретаторы плохо себя зарекомендовали в начале 90-х, когда железо было слабым. Из этой серии еще "управляемый код". Байт код создается, чтобы интерпретатор каждый раз не выполнял синтаксической разбор исходного текста программы. Поэтому c# и java всегда были тормознутыми по сравнению с компилируемыми приложениями, например, на c/delphy/ clarion. И pyton, и 1c работают примерно также - при первом запуске переводят текст в байткод, а потом его интерпретируют. Вроде и про php писали аналогично.

Всегда удивлял пассаж любителей веба, что под терминальные сервера нужно крутое железо. Товарищ, который у нас в комьюнити разрабатывает встроенный web сервер, тоже такую чепуху периодически озвучивает и, судя по всему, убедил себя и верит в это. На самом деле, все зависит от приложения. Для работы 10-30 пользователей подойдет почти любой современный бытовой компьютер. Если ставить более серьезное железо, то, скорее всего, надо говорить о сотне конкурентных пользователей, а не про 10-30. Я могу сказать про одну организацию, в которой 10 рабочих мест. У них сервер еще на win2003, двух ядерный процессор, которому лет 10 уже и пара гигабайт памяти. И все работает быстро. Не какое-то маленькое приложение, а полноценная учетная система, которая после запуска отъедает 100+ мб оперативки. Но фишка в том, что код этой в системе размещается в dll, а на терминальных серверах dll подгружаются в память только один раз и расшариваются между запущенными сеансами. в результате на каждого пользователя приложение откусит меньше 1мб - размер стартового exe. А компилированный код исключает массу служебных операций, которые имеют быть в интерпретаторах.

На скриншоте среда разработки clarion 11, версия от 2018 года. В заголовке написано Clarion6, так как используются компилятор и рантайм библиотеки от этой версии. Так можно, в одной среде переключать разные версии компилятора.
Судя по всему, ты не представляешь, что такое кларион. Если кратко, это язык программирования, наподобии си или паскаля (точнее, по синтаксису он ближе к модула 2), со строгой типизацией и встроенными объектами для разработки деловых приложений - оконными/репорт/файловые структуры и т.п. Поддерживает структурное и объектное программирование. Можно писать прямо на этом языке и компилировать в машинный код. Но основная фишка это язык темплейтов. С его помощью (в обычном текстовом редакторе) создаются так называемые темплейты (шаблоны) - это объекты метаданных, которые автоматически генерят код на языке клариона. В отличии от других сред, код регенирится. В проекте хранятся объекты метаданных, а не создаваемый код. Логику генерациии кода определяют информация в словаре (структуре базы данных) и задаваемые разработчиком значения в промптах шаблона (реже - в промптах других шаблонов). То есть весь каркас приложения строится на шаблонах. Вставка кода в нужные места шаблонами или вставка ручного кода осуществляется в эмбеды. Это case технология. Таким образом, в итоге собирается приложение, часть кода которого генерится автоматически, часть может написать разработчик самостоятельно.
Шаблоны можно создавать, какие тебе нужно, насколько хватит фантазии. Я в основе использую русскоязычную версию семейства Clarion шаблонов (процедурный вариант), плюс порядка 150 своих, разработанных специально под свои задачи. Таким образом, clarion это эффективный инструмент для создания своего фреймворка, заточенного на ту идеологию построения систем, какую ты сам считаешь оптимальной.

Закачал ролик, показывающий, как работает в реале. Небольшое пояснение, озвучивать или титры вставлять лень было.
1. Берем чистый фреймворк. Это системные вещи, которые включаются в во все проекты (кроме небольших утилит).
2. В словаре (структуре базы данных) создаем справочник Olegon. Чтобы не растекаться мыслью по древу, копирнул типовую структуру из мастер словаря.
3. В одном из модулей автоматом создаю сразу 3 диалоговых окна - просмотр справочника, редактирование справочника, выбор из справочника.
4. Компилю.
5. В заглавном ехе в меню фрейма включаю вызов этого справочника. Потом по мелочам причесываю.
Замечу, что мы не просто создаем справочник Olegon. Эта структура автоматически встраивается в систему управления окнами, изменения автоматически логируются (обеспечивая аудиторский след), автоматически включается в систему распределения прав доступа, настройку панели команд, статистику доступа к диалоговым окнам, отображается в разделе технической поддержки, включается в систему версионирования структуры базы данных и т.п. Это обеспечивает функционал конкретного фреймворка, разработанного на clarion под свои задачи. При этом все собирается в обычные exe+dll, всякие веб сервера, .Net фрейворки или джава машина не требуется. На компьютере у клиента минимум телодвижений, достаточно одной винды любой версии (кроме мобайл).

Диалог по прежнему не уходит в конструктив. FinSoft, приглядись все же, пожалуйста, максимально непредвзято к сути обозначаемого.
И, подтвержаю, ролики на ютупе не дают понимание, как и что программируется на самом деле. Надо что-то попробовать создать самому. И не в теории, а под конкретную задачу. "От" и "до", чтобы прочувствовать все нюансы.
"Не верю" :) MS давно уже не шарит dll между сеансами из-за проблем безопасности. Видимо, понимание "быстро" очень сильно отличается. Десять пользователей одновременно разве что только калькулятор смогут запустить.

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