EMACSWAY_LOG Telegram 1576
Вообще я сегодня должен был написать либо про философские доклады с BiasConf, либо про InBetween.

Но внезапно я сделал новую версию карты интеграций: https://github.com/yksi12/integrations/blob/main/Integrations%20Tech%201.0.1.pdf

Добавил туда JSON-RPC, т.к. он в последнее время стал популярен в связи с MCP — протоколом для взаимодействия LLM с внешними источниками данных и сервисами. Также он используется в блокчейн-проектах (они не на слуху, но вообще-то вполне себе живы и развиваются).

На картинке видно, что протокол легковесный: вся линейка почти пустая.

Впрочем, карта уже дает предсказательную силу — ну не опишешь ведь RPC ни в OpenAPI, ни в AsyncAPI. Но должен же быть формат для описания спецификаций? Ну вот он и есть: OpenRPC! https://open-rpc.org/

То есть, когда вы сталкиваетесь с какой-то новой для себя технологией или приёмом, можете задать себе всё те же вопросы:
— Верхнеуровневый паттерн: это удаленный вызов или обмен сообщениями (надеюсь, общую БД и файловый обмен вы не используете)
— Это синхронно или асинхронно?
— Какая метафора используется? Какая семантика взаимодействия? Вызов процедуры, CRUD над ресурсами, гипермедиа, запрос данных, извещение, подписка на событие, очередь? У некоторых авторов это называется "интеграционный стиль"
— На каком это протоколе? HTTP, HTTP/2, TCP с какой-то своей нашлепкой? И если HTTP, то только как транспорт, или по полной, как в REST? Протокол-то вообще бинарный или текстовый? И вообще, этот метод завязан на конкретный протокол, или может использоваться с разными?
— В каком формате передаем данные? Есть ли у этого формата схема? Строгая ли типизация в этом формате? Он плоский, или допускает вложенность? Насколько сложным по структуре может быть ответ?
— Если нам нужно преобразование данных, то есть ли штатные средства для этого?
— Что с обработкой ошибок? Можно ли определить и возвращать собственные коды ошибок и дополнительную информацию?
— Что с безопасностью? Аутентификация и разделение полномочий? Есть ли штатные средства? Или всё ограничивается TLS/SSL и OAuth?
— Что с производительностью, скоростью и гарантиями доставки?
— В чем мы это будем описывать, какие есть языки спецификаций и инструменты тестирования? Где мы эти спецификации храним и как обеспечиваем их актуальность?

И если мы берем какую-то совершенно новую технологию, нужно просто задаться всеми этими вопросами. И мы можем сравнить две технологии — дублируют ли они друг друга? Можно ли использовать на одном проекте RabbitMQ и Kafka? Что выбрать — GraphQL или gRPC?

В общем, кажется, схема работает. Про что ещё можно спросить в отношении технологий интеграции, чтобы сравнить их друг с другом?
🔥4👍2



tgoop.com/emacsway_log/1576
Create:
Last Update:

Вообще я сегодня должен был написать либо про философские доклады с BiasConf, либо про InBetween.

Но внезапно я сделал новую версию карты интеграций: https://github.com/yksi12/integrations/blob/main/Integrations%20Tech%201.0.1.pdf

Добавил туда JSON-RPC, т.к. он в последнее время стал популярен в связи с MCP — протоколом для взаимодействия LLM с внешними источниками данных и сервисами. Также он используется в блокчейн-проектах (они не на слуху, но вообще-то вполне себе живы и развиваются).

На картинке видно, что протокол легковесный: вся линейка почти пустая.

Впрочем, карта уже дает предсказательную силу — ну не опишешь ведь RPC ни в OpenAPI, ни в AsyncAPI. Но должен же быть формат для описания спецификаций? Ну вот он и есть: OpenRPC! https://open-rpc.org/

То есть, когда вы сталкиваетесь с какой-то новой для себя технологией или приёмом, можете задать себе всё те же вопросы:
— Верхнеуровневый паттерн: это удаленный вызов или обмен сообщениями (надеюсь, общую БД и файловый обмен вы не используете)
— Это синхронно или асинхронно?
— Какая метафора используется? Какая семантика взаимодействия? Вызов процедуры, CRUD над ресурсами, гипермедиа, запрос данных, извещение, подписка на событие, очередь? У некоторых авторов это называется "интеграционный стиль"
— На каком это протоколе? HTTP, HTTP/2, TCP с какой-то своей нашлепкой? И если HTTP, то только как транспорт, или по полной, как в REST? Протокол-то вообще бинарный или текстовый? И вообще, этот метод завязан на конкретный протокол, или может использоваться с разными?
— В каком формате передаем данные? Есть ли у этого формата схема? Строгая ли типизация в этом формате? Он плоский, или допускает вложенность? Насколько сложным по структуре может быть ответ?
— Если нам нужно преобразование данных, то есть ли штатные средства для этого?
— Что с обработкой ошибок? Можно ли определить и возвращать собственные коды ошибок и дополнительную информацию?
— Что с безопасностью? Аутентификация и разделение полномочий? Есть ли штатные средства? Или всё ограничивается TLS/SSL и OAuth?
— Что с производительностью, скоростью и гарантиями доставки?
— В чем мы это будем описывать, какие есть языки спецификаций и инструменты тестирования? Где мы эти спецификации храним и как обеспечиваем их актуальность?

И если мы берем какую-то совершенно новую технологию, нужно просто задаться всеми этими вопросами. И мы можем сравнить две технологии — дублируют ли они друг друга? Можно ли использовать на одном проекте RabbitMQ и Kafka? Что выбрать — GraphQL или gRPC?

В общем, кажется, схема работает. Про что ещё можно спросить в отношении технологий интеграции, чтобы сравнить их друг с другом?

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.


Share with your friend now:
tgoop.com/emacsway_log/1576

View MORE
Open in Telegram


Telegram News

Date: |

Choose quality over quantity. Remember that one high-quality post is better than five short publications of questionable value. Earlier, crypto enthusiasts had created a self-described “meme app” dubbed “gm” app wherein users would greet each other with “gm” or “good morning” messages. However, in September 2021, the gm app was down after a hacker reportedly gained access to the user data. How to create a business channel on Telegram? (Tutorial) The initiatives announced by Perekopsky include monitoring the content in groups. According to the executive, posts identified as lacking context or as containing false information will be flagged as a potential source of disinformation. The content is then forwarded to Telegram's fact-checking channels for analysis and subsequent publication of verified information. According to media reports, the privacy watchdog was considering “blacklisting” some online platforms that have repeatedly posted doxxing information, with sources saying most messages were shared on Telegram.
from us


Telegram emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
FROM American