Дело в том, что в статье не отражена некоторая подоплёка: изначально никакой ручной вёрстки не планировалось, однако после того, как было сделано чуть больше половины работы (включая интерфейс и серверный код, ответственный за доступ к данным), из-за одной проблемы с uniGUI, которую так и не удалось решить, пришлось применить описанный в статье подход, сохранив, что крайне важно и приятно, весь серверный код. Поэтому написанное — это положительная иллюстрация того, что библиотека позволяет при острой необходимости проделать такую радикальную замену.
Также в качестве небольшой ремарки — упомянутый проект агрегатора на самом деле состоит из двух сайтов: публичного из статьи и служебного, служащего для управления содержимым первого, который уже написан исключительно на компонентах uniGUI, по первому сценарию.
а как обстоит дело с состоянием(state), если делать приложение с web интерфейсом
Если правильно понял вопрос, то дело с состоянием вполне обстоит — при каждом обращении к веб-приложению (речь идёт о SPA) создаётся своя сессия в новом потоке, которая может хранить любые нужные ей данные (то самое состояние); если представить, что пользователь открыл, скажем, 3 вкладки такого сайта, то на сервере появится та же троица сессий.
многопотчность при standalone server
Данный тип сервера ничем не отличается в этом плане от прочих — на каждую сессию будет автоматически создан свой поток.
Автономный (standalone) сервер и Windows-служба компилируются в исполняемый файл (exe), как такового подключения не требуют, т. к. сами себе и веб-сервер, и сайт — всё в одном флаконе.
ISAPI-модуль представляет собой DLL, которую необходимо добавить в сторонний веб-сервер. Сайт-агрегатор, упомянутый в статье, развёрнут именно в таком виде (на IIS).
Можно стандартно приладить туда обычные компоненты?
Если под «туда» имелась в виду форма, а под определение «обычные» подпадают визуальные VCL-компоненты, то нельзя, однако большинство невизуальных (например для работы с базами данных) — конечно можно.
Насколько понимаю, Вы предлагаете полностью веб-решение, когда приложению (в том числе мобильному) отводится всего лишь роль контейнера для браузера; для несложных случаев — почему бы нет, но у синхронизации (да и всего проекта в целом) требования довольно разнообразны и специфичны (например, работа над списками без доступа к сети).
Не могли бы Вы уточнить, почему упомянули UniGUI? Её связь со статьёй довольно слаба — разве что эта библиотека использует в качестве транспорта HTTP, озвученный здесь в таком же качестве.
Изначально FireMonkey создавалась для полностью самостоятельной отрисовки интерфейса, но позже были добавлены некоторые родные компоненты у двух ОС: Windows и iOS; в дополнение к этому, для мобильных платформ есть как бесплатные наборы для построения родного интерфейса в Android и iOS, так и платный — но только под iOS.
Делфи выполняет компиляцию напрямую в машинные коды, причём это касается не только Android, но и всех поддерживаемых платформ. Никакие сторонние графические фреймворки тоже не используются — за отрисовку интерфейса отвечает собственная библиотека FireMonkey.
Также в качестве небольшой ремарки — упомянутый проект агрегатора на самом деле состоит из двух сайтов: публичного из статьи и служебного, служащего для управления содержимым первого, который уже написан исключительно на компонентах uniGUI, по первому сценарию.
Данный тип сервера ничем не отличается в этом плане от прочих — на каждую сессию будет автоматически создан свой поток.
- Автономный (standalone) сервер и Windows-служба компилируются в исполняемый файл (exe), как такового подключения не требуют, т. к. сами себе и веб-сервер, и сайт — всё в одном флаконе.
- ISAPI-модуль представляет собой DLL, которую необходимо добавить в сторонний веб-сервер. Сайт-агрегатор, упомянутый в статье, развёрнут именно в таком виде (на IIS).
Если под «туда» имелась в виду форма, а под определение «обычные» подпадают визуальные VCL-компоненты, то нельзя, однако большинство невизуальных (например для работы с базами данных) — конечно можно.