Нашествие

#whois Привет! Какой у вас проект или где работаете? - Фрилансер, сейчас работаю над backend для ios-приложения В чём вы специалист? - Опыт 4 года C# .NET, 2 года веб разработке(ASP.NET MVC, NodeJs) Чем можете быть интересны или полезны сообществу? - Возможно, ответами на вопросы Откуда вы? - Казань Как узнали про группу? - geektimes

#whois Привет! Какой у вас проект или где работаете? - Фрилансер, сейчас работаю над backend для ios-приложения В чём вы специалист? - Опыт 4 года C# .NET, 2 года веб разработке(ASP.NET MVC, NodeJs) Чем можете быть интересны или полезны сообществу? - Возможно, ответами на вопросы Откуда вы? - Казань Как узнали про группу? - geektimes

? Привет, земляк!

? Привет, земляк!

✌?

{ test: /jqueryplugins\/.+js$/, loader: "imports?this=>window,$=jquery,jQuery=jquery" }

А как ты их реквайришь

Уже сделал, спасибо

Друзья, прошу помощи ? Не могу разобраться как микросервисы авторизуют запросы к себе, это раз и второй вопрос как на примере того же чата можно организовать вывод сообщений из одного микросервиса сообющение и авторов из микросервиса identity? Буду благодарен за любую помощь (ссылки, советы). Заранее спасибо! Если чего нужно подробнее написать, пишите.

Друзья, прошу помощи ? Не могу разобраться как микросервисы авторизуют запросы к себе, это раз и второй вопрос как на примере того же чата можно организовать вывод сообщений из одного микросервиса сообющение и авторов из микросервиса identity? Буду благодарен за любую помощь (ссылки, советы). Заранее спасибо! Если чего нужно подробнее написать, пишите.

Токены например

Это понятно, jwt например для этого можно использовать. Интересует именно реализация... как прикручивается то это?

у меня микросервисы в докере в оверлей сети, снаружи не доступны - авторизации нет, есть прокидывание токена юзера

Ну например: есть gateway, он обращается к микросервису Articles. Как Articles поймет, что ему можно эти данные отдать?

у меня микросервисы в докере в оверлей сети, снаружи не доступны - авторизации нет, есть прокидывание токена юзера

? Не гуд, хочется следовать принципу AWS. А конкретно: - микросервис должен быть таким, чтобы в любой момент времени его можно было открыть в публичный доступ. Сейчас попробую найти источник

Это понятно, jwt например для этого можно использовать. Интересует именно реализация... как прикручивается то это?

Хороший старт https://github.com/mfornos/awesome-microservices/blob/master/README.md#security

Oauth2 тоже подойдёт да

товарищи, подскажите что делаю не так. ссыль - https://repl.it/FeK5/0

Await и промисы, логично) Писать через прототипы в es6, имея классы - логично))

Oauth2 тоже подойдёт да

А конкретной реализации нет в общем досутпе, чтобы посмотреть, как это у других сделано?

А конкретной реализации нет в общем досутпе, чтобы посмотреть, как это у других сделано?

Не думаю. Просто примени стандарт

у меня микросервисы в докере в оверлей сети, снаружи не доступны - авторизации нет, есть прокидывание токена юзера

Все сервисы одинаково токен обрабатывают? Т.е. это какая-то библиотека?

Все сервисы одинаково токен обрабатывают? Т.е. это какая-то библиотека?

Они его обрабатывают по необходимости. Но да, есть щареды между всеми МС которые помогают обрабатывать, например, возможность доступа этого юхера к какому-то документу

Все сервисы одинаково токен обрабатывают? Т.е. это какая-то библиотека?

У тебя есть микросервис проверки прав?

у меня микросервисы в докере в оверлей сети, снаружи не доступны - авторизации нет, есть прокидывание токена юзера

Еще такой вопрос, как решается проблема вывода пересекающихся данных? Пример чат: - сервис сообщений & авторы - сервис identity

не понял вопрос

не понял вопрос

Вывод на интерфейсе информации из двух микросервисов в один блок: Вижу решение влоб: - первым запросом получили список сообщений к микросервису сообщений - вторым получаем имена авторов по их authorId-userId

Можно в сообщениях кешировать авторов и не делать второй запрос

У тебя есть микросервис проверки прав?

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

Скорее логичнее наоборот, как мне кажется

Я сторонник портить третью нормальную форму, да

Вот возможно я заблуждаюсь, поправьте, если моё виденье ошибочно. Рассмотрю на примере чата: 1. Есть сервис самого чата, в нем сообщения и ИД авторов, ничего не знает об авторах (изолированно) 2. Есть сервис Identity, который знает всех пользователей 3. Есть микросервис для сбора вью под это всё дело, т.е. самомстоятельный блок чата, который можно запихнуть куда хочешь. 4. Есть gateway - который собирает страницу, если ему нужен чат, он делает запрос к микросервис №3 (выше). При таком подходе зависимость копонентов идет снизу вверх (или наоборот ? ), т.е. микросервисы на одном уровне ничего не знаю друг о друге, так сказать архитектура слоеного пирога.

