Интеграция (Ich will version)

0. botokash 377 16.09.22 15:30 Сейчас в теме
Поговорим про интеграцию с точки зрения архитектора.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 625 16.09.22 15:46 Сейчас в теме
Ахтунг! Игоря на вас нету...
2. ixijixi 1470 16.09.22 16:25 Сейчас в теме
А давайте его позовем! Или он сам приходит на англицизмы?
Прикрепленные файлы:
0x00; frkbvfnjh; a_a_burlakov; +3 Ответить
26. Evil Beaver 7864 18.09.22 20:28 Сейчас в теме
3. amd1986 16.09.22 18:53 Сейчас в теме
Много иностранных слов. Пользы от этого не много.

http запросы не рекомендуется использовать. Лучше https. Get запросы также не стоит.
4. botokash 377 16.09.22 19:00 Сейчас в теме
(3) Настройте https на веб-сервере где публикуете базу, в чем сложность? И почему это GET запросы это плохо?
5. amd1986 16.09.22 19:17 Сейчас в теме
(4) сложности нет. У вас пример с http. И любопытны настройки проверки содержимого запросов с https.
Тем что видны параметры. С точки зрения безопасности лучше использовать post запросы. Да и ограничения по размеру запроса у get запроса есть.
10. nixel 1320 16.09.22 20:24 Сейчас в теме
(5) вы путаете тёплое с мягким. https - это надстройка над http, которая живёт только на уровне веб сервера. На уровне сервера приложений трафик уже расшифрованный.
Выбор get/post/других http-глаголов должен быть обусловлен семантикой и логикой запроса, а "плохостью"
Bazil; Aleskey_K; so-quest; horsgroup; zen_daya; +5 Ответить
15. zen_daya 16.09.22 22:42 Сейчас в теме
(5)
Не соглашусь с вами насчет проблем безопасности GET запросов

Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для выполнения этого запроса, без хранения какого-либо контекста на стороне сервера. Состояние сеанса целиком хранится на стороне клиента.
Надо просто правильно проектировать API
user1831019; +1 Ответить
24. gybson 18.09.22 14:55 Сейчас в теме
(15) Имеется в виду уязвимость URL. В случае с https это не должно быть актуально.
23. gybson 18.09.22 14:53 Сейчас в теме
(5) а DELETE безопасный?

Если есть желание из REST сделать SOAP, то делайте сразу SOAP.
qwerty_3; +1 Ответить
40. amd1986 19.09.22 11:18 Сейчас в теме
(23) SOAP сложнее интегрировать с внешними сервисами.
Aleskey_K; +1 Ответить
6. botokash 377 16.09.22 19:35 Сейчас в теме
(5) На то это и пример, не понимаю претензии. Платформа 1С не отвечает за протокол, а разработчику 1С вообще без разницы что стоит перед/на веб-сервере. Об этом должны заботиться сетевики, безопасники, админы.
Про GET - можете ссылкой о чем речь? Делать запрос на получение ресурса в REST API методом POST - звучит странно.
13. amd1986 16.09.22 20:33 Сейчас в теме
(6)
(6)
Делать запрос на получение ресурса в REST API методом POST - звучит странно.

Потому что не сталкивались с проблемами.
27. Evil Beaver 7864 18.09.22 20:29 Сейчас в теме
(13) с какими проблемами можно столкнуться, используя GET вместо POST?
46. amd1986 19.09.22 11:36 Сейчас в теме
(27)
- Проблемы с безопасностью.
- Проблемы с ограничением передаваемых данных.
47. Evil Beaver 7864 19.09.22 11:37 Сейчас в теме
(46) какие проблемы с безопасностью?
51. amd1986 19.09.22 11:55 Сейчас в теме
(47)
В get запросах данные передаются в параметрах запроса
В post запросах данные передаются в теле запроса
7. tormozit 6868 16.09.22 20:13 Сейчас в теме
Заголовки на непонятном думаю большинству читателей языке - не к месту. Думаю стоит их заменить русскими вариантами. Они как бы нужны в первую очередь для ускорения навигации читателя по статье =)
fieryfist; +1 Ответить
8. botokash 377 16.09.22 20:17 Сейчас в теме
(7) Была такая творческая задумка - первый куплет из одноименной песни (его перевод) раскрывает суть "боли" архитектора) Но, как говорится, из песни слов не вырежешь, оставлю как есть. На амальгаме можно посмотреть перевод нормальный.
qwerty_3; +1 Ответить
14. NiGMa 16.09.22 22:20 Сейчас в теме
(7) Сергей, это ж песня. Строчки из песни.
Раммштайн (Rammstein), "Ich will"
37. starik-2005 2829 19.09.22 11:11 Сейчас в теме
(14)
Rammstein
У меня подружка бывшая уважала, мне сам звук нравится, но как это пишется - понятия не имею.

