Можно вообще sonic заюзать. Но у меня был кейс когда sonic не завелся на проде, что очень странно.

Мб у вас процы поменяли

В protobuf есть тип union. Интересно глянуть как он jsonом маршалится. А ну хотя тамж другой маршалер. Мб protobuf заюзать)) раз он умеет

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse); Типо как в примере На вход стриминговый тип на выход обычный

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

быстрее написания кода мало что поможет освоиться. Лучше что-то писать. Пет проект, да

минимально включи в него: веб-сервер бд заверни в докер и выложи в кубер локально развернутый Это будет хороший проект. Остальное по желанию. Можешь редис прикрутить например

kubernetes - плохо представляю что это. Только термины читал в гугле)) Стоит сразу включать в проект тоже? или это для начала будет слишком?

kubernetes - плохо представляю что это. Только термины читал в гугле)) Стоит сразу включать в проект тоже? или это для начала будет слишком?

минимально включи в него: веб-сервер бд заверни в докер и выложи в кубер локально развернутый Это будет хороший проект. Остальное по желанию. Можешь редис прикрутить например

kubernetes - плохо представляю что это. Только термины читал в гугле)) Стоит сразу включать в проект тоже? или это для начала будет слишком?

Запустил под дебагом и увидел, что перебирая элементы массива и определяя их тип, он определяется как reflect.Interface{}, почему так?

Вечер добрый, господа. Пишу на gin/gonic upload-download image сервис и встретился с проблемой, что не отрисовываются img. Могу кинуть ссылку на репу, не могли бы подсказать в чем проблема? router.Static не помогает, в обычном http картинка есть, а при запуске сервера - нет, хотя пасник лежит верный, судя по консоли

Народ, всем привет! Вопрос по взаимодействию сервисов. Есть сервис Realty, который управляет адресной базой и связанными с ней вопросами - один Bounded Context. Есть сервис Owners, который управляет информацией о собственниках недвижимости - второй Bounded Context. У Realty есть API администрирования, которое по сути CRUD и позволяет: - получать список недвижки (с разным фильтрами); - получать данные конкретного объекта по ID; - изменять объект по ID; - добавлять объект. У Owners есть аналогичный CRUD-API для, соответственно, собственников. Оба API закрыты JWT-токенами. Для работы с Realty у пользователя должна быть роль realty-admin, для работы с Owners - owners-admin. Но при этом когда в Owners добавляется или изменяется собственник, одним из его параметров является список ID объектов недвижки этого собственника. Возникает необходимость следующего: - банально проверить, что такая недвижка есть; - забрать часть её данных для дальнейшей обработки в логике Owners. Для этого сервис Owners должен стучаться в Realty. И тут возникает вопрос с авторизацией. Если Owners придёт в Realty с токеном пользователя, у которого нет роли realty-admin, то не сможет выполнить чтение недвижки и, соответственно, добавление/изменение собственника. Не айс, потому что тогда при выставлении роли owners-admin будет всегда требоваться выставление realty-admin и предоставление доступа к совершенно левому Bounded Context. Если Realty будет позволять делать поиск недвижки по роли owners-admin, то в него протечёт зависимость из другого сервиса. А таких сервисов в теории может быть много разных. Плюс теоретически пользователь без доступа к Realty сможет выполнять запросы на поиск недвижки, если узнает об этой особенности. Тоже не айс. Если заводить отдельную роль realty-read, то надо не забывать проставлять её всем, у кого есть owners-admin - получится примерно такое же протекание зависимости, но в другую сторону. Вопрос: как правильно организовать проверку доступа к списку недвижки в Realty при межсервисном взаимодействии? Желательно с передачей информации о пользователе, который инициировал оригинальный запрос, потому что в аналогичном сценарии с другими сервисами будут write-операции. Пилить отдельный API для внутрянки? Использовать другую схему авторизации для внутрянки? Спасибо!

