DS
Там же уже есть карта микросервисов
Size: a a a
2020 May 13
AD
так я не спрашивал где есть и нет карты микросервисов 🙂
AD
мне просто интересно найти адекватный формат описания комуникаций что бы это работало
DS
так я не спрашивал где есть и нет карты микросервисов 🙂
Просто интересно чего не хватает в готовых решениях и в чем боль
AD
боль в том, что не понятно как это описать адекватно
AD
если говорить про дата дог, они строят информацию по трафику, а мне это не очень интересно
AC
народ, я тут задумался о варианте описания всех коммуникаций сервисов, хочу иметь довольно простой и маштабируемый формат, в котором можно будет описать 90% всех возможных комуникаций между частями системы, пока додумался до такого формата (это ямл, но в целом не имеет значения, json, yaml, xml или что еще это будет)
communications:
- type: http/rpc/event-producer/event-consumer
target: service/kafka/rabbitmq/etc
# optional fields
critical_rate: critical/uncritical
resource: topic-name/rpc-resource/rest-resource/gqlschema
custom_data:
# can be anything
# events:
# - test-event
# version: 2
интересно мнение и если видите проблемы тут - показать где я не прав
communications:
- type: http/rpc/event-producer/event-consumer
target: service/kafka/rabbitmq/etc
# optional fields
critical_rate: critical/uncritical
resource: topic-name/rpc-resource/rest-resource/gqlschema
custom_data:
# can be anything
# events:
# - test-event
# version: 2
интересно мнение и если видите проблемы тут - показать где я не прав
1. А под ресурсом имеется в виду конкретный вид ресурса, напр., пользователь/пост? Если один сервис использует штук 20-30 эндпоинтов от другого, для каждого нужен будет отдельный элемент в communications, или стоит поддерживать массив resources вместо одиночного resource?
2. А graphql не является ли больше типом взаимодействия? А то конкретный ресурс к нему сложно привязать, если только в значении "сервис А имеет доступ через graphql к таким-то ресурсам сервиса B"
2. А graphql не является ли больше типом взаимодействия? А то конкретный ресурс к нему сложно привязать, если только в значении "сервис А имеет доступ через graphql к таким-то ресурсам сервиса B"
AD
1. А под ресурсом имеется в виду конкретный вид ресурса, напр., пользователь/пост? Если один сервис использует штук 20-30 эндпоинтов от другого, для каждого нужен будет отдельный элемент в communications, или стоит поддерживать массив resources вместо одиночного resource?
2. А graphql не является ли больше типом взаимодействия? А то конкретный ресурс к нему сложно привязать, если только в значении "сервис А имеет доступ через graphql к таким-то ресурсам сервиса B"
2. А graphql не является ли больше типом взаимодействия? А то конкретный ресурс к нему сложно привязать, если только в значении "сервис А имеет доступ через graphql к таким-то ресурсам сервиса B"
1. хороший вопрос, думаю оно должно быть массивом, потом что ты не только с одной очередью/топиком работать можешь. так же и с ресурсами в синхронных коммуникациях, я думаю
2. сложно сказать, для меня gql это все же язык запросов, транспортный слой то любой может быть (как http, так и просто память), под ресурсом тут я подразумеваю название gql схемы с которой работать стоит
2. сложно сказать, для меня gql это все же язык запросов, транспортный слой то любой может быть (как http, так и просто память), под ресурсом тут я подразумеваю название gql схемы с которой работать стоит
AC
А в случае http/rpc стоит указывать, просто вытаскиваются данные из другого сервиса или добавляются/изменяются?
AC
Это может быть важно для понимания, откуда куда идут данные
AD
думаю, что это можно в
custom_data добавитьAC
Ещё, если я правильно понимаю логику, то "critical_rate" имеет смысл переименовать в "criticality_rate" или просто "criticality". Иначе вместо "рейтинга критичности" получается "критичный рейтинг"
AD
Ещё, если я правильно понимаю логику, то "critical_rate" имеет смысл переименовать в "criticality_rate" или просто "criticality". Иначе вместо "рейтинга критичности" получается "критичный рейтинг"
Ага, тоже верно
AC
Ну, т.е. rate не "рейтинг" переводится, но ты понял
AD
ага, спасибо!
2020 May 14
VZ
всем привет. возникла задача подбора Rails-based CMS для нового проекта, Rails 6 + UJS, Postgres.
из того, что я пока понял:
Refinery практически мертва, Locomotive на Mongo - отпадают. наиболее обещающе выглядит ComfortableMexicanSofa, но появились и новые игроки (Alchemy, Spina, Fae), про которых я вообще ничего не знаю. и некоторые давно известные, но не мне (Camaleon, RadiantCMS).
кто может поделиться опытом, что юзали, какие проблемы возникали, какие бенефиты?
из того, что я пока понял:
Refinery практически мертва, Locomotive на Mongo - отпадают. наиболее обещающе выглядит ComfortableMexicanSofa, но появились и новые игроки (Alchemy, Spina, Fae), про которых я вообще ничего не знаю. и некоторые давно известные, но не мне (Camaleon, RadiantCMS).
кто может поделиться опытом, что юзали, какие проблемы возникали, какие бенефиты?
AD
я очень давно софу использовал, мне в целом нравилась, но у меня опыт 5ти летней давности
IN
Рельс, который родился из мифов Блог (aka CMS) за 15 минут и "я сам за пару часов соберу CMS с нужным функционалом" Обосрался по полной и не смог родить ни одного конкурента WordPress или PHPBb. Нужна CMS? Идите в пхп. Тут рыбы нет.
VA
Я понимаю ещё использование ActiveAdmin. Но CMS - для обычного сайта.. Дольше разбираться в нём. Проще самому написать с помощью рельс.
w
Рельс, который родился из мифов Блог (aka CMS) за 15 минут и "я сам за пару часов соберу CMS с нужным функционалом" Обосрался по полной и не смог родить ни одного конкурента WordPress или PHPBb. Нужна CMS? Идите в пхп. Тут рыбы нет.
ну почему же, просто они никому не нужны в эпоху конструкторов сайта типа тильды. Зачем самому собирать, если можно заюзать готовые решения, к которым уже платежки и магазины прикручены