ЗЫ: ИМХО, было бы куда веселее, если бы это все было русскими буквами. Типа: "Ду хаст!" (это все, что я осилил вспомнить). 100% не я один такой.
39. botokash 377 19.09.22 11:17 Сейчас в теме
(37) почему многие в комментариях так активно "цепляются" за подачу? Англицизмы, написано не русскими буквами - это все что беспокоит профессионала в наше время? Есть термины, которые придуманы не нами, есть песни, перевод которых никого не интересует.
qwerty_3; +1 Ответить
41. starik-2005 2829 19.09.22 11:21 Сейчас в теме
(39)
есть песни, перевод которых никого не интересует
Это одна из них?
42. botokash 377 19.09.22 11:26 Сейчас в теме
(41) Тут больше вижу проблему в том, что увидев непонятное для себя людям проще сказать КГ/АМ, а не попытаться разобраться в вопросе. Предлагаю считать этот вопрос закрытым =)
56. starik-2005 2829 19.09.22 13:29 Сейчас в теме
(42)
людям проще сказать КГ/АМ
Людям действительно проще так сказать, даже, предположу, Вам. Так что не провоцируйте людей - будьте к ним благосклонны. Они же пришли с утра на работу и вся их активность часто ограничивается поиском того, над кем бы постебаться. Такова жизнь большинства наших (и не наших - тоже) сограждан, увы и ах...
9. Ndochp 103 16.09.22 20:21 Сейчас в теме
В зипе ЛогированиеREST и ОбработкаВызоваREST?
11. botokash 377 16.09.22 20:25 Сейчас в теме
(9) в зипе cf файл с двумя подсистемами самого инструмента и доработками по примеру из статьи. ЛогированиеREST и ОбработкаВызоваREST это название общих модулей. Так же, в самом начале статьи есть ссылка на репозиторий гитхаб, где базовая конфигурация лежит как проект EDT.
12. Ndochp 103 16.09.22 20:26 Сейчас в теме
16. malikov_pro 1235 17.09.22 16:04 Сейчас в теме
За разработку темы трассировки + и sm.
По содержанию статьи
* "ключевым отличием от него является способ заключения контракта" - не понял какие именно отличия?
* указан что выбран "Elastic APM", но нет описания что вообще возможно собирать в трассировки и почему выбрали именно его. В модуле
ДобавитьВТелоЗапросаМетаданные(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаТранзакцию(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаИнтервалы(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаМетрики(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаОшибки(ТелоЗапроса, КонтекстЗамера);

Сам разбирал структуру сообщения sentry, много чего интересного накопал, блок с производительностью там тоже есть.
* для многих развернуть сервис мониторинга неподъемная задача, нужна как минимум ссылка на документацию по установке.
* По каким аспектам пересекается с анализом производительности БСП?
* Возможно ли переложить эти наработки на мониторинг работы внутренних функций, в формах например?

По коду
* зачем комментарий?
// ОписаниеСервиса
ОписаниеСервиса = УправлениеRESTПовтИсп.ПолучитьОписаниеСервиса(КонтекстЗапроса.КлючСервиса);


Зачем выделять в отдельную переменную?
в СформироватьДанныеКонтекстаЗапроса()

ИмяПубликации = ПолучитьИмяПубликации(ДанныеИсходногоЗапроса);
Результат.ИмяПубликации = ИмяПубликации;


Хардкод системы мониторинга
HTTPСоединение = Новый HTTPСоединение("vm-ais-logmonitor.technodom.kz", 8200);


Отправка сделана синхронно, и если сервер мониторинга недоступен, то колом встает основной сервис. Возможно коллеги предложат решения с + и -.

По реализации
У Валерия Крынина уровень абстракции сложен для восприятия (мне по крайней мере), у вас представлена более простая модель HTTP сервиса с одной точкой входа, думаю подходы будут интересны сообществу, например вариант маршрутизации без regexp
* в ПроверитьКонтекстЗапросаПоСпецификации не увидел блока валидации тела запроса по JSON Schema наработки уже есть.

На сколько сложно вынести описание обработчиков в код?
// Вызов обработчика
РезультатОбработчика = Неопределено;
Команда = "РезультатОбработчика = " + КонтекстЗапроса.ОписаниеМетода.Обработчик + "(КонтекстЗапроса, КонтекстЗамера);";

Попытка
	Выполнить(Команда);


Его все равно версионировать, что из БД доп. затраты по сравнению с кодом. И прослеживаемость "Выполнить" отсутствует
19. botokash 377 17.09.22 17:54 Сейчас в теме
(16) ух как много вопросов. На каждый развернуто тут не ответишь, предлагаю перейти в личку, а ещё лучше в телегу.
Если кратко, касательно кода - представлен не готовый продукт, об этом сразу сказано. Там многое стоит ещё доделать, в том числе валидация и упрощение жизни разработчику. Путь на сервер APM да, забыл исправить) А вот про обработчики не понял вопроса.
17. quazare 3074 17.09.22 16:12 Сейчас в теме
18. DemetrKlim 130 17.09.22 16:16 Сейчас в теме
Ну... из всего написанного, я только немецкий текст и понял (спасибо колледжу в земле Саксония.....)
20. malikov_pro 1235 17.09.22 20:48 Сейчас в теме
(19) А вот про обработчики не понял вопроса. - сейчас реализовано в виде записей с справочниках, мне привычнее в виде кода, возможно просто непривычно. При наличии "библиотеки" HTTP сервиса под нее можно сделать трансформацию кода в/из swagger.

"На каждый развернуто тут не ответишь" - задал в том числе чтобы коллеги обратили внимание на эти вопросы.
Моя версия была опубликована в 19 году, Валерий в 20 году добавил свое, после началась "движуха" по swagger, в этом году вроде еще "пролетала" реализация. Движение есть, вероятность сделать серверную часть на уровне Коннектор1С присутствует. Нужен тот кто соберет базово github проект, дальше могу подхватить, практика EDT+git полезна, пример https://github.com/plastinin/diagramobject/issues

Рядом тема с JSON-RPC, как легковесная замена SOAP, больше ограничений по сравнению с REST, но и реализация думаю проще будет.
33. starik-2005 2829 19.09.22 10:53 Сейчас в теме
(20)
JSON-RPC
Был тренд в стороне graphQL, хороший механизм для извлечения данных. Я так понимаю, что он является частным случаем реализации.
21. malikov_pro 1235 17.09.22 20:51 Сейчас в теме
(18) Так задайте вопросы с момента когда становится непонятно. Сам при написании статьи упускаю моменты которые для меня понятны, а окружающие с этим не сталкивались.
22. DemetrKlim 130 17.09.22 21:03 Сейчас в теме
(21) Не, я - бестолковый. Занимаюсь кондовым, посконно-домотканным программированием для альтернативно-одаренных заказчиков, случайно приговоренных к работе в бухгалтерии. Я выше арифметики не подымаюсь....
a_a_burlakov; +1 Ответить
32. starik-2005 2829 19.09.22 10:49 Сейчас в теме
(22)
Я выше арифметики не подымаюсь....
Я выше арифметики поднимаюсь только при решении тестовых задач на очередных собеседованиях. Но там вся математика сводится к тому, как интерпретировать формулу. Остальное - это много арифметики, ибо даже красивый значок суммы - это всего лишь сложение элементов массива.
54. DemetrKlim 130 19.09.22 12:55 Сейчас в теме
(32) Тебе смешно, а у меня - комплексы... Как почитаю тексты... осмелюсь сказать, коллег и слюна прокисает от досады. Люди работают с какими-то небожителями, решают какие-то их удивительные и выдающиеся проблемы. А я вспоминаю лица своих заказчиков, у которых основные проблемы описываются на уровне средней группы детсада. Такое ощущение, что я в каком-то интеллектуальном гетто оказался, без права на подъем с глубины.
55. starik-2005 2829 19.09.22 13:27 Сейчас в теме
(54)
без права на подъем с глубины
Воспользуйся социальным лифтом, сам придумай, что это...
25. gybson 18.09.22 15:08 Сейчас в теме
"один из сервисов внутри компании"

Внутри компании лучше SOAP. Там и с типизацией получше, с валидацией и структура данных документирована.

Про одну точку входа вообще загадка. Она по определению у одного HHTP-сервиса одна. В чем прикол парсить URL, вместо того, чтобы добавить шаблон и тем самым задокументировать функцию? Не? Пусть в модуле копают и выяснят, чего там как работает.

Это кунг-фу с разбором строк, когда на уровне платформы все можно получить разжеванным, оно зачем? У вас модуль обработки вшит в конфигурацию. Вы все-равно не сможете просто так добавить обработку другого запроса.
34. botokash 377 19.09.22 10:56 Сейчас в теме
(25) Условно не соглашусь. Не отрицаю наличие такой ситуации, когда система 1С интегрирована с "устаревшими" продуктами, в период создания которых SOAP действительно являлся стандартом. Но сейчас даже http REST это уже не "модно", все больше grpc и другого низкоуровневого стека используется.
itoptimum; +1 Ответить
28. user1831019 18.09.22 21:55 Сейчас в теме
(2) Да тут в основном немчизмы!
Жаль, что я в школе плохо учил казахский. Сейчас бы в комментариях блеснул казахизмами.
29. DemetrKlim 130 19.09.22 08:00 Сейчас в теме
(28) Я программирование начинал изучать как раз у немцев (промышленные контроллеры только начинали появляться). И вот какое отличие заметил уже тогда (1989 - 1990). Их "учителя" не стараются умничать. Они отчетливо понимают, что их аудитория признает свою изначальную некомпетентность и пришла именно за знаниями и компетенциями, а не на замер.... кто там чем хотел померяться! Если взять несколько самоучителей по программированию отечественных и забугорных авторов, то отчетливо видно, что западенец пишет, как комикс для детей, зачастую - с картинками! Его задача - обучить, дать понимание. Ему не нужно раздувать свое эго, если он реально дожил до самоуважения к себе, как к профессионалу. И берем учебники (методические материалы) наших авторов. На первых же строках автор просто обязан продемонстрировать свое знание высшей математики и истории партии с решениями последних съездов) Текст пресыщен кучей научных терминов, за ссылками на которые надо постоянно нырять "в зад" книжке. Не чтение, а мучение.
Среди коллег, увы, такая родимая генетическая линия тоже присутствует. Надо так написать, чтобы был виден "уровень"))
starik-2005; +1 1 Ответить
31. starik-2005 2829 19.09.22 10:46 Сейчас в теме
(29) Вот соглашусь с Вами, хотя и не стал бы говорить, что наши учебники так уж плохи. Я начал изучать программирование лет в 10-11 по книжке, которую взял у друга. Книжка наша, про бейсик. Потом у приятеля взял книжку "Паскаль в иллюстрациях" - офигенная книжка, в которой все эти "дискретные алгебры" с их графами и двоичными деревьями, хеш-функциями и прочими оптимизациями работы со списками, даны были в виде картинок и очень простых текстов. Но фундаментальное понимание программирования я именно по "нашей" книжке без картинок получил, т.е. сам по себе ответ на вопрос "как это работает". Да, потребовалось выплакать тонну слез, рассчитывать было совершенно не на кого, ибо в 1990-м году вокруг не было компьютеров, а программистов не было даже на большом расстоянии. И я сейчас нисколько не жалею, что мне тогда пришлось пережить эту дыру боли, и очень рад, что я взломал тот текст, а не он меня - сработал принцип образования по Занкову, когда перед учеником ставится такая задача, которую он заведомо не может решить, и через которую единицы продираются. Это действительно работает - на своей шкуре проверил.
30. starik-2005 2829 19.09.22 10:39 Сейчас в теме
Вот такая простая "реализация SOAP" с помощью HTTP-сервисов ))) Осталось только передавать схему данных с информацией о списке сервисов, их параметрах и возвращаемом значении...
35. botokash 377 19.09.22 11:00 Сейчас в теме
(30) это далеко не SOAP. Сейчас тренд в сторону уменьшения размера пакета данных и, соответственно, трафика. Ведь одной из причин появления формата JSON было именно этим обусловлено. Хотя история циклична, команды переходят на protobuff, который по сути низкоуровневый SOAP =)
36. starik-2005 2829 19.09.22 11:06 Сейчас в теме
(35)
Сейчас тренд в сторону уменьшения размера пакета данных
Ну так смысл этого тренда в том, что клиентов очень много стало, а пропускная способность сети за ними не успевает.
А SOAP - он же любой массив данных может передать - хоть жуткий и большой XML, хоть сжатый в 100 раз массив данных в base64. "Протобуф" просто избавляется от дополнительных байт base64 и заголовков полей, но он работает только поверх HTTP2.

