krvsakalin Про современных :)
Вона как...
Как писалось выше "Простой разработчик сейчас должен работать на одном стеке. Frontend или Backend"
И хотелось добавить, ему абсолютно безразлично, какая там внизу стоит СУБД. Современные средства разработки, поддерживающие ORM https://ru.wikipedia.org/wiki/ORM, исключают "прямое" участие разработчика в непосредственном создании структур данных или таблиц в самой СУБД и "прямую" работу с этими структурами. За создание структур данных в СУБД и поддержку их целостности при их изменении отвечает непосредственно ядро ORM. Отсюда следует, что установка и настройка СУБД, изучение ее особенностей установки, а также поддержка целостности ее работы на серверах - это не задача Frontend или Backend разработчика, а системного администратора.

И еще , Frontend или Backend разработчик не взаимодействуют, как правило, напрямую с ORM. Для этого есть соответствующие инструментальные средства для разработки Frontend и Backend

DAiMor,
Хорошо. Вернемся к IS.
Где можно посмотреть готовое решение от IS для Cache, где из "коробки" можно было бы реализовать простейший web Backend интерфейс, а именно:
1. Описываем Модель1
2. Описываем Модель2 -> содержит поле модель1
3. Меню -> модель1 - > отображение с возможностью редактирования и контроля в виде таблицы и формы модели2 с выводом информации модели1 -> поиск в модели1 и 2
2. Пользователь -> регистрация -> меню > доступ к модели2
Из "коробки", подразумевается написания кода только самих моделей и их полей данных.

DAiMorkalin,

Я участвовал в разработке двух проектов, которые наверно наверно немного близки к тому, что вы типа хотите.
Первый это, что-то наподобие 1С. Есть толстый клиент, который можно перевести в режим дизайнера и менять/создавать формы, программировать на скриптовом языке эти формы. Но большая часть работы все равно была на каше сервере, там выполнялись все основные процессы. И добавление полей в таблицы все равно осуществлялось на стороне Cache.

И второй проект это ЛЕТОГРАФ. тут на самом деле большой полет фантазии, это документооборот, и так что в некотором роде близок к ERP. Здесь конечный пользователь продукта не программирует вообще ничего (но может немного). Но может создавать новые виды документов с любым набором полей, к сожалению не получилось сделать там визуальный редактор форм, но есть HTML файлики которые служат шаблоном для отображения документов. И там много чего еще можно делать и все это только через интерфейс приложения.
Все правильно пишите. Только такой пускай не визуальный редактор форм (представлений) и генератор моделей должен быть предоставлен IS и им поддерживаться, и "тонкости" организации таблиц и объектов в Cache оставить генератору моделей. Т.е. IS должен предоставить некий FrameWork, и не важно какие он технологии в себя будет включать:node.js, react native,Qweb, Xpath и пр... и предоставить к нему описание на API для конечного разработчика. Речь не идет об изобретении "собственного велосипеда", а об использовании готовых решений применительно к СУБД Cache. Ну, соответственно, в данном FrameWork должен быть набор полноценных модулей для создания простейшего backend и frontend приложений начального уровня, на базе которых сообщество сможет расширять функционал и выкладывать модули и приложения для всех желающих.

Все сводится к тому, что-бы привлечь разработчиков не имеющих ничего общего с Cache и не желающих тратить время на изучение всех тонкостей работы с данным продуктом, но умеющих использовать более распространенные средства разработки ПО.

Блок А.Н.,
Бил Гейтс и сделал систему для "дураков", называется Windows и стал миллиардером :)

Как Вы думаете, какой код проще изучить начинающему кашисту:
Вариант Cache:
s rezult=##class(%ResultSet).%New()
d rezult.Prepare("select * from User.User where Group='admin'")
d rezult.Execute()
while rezult.Next() {
w rezult.Get("Name")
}

Или ORM:
rezult=model['User.User'].search(['Group','=','admin'])
for d in rezult:
print(d.User)

doublefintkalin, если у начинающему повезло, и кто то уже заложил модель и определил интерфейсы), то наверно такой


Гораздо проще было бы еще написать:
s array=$$user^Group("admin") w array
Но проблема в том, что $$user^Group кто-то должен еще написать, впрочем как и ByGroupFunc("admin")

AlexKBkalin,

В Вашем примере Вы сравниваете несравнимое - в SQL-терминале просто наберут строку:

select Name from sample.person where ID=8
Давайте в прошлый век, будем писать SQL и скрипты для прямой работы с базой

DAiMorkalin,

Такие куски кода совершенно ничего не говорят, все зависит от начинающего кашиста, и того как хорошо поработали его предшественники.

То же самое касается и любых других языков программирования, вы представили какой то абстрактный язык (хотя похоже это питон), а их много, или вы предлагаете всем отказаться от этого и писать на вашем ORM, а ваш ORM на чем написан?
Совершенно не понятно, что вы так вцепились за этот уровень, не забывайте, что разработчиков много разных. Вы преподносите эту ORM как святой грааль, что он идеален. И наверняка в вашем ORM еще вагон проблем.

Кстати с Cache тоже можно из питона работать.
Здесь тяжело спорить, каждый выбирает на чем ему проще и дешевле реализовать логику работы своего приложения.
Python, так же как и node.js и пр. не является интегрированным в Cache на уровне ядра framework. Технология Cache, насколько я знаю, рекомендует писать код встроенными в ядро средствами.

DAiMorkalin Здесь тяжело спорить, каждый выбирает на чем ему проще и дешевле реализовать логику работы своего приложения.
Python, так же как и node.js и пр. не является интегрированным в Cache на уровне ядра framework. Технология Cache, насколько я знаю, рекомендует писать код встроенными в ядро средствами.
Какая то странная логика, а ваш ORM встроен в PostgreSQL, или их разработчики как то принимали в этом участие. О какой интеграции с каким ядром Framework речь?
Эту интеграцию предлагает InterSystems, а рекомендации по поводу то чтобы использовать COS нету. Рекомендация может быть только на уровне, если нужно больше производительности.
А как-же CSP и zend framework , встроенные в Cache ?
По поводу производительности - весьма спорный вопрос, который, опять же, был актуален в прошлом веке на "слабом железе".

В cache своего рода ORM присутствует на базе CacheObjectScript, но на сегодня набор "просто" классов никому не нужен. Тот же Zend предполагает написание с нуля приложения, где события интерфейса обрабатываются на стороне Cache. Но на сегодня этого явно недостаточно.