Comments 52
Не то чтобы хотелось покритиковать, но почему-то с заголовка и до середины статьи думал что бэк будет на Delphi. Оказалось что на php...
Соглашусь, тоже так думал. И кстати, не понимаю, почему бы не написать и сам сервер на Delphi. Для этого много инструментов имеется. Как полных фреймворков с роутингом, орм, миграцией и т.д., так и просто готовых фреймворков, где ОРМ можно подключить отдельно или вообще не использовать.
Сам сейчас как раз занят созданием такого сервера на Delphi (уже второго) с использованием фреймворка MARS.
Пример
[Path('/catalog')]
TCatalog = class
public
[GET, Path('configuration_tabs/{config_name}'),
Produces(TMediaType.APPLICATION_JSON)]
function GetTabs([PathParam, Required] ConfigName: string): TConfigurationTabs; //автоматическая сериализация объекта в json
end;
[Path('/catalog_items')]
TCatalogItems = class
protected
class var
Cache: TCache;
protected
[Context, Connection('MAIN_DB')] // автоинъекция подключение к бд и пула
MAIN_DB: TMARSFireDAC;
public
[POST,
Produces(TMediaType.APPLICATION_JSON),
Consumes(TMediaType.APPLICATION_JSON)]
function CatalogItems(
[QueryParam] count: Integer;
[QueryParam] offset: Integer;
[QueryParam] total_count: Boolean;
[BodyParam, Required] QueryData: TJSONObject): TJSONObject; //сырой json
end;p.s. по наименованию роутов понимаю глупость. Но я вынужден подстроиться под клиенты. Бэк пишется не с нуля, а переписывается с Питона
А я наоборот думал- зачем же бекэнд на делфи, его же в линуксе не поднять)
Или сейчас делфи уже научилось в кросплатформенность?
А Delphi еще где то используется ?)
Я очень плотно использую Delphi 11 в двухзвенной архитектуре под sql для нужд производства в компании где работаю. Быстро делается интерфейс и логика в процедурах на сервере. Сделал уже два приложения на связке delphi/sql server. Нет необходимости настраивать клиентов, использую firedac, около 60 пользователей в самом сложном МЕS приложении, удалённые пользователи через корпоративный vpn, трафик небольшой, так как вся обработка на сервере, на котором крутятся ещё три системы с подобной архитектурой под labview, плюс система мониторинга всех приложений. Пиковая загрузка сервера не превышает 20 % благодаря продуманный архитектуре баз данных, коих сейчас насчитывается уже с десяток. Есть ещё приложение, которое крутится на php,pyton, postgres Linux, но периодически глючит. В общем простoe grud приложение. Тот кто его делал давно покинул контору. Никакой потребности делать так не было, просто чел изучал новые технологии и готовился уйти в другое место.
Очень "вендорлокнутый" стек с очевидными ограничениями по масштабируемости и гарантированными проблемами в поддержке - тащить в виде legacy мертвую лошадь конечно можно - но в среднесрочной перспективе такоэ себе.
Какие-то преимущества перед qt или там шарпом наверное есть - но со стороны пожалуй что не видны.
C# и Qt - это тот же самый "вендорлок". А спецификация языка и среда разработки в последний раз выходили в декабре прошлого года (через месяц выходит апдейт (задерживается из-за перехода на новые рельсы Jira)). Для легальной сборки проекта не требуется подписка на среду разработки, а для получения апдейтов достаточно продлить лицензию. О legacy речи вообще не идет.
Гм. Да. У вас какое-то очень, очень, очень специфическое понимание термина. Opensource-delphi у вас есть? FPC+lazarus не предлагать, ага :). А MsSQL от какого-нибудь более-другого вендора? Ну или хоть не весь мускуль - так альтернативную реализацию T-SQL? Опять-таки про SELTA н-нинада. И с "альтернативным windows" на котором можно эту самую delphi запустить тоже, насколько мне известно, "не сложилось" пока.
Вы что то не то пишете, про поддержку. У меня не web приложения, поддержка проста, так как северная бизнес логика. Весь sql и изменения фиксируется в бд, всегда можно откатиться. Клиентское приложение просто интерфейс, кнопочки, таблички и тп. Специальная структура бд упрощает разработку северной логики. Я просто очень хорошо знаю sql, умею правильно, быстро и оптимально обрабатывать данные на сервере без загрузки трафика клиентом, как делается в web. Web в области корпоративной разработки не только не нужен, но и вреден, так как неоправданно усложняет разработку. Незачем тащить с собой бесполезный чемодан, набитый всякими не особо нужными вещами. Были уже попытки в конторе, я об этом писал, и все это не только глючит, но и тормозит. Держать дорогую команду web разработчиков под внутрикорпоративные МЕS задачи производства никто не будет. Да и все что касается железа в производстве, а это настройка, тестирование и тп под Web делать невозможно.
Где вы возьмете новых разработчиков на delphi, с учетом того, что pascal с деривативами уже даже из институтов en masse выпал? Про "коммерческую разработку" на deplhi и вовсе молчу - не то, чтобы "совсем нет", но где-то на уровне статпогрешности. А сколько времени у человека "с улицы" займет въезжание в специфическую бизнес-логику, размазанную между клиентом, сервером и БД на tsql (Нормального ОРМ предполагаю нет?) - с учетом того, что формализованных постановок, CI\CD, скв в таких случаях скорее "нет"?
Тут ситуация из разряда "если надо объяснять - то не надо объяснять", если честно. Кейс с необходимостью полной замены типа-MES'а на delphi на вот "нухотьсовсемчтоугодно" в связи с выходом специалиста (1 штук, да) на пенсию у меня окрест есть, ага.
Разработчики есть, ОРМ - десяток наберется, CI/CD без проблем давно работает, СКВ вообще в Delphi встроен (git/svn). Делфи и Pascal преподают в том числе и в университетах. Проектов на Делфи тысячи, и я только о новых. В том числе и крупных, от больших корпораций. Например, Сбер недавно выпустил кроссплатформенный клиент Сбер Pro на Delphi + FMX (гуглится очень легко).
Бизнес-логику строить можно как угодно. Стандартов у этого нет и въезжать в любую бизнес-логику человеку с улицы будет одинаково сложно, что на Делфи, что на другом языке. В том числе и пользователям системы.
Не-не. Тут разные ветки - "про delphi" как инструмент - отдельно. Там все относительно неплохо, тут вы правы.
Вторая - про _конкретное решение_ в комменте выше - с MsSQL и бизнес-логикой на T-SQL server-side, с классическим "толстым" клиентом - и вот тут все относительно плохо, CI\CD+git для СУБД не то, чтобы "совсем нет", скорее "как правило нет". Да, если у тебя все миграции данных в коде и вся логика работы с БД через ORM - то оно как бы и ничего, но тут как я понял - прям сильно не тот случай.
По персоналу\проектам - ну ок, раз вы говорите, что всего в избытке - сталбыть, так оно и есть.
Ну критиковать конкретный случай бизнес-логики на общих правилах - как бы не совсем честно. Более того, стоит всё же иметь более глубокое понимание что и как и не строить домыслов. Я бы не стал критиковать подход человека основываясь лишь на том, что написано человеком выше. Мало данных.
Про избыток я не говорил, перекос в разработчиках Делфи очевидно имеется. Но, не критичный.
Ну, я считаю, что данных достаточно - но да, могу и ошибиться, конечно же.
"Критичный"\"не критичный" - вопрос интересный. Скажем так, в окрестностях delphi\fpc в качестве технологического стека для построения чего угодно просто _не рассматривается_ - просто нет возможности нанять нужное количество разработчиков "с рынка". Если у тебя есть готовая команда - усилить её +1, край 2-мя сотрудниками наверное получится - собрать под задачу хотя бы пять человек - не-а.
Вы мою статью почитайте, на хабре, в профиль зайдите. Там я описываю свою систему тестирования интеллектуальных приборов. Клиент labview, северная логика. Что либо подобное сделать с логикой на клиенте ну не знаю, вообще возможно ли за вменяемое количество времени. Команда два человека, я как архитектор БД и sql+ напарник на labview.
Да как бы трехзвенка же, чтобы бизнес-логику из БД поелику возможно вынести...
Можно, но цель? Эта система работает уже несколько лет без каких либо проблем. Параллельно с системой мониторинга. Сейчас масштабируем до 8 станций и ничего не надо переделывать. В предыдущей конторе подобную систему без программируемых тестов делало 6 человек несколько лет на C#. Мы вдвоём за год программируемую. Если маяться с логикой на клиенте то тут годом бы не отделаться. Система очень стабильна благодаря связке labview и SQL server. Единственное что вынес на клиета это расчёт коэффициентов полиномов, так как требовалась нехилая точность при обратном расчете полиномов. У нас сложная математика, это не джисоны туда сюда гонять
Нет, не настолько плохо в найме, поверьте. За этот год мы начали строить несколько новых проектов и буквально за пару месяцев наняли более 4 новых человек на Делфи направление. Замечу, что у нас не только Делфи, но и С# с юнити и рекат и даже местами питон, в штаты которых мы тоже параллельно набирали людей. Так что проблем с этим нет. Также, стоит заметить, что проекты именно новые, на новых версиях инструмента и новых стеках.
Ну, под сотню актуальных резюме в которых указано "что-то про delphi" на всю Москву есть, да. Из них именно программистов с релевантным опытом (А не бэкенд, фронтэнд и ну вот delphi еще был), готовых к переходу на новое место работы - ботинки снимать не придется, не факт, что и вторую руку из кармана доставать понадобится.
Вы не понимаете, что простота разработки и установки включает расширенную в сети папку в которой лежит ехе. Ярлык на рабочий стол пользователя вот и все что нужно. Документы через шаблоны EXCEL. Коммерческая разработка не нужна. Можно в этой идеологии и C# использовать. Клиент можно любой, но только не всякие qt которые несовместимы могут быть от версии к версии. Delphi я использую из за firedac - любую бд поддерживает без настройки коннектa.
Это из разряда "хуже воровства", да.
Раздутость кода, зависимостей библиотек и команд разработки вот что хуже воровства в этой web парадигме программирования, которую вы называете "современными технологиями". Об этом пишут многие профессионалы программирования кто приложил к этому руку в 2000-х. Благо бы она была нужна в области удалённого доступа, но в локальной разработке это большой геморрой. Я обхожусь минимальными средствами и достаточными чтобы создавать качественное, лёгкое в поддержке и доработке и стабильное ПО.
Ну и я вставлю свои "5 копеек" за то что Delphi все еще жив))
За последние 5 лет видел написанное на Делфи ПО в структурах ООН и Deutsche Bank с довольно приличным интерфейсом и богатым корпоративным функционалом, поэтому наверное Делфи незаслужено ушло в тень учитывая размеры команд - очень экономит бюджет, если сравнивать с командами на Java.
Используется, переписывал на одном месте работы методы API с Delphi на C#, в основном благодаря Net.Core код практически уходит, становиться в разы меньше и проще. Хотя методы API на Delphi немного быстрее работали :)
Странно, спросил где используется, накидали минусов… Простое любопытство задевает чьи-то чувства ?)
Дело в том, что вопрос мертв ли Delphi, на хабре уже много раз был обсосан. Простым гуглением можно узнать используется ли где-то Delphi. А вопрос ваш и его форма выглядят как провокация (признаюсь, даже мне до сих пор так кажется), скорее всего поэтому и минусят.
Delphi используется до сих пор там, где на нём было много написано, например, многие САПР были и остаются на Delphi. Хотя кто-то уже переползает на C#. Также выше пишут, что используют его там, где надо легко и быстро накидать приложение. Причём запускаться оно будет без установок библиотек и зависимостей.
В целом Delphi хороший, читаемый язык. Его теперешнее состояние кажется заслуга плохого менеджмента. Слышал от тех кто пишет до сих пор на нём, например, что в какой-то момент Embarcadero (разработчик) начали копать в сторону Android, macOS и iOS вместо каких-то действительно полезных фич. Но это только одно мнение и то, возможно перевраное.
Старая информация, но отражает действительность на 2010-2016ые года. Изначальный крах произошел в следствии конкурентной борьбы с Microsoft. А кто в те года мог себе это позволить, если MS решит создать конкурентный инструмент? Вот и Борланд не смогла, потеряла одного из ключевых разработчиков и идеологов Андерса Хейлсберга, который перешёл в MS для работы над C#. Что в свою очередь сделало C# почти таким же удобным инструментом для разработки как и Delphi, перенеся львиную долю идей в .Net (правда сейчас уже WinForms немного заброшен, а новые подходы не такие удобные). Но рынок порешал в пользу более выгодного C# с .Net. Другими словами, Delphi просто задавили.
После покупки Delphi компанией Embarcadero, стало развиваться кроссплатформенное направление, но не только оно. Полезных фич в языке появилось не мало, а стандартная библиотека начала разрастаться очень сильно. С тех пор появились дженерики, хелперы, развитие рефлексии с атрибутами и прочим, анонимные функции, инлайн переменные, вывод типов, инлайн оптимизации, "мультистроки", таски, фьючерсы, локальные скоупы, расширенные структуры, перегрузка операторов, классовые конструкторы/деструкторы, бинарные числа (var Bin := %010001) и так далее. Можно много накопать, а это только то что я помню. Среду разработки тоже развивают, но к сожалению, пока речи о кроссплатформенной среде речи не идет. А вот саму кроссплатформу развивают. Один код прекрасно будет работать на всех платформах. Я как-то недавно портировал GameBoy эмулятор под кроссплатформу. Дольше игрался в игры GameBoy на Андроид после сборки, чем потратил на портирование.
Согласен с Вами, тоже был свидетелем когда амбасадоры Embarcadero очень активно двигали идею писать на Делфи мобильные приложения, а энтерпрайз сегмент как-то забросили. Плюсую, это стратегический просчет руководства, не развивать фичи для корпоративного сегмента.
У самого всегда появляется мысль о Делфи когда встает задача создания какого-то прототипа или проверки какого-то бизнес функционала, так как без лишних хлопот можно быстро набросать вполне приличный функционал, хотя моя специализация Java.
Мммм... непонятно, зачем тут delphi? Десктопное приложение выдвигает специфические требования к интерфейсу, (не|сложно) реализуемые в браузере?
А по openapi-спеке генератор совсем-совсем кривой и не работает? Вроде ж даже гуглится в количестве более одного...
А у нас теперь принято писать именно веб-приложение для браузера, если требуется работать с сетью?
Последние лет эдак 15 если не 20? Да. Если нет очень специфических требований к интерфейсу, то да - да и то с развитием WASM'а это уже не столь строгое ограничение.
Ага... Т.е. именно по этому за последние 15-20 лет созданы десятки новых GUI фреймворков, придуман Электрон (прости хосподи), под Питон созданы обертки для разных GUI фреймворков, а Flutter теперь и на десктоп позволяет писать?
За последние 15-20 лет увеличилось количество веб-разработок, но при этом, количество десктоп разработок не уменьшилось. Просто у вас сменились интересы.
Более того, Delphi - это давно далеко не только десктоп.
Электрон - это на мою мельницу вода, нет? :)
Насчет "десятков новых GUI-фреймворков" тоже, если честно, сомневаюсь. Тема не моя - но из кроссплатформенного есть вот QT, GTK и, наверное, wxWidgets? Ява примерно померла, шарпей за рамками windows не взлетел - кто остался на трубе?
По десктопу - окрест меня разве что тренажеры для операторов с их требованиями к отзывчивости интерфейсов на чистом десктопе пилят... ну вот "ничего" не пилят. Даже чертов 1С на котором одно время изрядно было - и тот в околовебню уползает.
Для энтерпрайза майнтенанс десктопов - дорого. Деплой вебни на 1000 пользаков - примерно "бесплатен", аналогичная операция для десктопного приложения - нууууээээ... чаллендж. Распилить десктопное приложение под совместную разработку N-командами - не то, чтобы "нельзя", но задача требующая прям хороших таких специфических навыков, да и набрать N-команд под один технологический стек - возможно не всегда, а для вебни пачка микросервисов в диапазоне от java'ы до .net'а через php-python-js вполне себе рабочая история. Да много очевидных причин на самом деле - на текущий момент ситуация такова, какова она есть и больше никакова, а отрицание действительности ни к чему хорошему как правило не приводит.
В том-то и дело, что "тема не ваша". Электрон - это скорее камень в ваш огород, т.к. даже вебу приходится исхищряться, чтобы угодить пользователю. Что и привело к созданию Электрона. А кроссплатформенного GUI в мире очень много. Тот же Flutter, в рамках десктопа, - новая разработка. В Delphi кроссплатформенный GUI с рендером на GPU (по дефолту, но опционально) общий для всех платформ (Винда, Линукс, Андроид, Мак, Иос).
Для энтерпрайза и других областей развертка софта - это секундный апдейт перед/в момент запуска. Любой Энетпрайз, который занимается не только чатиками и циферками в документах использует десктоп программы. Для мониторинга, сбора и анализа данных, для управления производством, для сложных вычислений, для графики/рендера, и т.д. Там веб в принципе влезть не может, даже с WebAsm.
И это не говоря о том, что многие языки позволяют создавать и веб-приложения тем же кодом. На Delphi есть несколько фреймворков с WYSIWYG для создания веб-приложений (не Асм), а с компиляцией и генерацией JS (погугли UniGui и TMS Web Core).
Электрон - это скорее камень в ваш огород, т.к. даже вебу приходится исхищряться, чтобы угодить пользователю.
Зависит от точки зрения. С моей - бизнес и разработчики _не готовы_ писать для десктопа, но еще пока могут заморочиться и упаковать ранее написанное вместе с браузером чтобы вывалить пользователю одним шматком. Иногда даже неплохо получается.
А кроссплатформенного GUI в мире очень много. Тот же Flutter, в рамках десктопа, - новая разработка.
Ну да. Только написанного на нем софта я окрест себя не вижу. Вижу я вот PyCharm на яве - но JB тут как бы не "последний из могикан" свою патченную java'у с GUI тулкитом тянет, телегу вроде бы на qt, файрфокс на gtk, teams на электроне - да в общем-то и все.
Для энтерпрайза и других областей развертка софта - это секундный апдейт перед/в момент запуска.
Не. Не видел. Безопасники не приветствуют. Единого стандарта нет, а разрешать каждый-суслик-агроном свою реализацию пилить, да с SRP стыковать... не видел. Скорее в существующем софте автообновление старательно отломать пытаются, а чтоб в insource-разработке делали...
Любой Энетпрайз, который занимается не только чатиками и циферками в документах использует десктоп программы.
Угу. И тот, что с "чатиками" тоже - куда-ж с него денешься-то? А местами и не хочется деваться - веб-интерфейсы как правило штука редкостно отвратная при регулярном использовании. Но дешевая, да - что собственно и решает.
Для мониторинга, сбора и анализа данных, для управления производством, для сложных вычислений, для графики/рендера, и т.д. Там веб в принципе влезть не может, даже с WebAsm.
Как архитектору этих самых систем управления производством мне в этот момент некоторым образом смешно, извините. Не попали вы примерно по всем пунктам. Безальтернативно на текущий момент - разве что SCADA в процессах с высокой дискретностью, а вот уже диспетчерский контроль на веб-интерфейсах цветёт и пахнет во все поля...
Управление производством может включать в себя не только набор служб, к которым подключаются клиенты для управления и мониторинга данных. Подобные службы могут быть конкретным элементом управления конечным станком. Системы на ЧПУ, софт для работы с конечным контроллером рядом с установкой. Системы, которые в реалтайме управляют системой под управлением оператора и уже сами могут быть связаны с другими службами управления производством для складирования данных или получения установок. Вы же ведь все, кроме "управления производством", которое имеет очень широкую область, пропустили из списка.
Веб-разработка не дешевле, особенно с учетом того, что штат для веб разработчиков требуется куда шире, чем для разработки даже целой системы 3х звенки.
Ну да. Только написанного на нем софта я окрест себя не вижу. Вижу я вот PyCharm на яве - но JB тут как бы не "последний из могикан" свою патченную java'у с GUI тулкитом тянет, телегу вроде бы на qt, файрфокс на gtk, teams на электроне - да в общем-то и все.
Так ведь мир крутится не только вокруг вас. Более того, вы заинтересованы в конкретных инструментах. Вы вроде как "разработчик" (в широком смысле этого слова), а не пользователь, на которого и направлен создаваемый софт. Разве никто не пользуется графическим софтом? Софтом для создания и редактирования документов? Для работы с видео? Для работы с устройствами?
Мир также не крутится вокруг интернета. Именно глобальной сети. Для производства глобальная сеть (и то не всегда) необходима уже в конце цепочки производства. А вся работа, которая и производит что-то осуществляется с устройствами, автоматикой, роботами, которыми управляют операторы в реальном времени. Давайте мы будем использовать веб браузер и сайтик для управления ковшом, который переправляет и закидывает в доменную печь металлолом на переплавку. Который напрямую получает данные с аналоговых устройств или контроллеров.
Любая серьезная работа, не включающая в себя абстракции в виде бухгалтерии или работы с цифрами и тому подобное, не особо рвется использовать браузеры и веб. Любая программа, которая использует данные здесь и сейчас - это десктоп программа работающая в реальном времени.
А когда мы говорим о простом домашнем использовании компьютера, которых к слову всё меньше и меньше у частных лиц (в угоду мобильным устройствам), конечно всё меньше и меньше десктоп софта. Тем не менее, очевидно, что для работы с калькулятором вы запустите десктоп программу, как и при работе с файлами. Не уверен, что вы читаете и редактируете текстовые файлики через браузер. Не уверен, что и картинки смотрите через него или фильмы (если они в виде файлов). Т.е. почти вся работа с файлами - десктоп софт (и не имеет значения, что он "встроен в ОС", потому что это отдельная десктоп программа в любом случае).
Для работы с СКВ, вы вероятно тоже не будете использовать веб (речь о просмотре истории разработки, а не git commit ., git pull, git push). Да и для разработки, почему-то мало кто использует веб версию VS Code на полноценной основе или другой подобный инструмент. Забавно, что даже Телеграмом все пользуются через клиент, а не через существующий веб-клиент.
У меня как у разработчика тоже мало "десктоп софта". Однако, архиваторы, просмотрщики, редакторы - десктоп софт. Уверен, что и у вас тоже. Тот факт, что в ОС сейчас встроено огромное количество функций никак не отменяет того, что нужен и другой десктоп софт. Вы уже не замечаете, что используете десктоп софт, это для вас прозрачно. Да что говорить, вы просто как должное принимаете, что IDE - десктоп софт и ТГ - десктоп софт, но для вас это как бы "исключение".
Чтобы было понятно - я НЕ люблю веб-интерфейсы. Они мне НЕ нравятся. Мне НРАВИТСЯ fpc\lazarus - с моей т.з. это "близкий к оптимальному" инструмент для развития именно "регионально-российского" IT, для которого задачи масштабирования "на весь мир" с "поддержкой индусами" и выносом всего-и-вся в облако не то, чтобы прям остро стоят на повестке дня для всех отраслей.
Но - при всем при этом я реалист и мое мнение к положению дел в индустрии отношение имеет примерно "никакое".
И да, окрест меня люди работают с графикой в фигме\drawio, открывают документики 365ым офисом (Онли - для неудачников), сам я калькулятором не пользуюсь и или в питонячьей консоли тыкаюсь, либо в адресной строке браузера пишу, и даже code-review все больше в браузере же, там же и кино-домино, ага. "Мир сдвинулся" и надо с этим жить.
Фигма и draw.io - это не графика, а инструмент для построения интерфейсов из примитивов, при чем средствами самого же веба. 365 офис не работает оффлайн. Мир не сдвигался в сторону веба, веб это лишь расширил. Заменить он standalone приложения никогда не сможет, в частности, если будет это и дальше происходить внутри абстракции браузера и тем более внутри абстракции абстракции - webasm.
В статье не стал упоминать требования к интерфейсу дабы не захламлять.
Одним из специфичным требованием являлось требование работы со сканерами Zebra (использовать Zebra SDK) - автоматом настраивать их и т.д. Было смутное ощущение что с веб интерфейсом это было бы намного сложнее сделать, если конечно вообще возможно. А времени на изучение темы как всегда не было))
Используем в нашем комплексе для REST API Delphi MVC Framework https://github.com/danieleteti/delphimvcframework . Документации для старта достаточно, для более расширенной можно купить книжку за $50.
Над фреймворком написан свой фреймворк для внутренней стандартизации обмена табличными данными. REST API также используется для взаимодействия клиентских модулей между собой на одной машине, и даже внутри одного процесса. Так удобно отлаживаешь клиентскую и серверную часть в одном приложении, с использованием паттерна "удаленный фасад" а потом выносишь серверную часть в удаленную службу.
Бакэнд собирается под Windows и Linux. Лазаря посмотрели, но прошли мимо - в первую есть опасения работоспособности отладки. в нем - кода много, Delphi справляется с компиляцией на пределе по памяти.
Для нового клиентского кода используем кроссплатформенные компоненты TMS FNC. Они позволяют использовать одинаковый код для VCL и FMX, только формы нужно продублировать. FMX FNC приложения собираем для Windows и Linux ( c использованием FmxLinux) . Разработка ведется под Windows. Новые приложения уже кроссплатформенные. В старые VCL приложения новые формы добавляем разработанные на компонентах TMS FNC для VCL.
Непонятно зачем автор статьи сразу налепил API Gateway , не понимая требований. И раз 5 сослался на отсутствие документации. Да есть документация, если поискать. В ТГ канале по Delphi обсуждали все фреймворки REST API
Пишем REST-приложение на Delphi