А в части моего коммента, то если добавить то, о чем я написал, будет реализация SOAP на JSON. Ну да, пакеты будут чуть меньше, но сложность реализации возрастает. При том для кейсов с 1С размер пакетов - это второстепенная проблема.
38. botokash 377 19.09.22 11:14 Сейчас в теме
(36) я может что-то не правильно понимаю, но SOAP это протокол и согласно ему сообщение имеет определенную структуру, которую никуда не выкинешь. Как бы мы не сжимали тело сообщения, останется обязательная часть, и именно отход от нее обусловлен постепенным отказом от SOAP в высоконагруженных системах. Плюс каждое движение над телом запроса - это дополнительные "такты" как на клиенте так и на сервере.
43. starik-2005 2829 19.09.22 11:26 Сейчас в теме
(38)
останется обязательная часть
Она не такая и большая. И, опять же, в 1С не является узкой частью.
(38)
это дополнительные "такты"
Опять же, в 1С это малосущественно. Я вот, лично, не вспомню и даже навскидку придумать не могу сценарий, где такты и вес сообщения для 1С являются существенными факторами.
И да, для SOAP можно написать так:
Возврат Новый ХранилищеЗначений( Запрос.Выполнить().Выгрузить(), Новый СжатиеДанных(0) );
В HTTP придется все это засовывать в тело ответа, т.е. как минимум создавать новый объект "HTTPОтвет" и засовывать в тело ответа получившиеся данные. И если их не паковать, то размер HTTP-пакета будет больше, чем размер пакета SOAP с пожатым хранилищем значений.
44. botokash 377 19.09.22 11:30 Сейчас в теме
(43) В частном случае системы 1С как 90% всех ИС компании - да. Но все таки в статье моя основная мысль - система 1С как один из сервисов внутри компании. И вот тут становится вопрос анализа всего архитектурного стека разработки компании. И свои выводы я предоставил.
45. starik-2005 2829 19.09.22 11:36 Сейчас в теме
(44) Ну так у каждой системы есть определенные требования к уровню обслуживания: реакция, доступность, нагрузка. 1С - это бэкофис, в лучшем случае еще что-то типа внешнего хранилища НСИ - этакий провайдер мастер-данных, MDM. В кейсе с MDM доступность системы должна быть высокой, но и пакеты там не особо большие ходят. В части бэкофиса, то 1С - это коллектор поступающих от фронта сообщений. И если думать об архитектуре, то в части MDM просто обязан быть механизм кеширования, чтобы за каждым ежеминутно нужным фронт не таскался в 1С - пусть берет из кеша, а 1С пусть кеш обновляет при изменениях. А при транспорте в коллектор нужен приличный брокер сообщений с гарантированной доставкой, а не прямой HTTP-сервис.

