А ты уже сверяешь твиттерид с тем что у тебя в бд и понимаешь кто залогинелся

В первую очередь потому, что это естественный этап в развитии кода

как вы пришли к микросервисам вообще? У меня реальная проблема здесь)

суббота, какая разница что обсуждать, а с умными людьми-то

А переход к тому что ты описываешь не имеет никакого профита

ты про jwt или границы транзакций?)

мне все равно нужно в своей таблице юзеров создать для него запись

Можно запросить у твиттера почту юзера и сохранять по почте

А ты уже сверяешь твиттерид с тем что у тебя в бд и понимаешь кто залогинелся

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

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

Загугли OAuth 2

и я бы не назвал это усложнением

В например у меня юзеры существуют в только в рамках api

В микросервисах их вообще нет

постепенно чуваки от монолита хорошенько отпиливали куски, которые надо было резко скейлить

Никакой авторизации, ничего

Это просто кусок кода, который что делает, не важно для кого и почему

ну у тебя получается есть центральная точка отказа

Более того, достаточно важно что два разных микросервиса не должны работать с одними и теми же данными

сервис авторизации

ну у тебя получается есть центральная точка отказа

Нет конечно

ну тогда я опять не понял(

API gateway полностью stateless

Их столько, сколько хочется

так а как он авторизирует?

jwt?))))

Загугли OAuth 2

гугл выдает подробности по тому как это внутри работает. Мне это в общем-то не надо знать, потому что за меня эту низкоровневую задачу делает либа (grant)

так а как он авторизирует?

Берет токен из запроса и идет в БД

ахахах, низкоуровневый OAuth 2

))))

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

Берет токен из запроса и идет в БД

ну чет не очень стейтлес

ахахах, низкоуровневый OAuth 2

что не так?

гугл выдает подробности по тому как это внутри работает. Мне это в общем-то не надо знать, потому что за меня эту низкоровневую задачу делает либа (grant)

Так ты и должен знать что там происходит. Что бы знать что сохранять

Ну БД не стейтлесс, да

Было бы странно если бы БД была стейтлесс

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

или еще че

ну т.е. фронт, который чуть сложнее, чем прокся

Растет только нагрузка на базу

это бывает неудобно

Она растет всегда и в любом случае

Это элементрано решается кэшированием

в случае микросервисов у тебя под каждый сервис своя база

Так и есть, условно

ну или что-то изолированное

как это организованно - деталь реализации

но ты можешь их скейлить вместе, грубо говоря

а тут надо еще скейлить всегда "центральный сервис"

это часто не проблема, но бывает проблема

тогда и нужен jwt

jwt это трэш

Неоднократно поднимался вопрос

Оно убивает безопасность

тогда и нужен jwt

или другой стейтлес-токен

Оно убивает безопасность

ну понятно, что у тебя рефреш токены стейтфул будут

а стейтлес на короткий срок

Это делает авторизацию слишком сложной на клиентской стороне

вопрос в том, чтобы экономить в 95% запросах время на хождение за инфой сессии куда-либо

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

Это делает авторизацию слишком сложной на клиентской стороне

так опять же, вопрос экономики, если на клиенте это решать в итоге дешевле, то так и надо делать

такие случаев КРАЙНЕ мало

но они есть

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

Строить такую систему дороже

При этом можно наделать катастрофических ошибок

она могла появиться эволюционно и так на каком-то этапе стало делать тупо дешевле

всегда можно наделать ошибок

ERROR: S client not available

Единое АПИ является максимально простым и надженым вариантом

я всего-лишь говорю, что это не всегда так

Я думаю всегда

когда тебе надо скейлить один единственный сервис, то проще скейлить только его

или группу сервисов

а еще бывает, что оно скачет очень сильно

сегодня одна группа, завтра другая, послезавтра обе

ну типа так бывает)

Это наоборот аргумент в пользу единого gateway

почему?

Т к на него нагрузка всегда ровнее

Ему все равно, какое распределение между запросами

и это может быть не так, например в случае послезавтра)

Условно говоря, ты скейлишь gateway пропорционально общей активности пользователей

Есть aws elb + socket.io?

Микросервисы пропорционально активности использования конкретных функций

Как решаете проблемы привязки?

или не скейлить gateway авторизационный, а скейлить только микросервисы

Так вряд ли может быть

http://microservices.io/patterns/apigateway.html

Using an API gateway has the following benefits: Insulates the clients from how the application is partitioned into microservices Insulates the clients from the problem of determining the locations of service instances Provides the optimal API for each client Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also means less overhead and improves the user experience. An API gateway is essential for mobile applications. Simplifies the client by moving logic for calling multiple services from the client to API gateway

http://microservices.io/patterns/apigateway.html

почитаю, спасибо

спасибо ребят вы такие отзывчивые

(на самом деле нет)

нашел здесь что искал http://stackoverflow.com/questions/10100231/sign-in-with-oauth-what-should-i-store-use-to-identify-the-user

А ты думал тут помогают решать проблемы? :)

my bad

теперь знаю что нет

Подскажите годный пакет для создания CLI.

Пакет яровой

есть пакет который форматирует sql запрос и раскрашивает, но для вывода в консоли?

Я как-то тоже не представляю микросервисы без гейтвея