🏋
Size: a a a
2020 November 24
🏋
На этом канале хорошо рассказывают про неткод
k
Афигенный канал. Пасибо!
k
ВОУ, автор этого канала говорит что WoW Classic юзал TCP. Неудивительно зачем они добавили Leeway. Но круто
2020 November 25
a
Всем привет, вопрос в архитектуре микросервисов. Возможно не туда. Поправьте если так. Есть три задачи:
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД
PR
Всем привет, вопрос в архитектуре микросервисов. Возможно не туда. Поправьте если так. Есть три задачи:
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД
1) Аутентификация и выдача токенов.
2) Восстановление пароля, путем отправки проверочного кода смс и его верификации
3) Регистрация пользователя
По сути всем трем сервисам необходимо так или иначе заглядывать в одну БД с таблицей Accounts...
Первый сервис проверяет истинный логин и пароль
Второй - меняет пароль
Третий - добавляет новую запись.
Как же быть, если микросервисы должны быть изолированны друг от друга? Или же допустимо использовать одну БД
а вам точно надо на три этих роли три разных сервиса?
a
а вам точно надо на три этих роли три разных сервиса?
Не уверен. Хорошо. Тогда проблема с endpoints.
1. api/auth/token, api/auth/refresh-tokens
2. api/restore/
3. api/registration
1. api/auth/token, api/auth/refresh-tokens
2. api/restore/
3. api/registration
a
Как бы их уместить в один уровень
a
auth/restore и auth/registration - ?
2020 November 26
S
Как бы их уместить в один уровень
/api/auth/<action>*
и это явно один сервис который занимается авторизацией
и это явно один сервис который занимается авторизацией
S
и да, он может ходить в другой сервис для рассылки почты (исползование api amazon SES это и есть ходить в другой сервис)
S
название =) зомби-люда =)))
S
интересно конечно. где они живой intel GPU нашли
их же мало выпускается
их же мало выпускается
MB
It works with current integrated Intel UHD GPUsS
It works with current integrated Intel UHD GPUsой, ну значит прикольная интересная штука =) нейронки на офисных пнях гонять
a
/api/auth/<action>*
и это явно один сервис который занимается авторизацией
и это явно один сервис который занимается авторизацией
POST /api/account - тоже сервис, занимается созданием пользователя. Но как тогда быть, если /api/auth нужна БД с users и /api/account
S
POST /api/account - тоже сервис, занимается созданием пользователя. Но как тогда быть, если /api/auth нужна БД с users и /api/account
это вам к DDDшникам =) я к сожалению тупой и этого не осилил
во всех этих микросервисах все плохо с базами данных. обычно ВСЕГДА =)
но вообще POST /api/account должен быть скорее POST /api/profile
и userid который нужен и там и там. вообще должен каким нибудь sonyflake time based аглоритмом генерироваться
и если authorization это какой нибудь tarantool в который в итоге генерит какой нибудь аналог JWT токена
то profile может быть уже другим сервисом с другой БД (MySQL \ PostgreSQL \ tarantool) из которой уже выгрузку в clickhouse можно сделать аналитическую инкрементально по "дате изменения"
во всех этих микросервисах все плохо с базами данных. обычно ВСЕГДА =)
но вообще POST /api/account должен быть скорее POST /api/profile
и userid который нужен и там и там. вообще должен каким нибудь sonyflake time based аглоритмом генерироваться
и если authorization это какой нибудь tarantool в который в итоге генерит какой нибудь аналог JWT токена
то profile может быть уже другим сервисом с другой БД (MySQL \ PostgreSQL \ tarantool) из которой уже выгрузку в clickhouse можно сделать аналитическую инкрементально по "дате изменения"