Я вот вообще не вижу 1С, как высокодоступного поставщика данных в корпоративной системе - это не ее функция.
49. botokash 377 19.09.22 11:42 Сейчас в теме
(45) Мы говорим о разных вещах. Я о системе 1С как части стека со всеми вытекающими требованиями, а вы о роли системы. Мои доводы о современных требованиях к используемым решениям это про то что по факту окружает нашу 1С систему.
50. starik-2005 2829 19.09.22 11:49 Сейчас в теме
(49)
Мы говорим о разных вещах.
Напротив, мы говорим об одном и том же - об архитектуре. Это слово есть даже в кратком содержании статьи (слово "Архитектор"). Так вот архитектура - это то to be, которое обеспечивает те самые реакцию, доступность и нагрузку. Если нагрузка небольшая, требования к доступности невысокие, а реакция позволяет пользователю сходить и налить кипятка, то нам достаточно 1С и SOAP. Если же требования возрастут, то выигрыш в 10% на HTTP-сервисах не даст ничего, т.к. все упрется сначала в доступность, потом в нагрузку, а потом и в реакцию (ну или наоборот, сначала в реакцию, потом в нагрузку, а за ними и в доступность, ибо Вы решили обновить систему в самый неподходящий момент, ибо предыдущее обновление все к хренам сломало).
53. botokash 377 19.09.22 12:09 Сейчас в теме
(50) Сожалею, но вы меня так и не поняли. Статья - интеграция с точки зрения архитектора. Человек, принимающий решение на основании своих компетенций и поставленных условий решения задачи. А условия не всегда про техническую составляющую, а больше про денежную. В данной ветке дискуссии мне больше нечего добавить =)
57. starik-2005 2829 19.09.22 13:31 Сейчас в теме
(53)
а больше про денежную
Скука.
48. booksfill 19.09.22 11:38 Сейчас в теме
Я не уверен, что паттерн Front Controller такое уж хорошее решение - при всех плюсах получаем серьезные проблемы:

1. Единую точку отказа - любая ошибка в самом методе (а иногда и в вызываемых из него) приведет к остановке всех сервисов.
Либо к тому, что они будут работать не так, как ожидалось (это в огород "попытка исключение", или заплатке типа Если ИСТИНА Или ...).

Не забываем, что "в подарок" еще получаем единую точку атаки.

Это все равно как отказ автопилота полностью заблокирует возможность ручного управления самолетом.

Мне кажется, что реализация такого паттерна без обязательной реализации системы "аварийного" канала - плохое решение.

2. Искусственная связь разных сущностей с "навязанным" общим решением.
Например, считаем, что все действия надо логировать, потом передумываем, точка входа начинает проверят некие условия и вместо удобства выполняет никому не нужные действия. Плюс еще на этапе архитектуры приходится закладывать соответствующие возможности, усложняя ее.

А все потому, что логика разных сущностей меняется независимо от остальных и с разной скоростью.

3. Потенциал стать бутылочным горлышком. Это хорошо видно на примере типовых конфигураций 1С, когда движения делаются путем вызова стандартных методов, которые зачастую выполняют 90% не нужной работы, в угоду универсальности и в ущерб понятности и быстродействию.

4. Как тут уже написали - вместо набора понятных и независимых сущностей, получаем некую загадочную "точку входа", куда по любому чиху лезем, чтобы понять что она умеет. И лезть в документацию, в общем случае, - плохая идея, т.к. совпадение документации с реальной жизнью, такое себе, красивое.
Артано; starik-2005; +2 Ответить
52. botokash 377 19.09.22 12:03 Сейчас в теме
(48) Для меня описанные проблемы выглядят немного "притянутыми за уши":
1. Единая точка входа - это изолированная функциональность подсистемы и отлично поддается тестирования. Если допускается возможность попадания в прод такого рода ошибок в коде - это проблема другого характера. А ошибка разработчика, написавшего обработчик метода сервиса, всегда изолирована через попытку и не может привести к остановке всего сервиса.
2. Цель применения подобного паттерна - разделение ответственности и единообразность. И если мы говорим разработчику не логировать что-то внутри сервиса почему он должен начать это делать? Или почему мы вдруг решим отойти от паттерна и в контроллер тянуть какие-то условия, нарушая тем самым его смысл?
3. Не вижу как пример с типовыми коррелирует с предоставленным подходом? Есть общепринятые рамки создания REST API и не предвидится никаких "вдруг" изменений в механизм его работы.
4. Сошлюсь на ответ в пункте 3. И вопрос к вам от меня - что является "набором понятных и независимых сущностей"?
58. booksfill 19.09.22 15:26 Сейчас в теме
(52)
Если бы я знал "как надо", я бы не комментарии писал,а статьи :)

Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет.
При этом "вес\значимость" того, что этот метод делает может быть различным для разных, вызываемых им методов.
И ошибка эта вовсе необязана выглядеть как "все пропало", она может провиться, например, чт овремя отклика станет слишком велико.


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