Это уже какие-то нано сервисы... На пересылке данных туда сюда гигантские потери будут же

Сейчас всё таки найду ссылку про AWS... ?

Да не, я много читал, и с авс в том числе

Просто вот у меня, если следовать модели наносервисов, будет уже не 31 микросервис, а 310 а то и больше. оно мне надо?

Сейчас всё таки найду ссылку про AWS... ?

не ну ты не стесняйся, кидай0

Так не, здесь всего 3 уровня: 1. точка сборки всей страницы 2. точка сборки компонента страницы 3. микросервисы

У меня спа - я страницу не собираю.

В промышленных системах, построенных на Микросервисной архитектуре, число компонентов растет быстро — поговаривают, что в Амазоне в рендеринг страницы вовлечены порядка 150 сервисов. Про рендеринг страницы: https://habrahabr.ru/post/280786/

У меня спа - я страницу не собираю.

?

single page application

не ну ты не стесняйся, кидай0

А вот про принципы AWS не нашел еще ? Очень много информации перебрал за последнюю неделю...

single page application

Тогда 1 уровень на клиенте поулчается. Т.е. минус один сервис...

Поясню для чего вообще такой подход мне кажется целесообразным: 1. микросервис может использоваться из проекта в проект без модификаци 2. вызывать микросервис в таком подходе можно под разными точками, т.е. в одному случае микросервис дергаем, чтобы показать блок на странице, во втором случае, чтобы сгенерировать ответ мобильному приложению, в третьем случае поддержка открытого API.

1) не верю 2) да, не проблема

2) Всё будет в одном микросервисе?

2) Тебе никто не мешает иметь денормальхованную форму как дополнение и имеить можификатор запроса который будет указывать - брать кешированое значение или зхапросить заново

2) не понял... это же разные формы ответа

2) Но у меня в одном МС находится больше чем одно действие, да

2) не понял... это же разные формы ответа

Формы ответа - одинаковые

2) Так я ж и говорю, что это позволяет их для каждого свои давать...

Формат ответа меняется в зависимости от вызванного эндпоинта, это нормально. Но выборку данных ты же не будешь делать разную? Просто отформатируешь как надо?

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

Формат ответа меняется в зависимости от вызванного эндпоинта, это нормально. Но выборку данных ты же не будешь делать разную? Просто отформатируешь как надо?

Верно

2) Но у меня в одном МС находится больше чем одно действие, да

А микросервисы знают друг о друге?

Да, конечно

Как иначе они будут общаться?

?

мне не нравится модель единой точки отказа - гейтвея

?

мне не нравится модель единой точки отказа - гейтвея

getway может быть в кластере

Ну и опять таки - гейтвей подразумевает что у тебя все запросы идут через него. И когда ты сидишь на дешманских тарифах - гигабит быстро заканчивается

ERROR: S client not available

Ну и опять таки - гейтвей подразумевает что у тебя все запросы идут через него. И когда ты сидишь на дешманских тарифах - гигабит быстро заканчивается

Да это понятно, что clientside сборка выигрывает здесь, но как быть с СЕО тогда?

А гендиру я просто ничего не говорю - это не его проблемы о.О

???

Ты сделал мой день!

Не, реально, нахрена ему знать нюансы архитектуры?

Да так то да ? Но как-то не хорошо, когда известно о таком "нюансе" ?

На самом деле я ожидал услышать, что современные поисковые системы умеют подхватывать ajax изменения страницы ?

О,о я тебя не понимаю. Почему? Что такого плохого в отсутствие гейтвея?

Почему это парит гендира? Что вообще происходит?

Стой стой, я понял в чем проблема

У микросервисов должен быть гейтвей

Извини по-русски написал SEO

Иначе это что то другое

Гейтвей для меж-мс запросов?

Нет, гейтвей для запросов снаружи

Да, для запросов снаружи он естественно есть.

Я про меж-мс гейтвей

А, ну, это другое

Нет, гейтвей для запросов снаружи

И на нём лежит задача первичной авторизации, проксирования из приватной сети наружу, определение начальной точки входа и тд

Да, да

Извини по-русски написал SEO

А, понятно. Ну так тебе никто не мещает тогда ренжерить на сервере спа - поставиь после гейтвея несколько рнедереров и пускай трафик через них

Стало тяжко - добавил еще рендереров - они тупые должны быть, тупо рендерить реакт

Я про меж-мс гейтвей

Так, вы меня сейчас запутали... ? Т.е. вы настаиваете, что: - чтобы собрать блок с чатом нам не нужно обращаться к gatway, мол дай нам блок с чатом на страницу? А делать запрос напрямую к микросервису чата?

Так, вы меня сейчас запутали... ? Т.е. вы настаиваете, что: - чтобы собрать блок с чатом нам не нужно обращаться к gatway, мол дай нам блок с чатом на страницу? А делать запрос напрямую к микросервису чата?

спа должен ходить за данными

давайте разделим на две части - запрос снаружи и что происходит внтури

но никак за куском страницы

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

аг