Микросервисы или монолит? Может быть создать еще один api с доступом уровня owner для предоставления данных о недвижке в том объеме, в котором пользователь с owner-доступом не сможет воспользоваться информацией о недвижке? Просто здесь решения надо принимать, исходя из многих факторов, которые не описаны

Микросервисы. Не хотелось бы в логике недвижки даже упоминать owner, потому что это сделает coupling менее loose 😊 И в дальнейшем к сервису Owners добавятся ещё несколько. Каждому по API выглядит не очень удобно.

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

Вообще, тоже склоняюсь к приватному каналу общения для микросервисов. Придумалось такое: сделать API, аналогичное "публичному", но за middleware, который игнорирует роли в jwt-токене, но проверяет наличие внутреннего preshared-токена в кастомном заголовке, чтобы удостовериться, что вызывающая сторона - наш сервис. Или вообще вместо jwt-токена передавать просто кортеж из ID пользователя, ID сессии и всего прочего полезного из payload. Но по ощущениям как-то кривенько. Хотя, может быть, достаточно хорошо?

Неужели никто не выносил эту тему на какой-нибудь конференции? Ведь про микросервисы многие говорят, Проблема взаимодействия должна стоять достаточно остро. Думаю, что озвученный путь на первый взгляд - оптимальный. Этот как с алгоритмами - вроде есть просто и понятный алгоритм решения задачи, а потом читаешь про какой то алгоритм, который проще, с меньшим О(), но не тривиальный, до которого сразу не додумаешься. Я бы погуглил эту тему и скорее всего в англоязычном сегменте, а пока двигался по вышеописанному пути

Я гуглил. Советуют примерно то же самое с разными вариациями, в основном в сторону асинхронных взаимодействий на базе RabbitMQ и прочих кафк. Сюда написал именно в надежде на тот самый нетривиальный, но более простой способ 😊 Ну или на примеры имплементаций, или на статьи/доклады. Взаимодействие пока точно будет синхронное через API. Не хочется делать лишних нагромождений. Отдельный HTTP-endpoint с другой схемой авторизации, например, или вообще GRPC - возможно, это усложнения, которых можно избежать без вреда для решения задачи.

у меня взаимодействие между сервисами сделано через grpc (с шифрованием трафика), но api внутренний, только для организации, так что мне проще)

Потому что это нужно самому делать, без reflect : type mess struct {key interface{} "json:k"} После unmarshal пробуешь перебором в рантайме приводить тип

Я гуглил. Советуют примерно то же самое с разными вариациями, в основном в сторону асинхронных взаимодействий на базе RabbitMQ и прочих кафк. Сюда написал именно в надежде на тот самый нетривиальный, но более простой способ 😊 Ну или на примеры имплементаций, или на статьи/доклады. Взаимодействие пока точно будет синхронное через API. Не хочется делать лишних нагромождений. Отдельный HTTP-endpoint с другой схемой авторизации, например, или вообще GRPC - возможно, это усложнения, которых можно избежать без вреда для решения задачи.

Приведение типа это float64(i), var.(float64) - это утверждение типа или type assertion. И все же зачастую лучше сделать кастомный анмаршалинг, иначе потом с этой структурой работать тяжело будет. Во всех местах, где понадобится значение из структуры взять, придется ассертить тип - то еще удовольствие.

Как говорится "Я не доктор, но тоже могу посмотреть". (хотя очень хочется отморозиться...)

Если рост планируется, то возьми nats, в принципе позволяет паттерны Request-Reply, при этом будет единый endpoint, без головняка, какой микросервис на каком порту запущен и во сколько инстансов. Он на go написан, позволяет повторно обрабатывать сообщения, которые, например, были получены, но не были обработаны из-за падения сервиса.

Или я может неверно понял вопрос?

Все не так просто. Все очень сложно. Мне хочется посмотреть, спать и компотика.

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

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

может кто-то объяснить новичку, в чем принципиальное отличие от буферизированных и небуферизированных каналов?

English please

Ок

English please

نحن نتحدث العربية سخيف