"набором понятных и независимых сущностей"

ПолучитьСписокСкладов - понятно и никак не зависит от "УдалитьСклад".
"УдалитьСклад" - понятный и независимый от метода "ПолучитьСписокСкладов", потому как идентификатор склада я могу получить множеством других способов.
59. malikov_pro 1235 19.09.22 16:30 Сейчас в теме
(33) По ссылке - "GraphQL это синтаксис, который описывает как запрашивать данные", а RPC - " класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве". Инструменты для разного класса задач. Про RPC упоминаю потому что на практике периодически вижу SOAP с схемой данных в виде одной строки в которую упихивают все подряд (XML), которое нормально заменяется JSON-RPC.
60. starik-2005 2829 19.09.22 16:34 Сейчас в теме
(59)
описывает как запрашивать данные
А что мы делаем при вызове веб-сервисов? В основном или запрашиваем данные, или передаем данные в систему. Остальные кейсы малозначимы. gpaphQL - это просто еще один механизм, позволяющий запросить тот пакет данных, который нужен получателю. Это как oData, фактически, только для извлечения данных.
61. malikov_pro 1235 19.09.22 22:34 Сейчас в теме
(58) "Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет." - если у вас косяк в коде и он не интерпретируется на уровне модуля HTTP сервиса, то даже в ЖР не напишет, не важно его количество.

Либо маршрутизация делается на уровне платформы, но она не умеет в regexp, и за ней "допроверять" в коде, либо используем роутер реализованный кодом. Проблемы при маршрутизации на уровне платформы начнутся когда начнете добавлять Listeners (слушатели), типовых форматов ответов, валидации передаваемых данных, доп аутентификации итд, вам придется в каждую функцию обработчик их прописывать, пробовал, неудобно.

"Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой." - сначала надо написать чтобы было удобно поддерживать и окружающим была понятна структура. Для примера посмотрите HTTP сервис для Mango в УНФ/РарусCRM, при адаптации их переписал на более прозрачную схему.

Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.
@botokash поэтому писал что хочу делать кодом, чтобы не завязываться на общую структуру данных в спр.
62. botokash 377 20.09.22 05:21 Сейчас в теме
(61)
чтобы не завязываться на общую структуру данных в спр


Думаю понял теперь о чем вы хотели сказать. Я считаю это вопросом в плоскости реализации и не вижу его таким значимым по отношению к поставленной цели, описанной в статье. Я реализовал то что почитал более быстрым, а другой разработчик может сделать как ему больше нравится. Напомню, цель моей статьи была не конечный продукт, а демонстрация практики и подхода к разработке сервисов =)
64. booksfill 21.09.22 11:22 Сейчас в теме
(61)
Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.


Вот, собственно я это и имел в виду, но, написал коряво. Тогда уже получаем достаточную надежность.
Просто насторожило введение Front Controller без оговорки об опасности реализации его в лоб, ну, или я был не внимателен.

А если надо больше, то это уже можно реализовать на уровне перенаправления средствами Apache + кластеризация и т.п., далее много умных слов, не имеющих никакого отношения к статье. :)

P.S. А вообще, было бы интересно, если кто-нибудь подробно осветил только правильную реализация данного паттерна в 1С, как раз с учетом первичной отказоустойчивости и балансировки нагрузки хотя бы по слушателям.
63. 1CUnlimited 162 20.09.22 13:09 Сейчас в теме
>"использование системы 1С как одного из сервисов внутри компании";
Сразу плюсанул за эту фразу, многие из 1С делают центр, но естественные ограничения платформы как бы намекают
65. malikov_pro 1235 21.09.22 11:55 Сейчас в теме
(64) "то это уже можно реализовать на уровне перенаправления средствами Apache" - https://infostart.ru/1c/articles/1258813/
"балансировки нагрузки хотя бы по слушателям." - вывод аутентификации на уровень кода, создание нескольких публикаций для одного HTTP сервиса, балансировка на уровне NGINX https://serveradmin.ru/nginx-v-kachestve-balansirovshhika-nagruzki/

нужно разбираться что за сервис, какого типа нагрузка, какое количество запросов, если есть состояние сеанса, то рядом нужно redis например прикручивать. Если "справочники", то выношу в промежуточный сервис на PostgREST, статью по этому поводу писал.

Будет свободное время - попробую организовать проект на GitHub и в него собирать наработки.
botokash; +1 Ответить
66. botokash 377 21.09.22 13:32 Сейчас в теме
(65) Спасибо за ссылки, полезная информация.
Оставьте свое сообщение
Вакансии
Аналитик 1C
Москва
зарплата от 120 000 руб. до 250 000 руб.
Полный день

Тестировщик 1С
Москва
зарплата от 125 000 руб.
Полный день

Программист/тестировщик
Москва
зарплата от 130 000 руб. до 150 000 руб.
Полный день

Ведущий разработчик 1С / Team lead отдела разработки 1С
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день

Программист 1С
Москва
зарплата от 150 000 руб. до 180 000 руб.
Полный день