@graphql_ru
GraphQL — русскоговорящее сообщество

Общаемся на темы, посвященные GraphQL и опыту его использования. Проблемы. Новости. Решения. Вам могут быть полезны: @apollo_ru, @react_js, @vuejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание в чате было полезным и комфортным.

352 members

Архив канала @graphql_ru 10 февраля 2018 г.

06:07:06 ПП
User 371133717
Где находится ваша логика авторизации на клиенте?
08:54:17 ПП
User 228403837
User 371133717
Где находится ваша логика авторизации на клиенте?
на клиенте ;)
08:54:38 ПП
User 371133717
Почему вы решили именно там?
08:54:49 ПП
User 228403837
а таки почему вы спрашиваете?)
08:54:56 ПП
User 228403837
вообще вопрос слишком общий
08:55:15 ПП
User 228403837
и второй вопрос тоже
08:55:50 ПП
User 228403837
например в react + redux у тебя будет компонент, который кидает экшен, который ловит хэндлер, который кидает экшен который ловит редьюсер ну и т.д.
08:56:16 ПП
User 228403837
в ангуляр приложении у тебя будет сервис, который если все ок прокидывает дальше, где ресолвер запрашивает сессию, и загружается компонент
08:56:19 ПП
User 371133717
в моем приложении авторизация происходит в двух местах.

Мне нужно авторизировать человека в блокчейне, а потом в бекенде
08:56:29 ПП
User 371133717
а еще у меня apollo-link-state
08:56:35 ПП
User 371133717
вы слышали что-то об этом?
08:56:47 ПП
User 228403837
User 371133717
а еще у меня apollo-link-state
понятия не имею что это и зачем оно надо. Я так и не засел разбираться с apollo
08:57:04 ПП
User 371133717
это redux/vuex на graphql
08:57:10 ПП
User 228403837
User 371133717
вы слышали что-то об этом?
тут весь вопрос - в чем разница. Ну то есть авторизация в блокчейне как мне кажется - это что-то противоествественное.
08:57:17 ПП
User 371133717
можно делать запросы к локальному стейту (кешу)
08:57:30 ПП
User 228403837
ну мол в моем понимании авторизация в блокчейне - это подпись транзакции которая полностью на клиенте происходит
08:57:55 ПП
User 228403837
ну либо у тебя какой-то свой блокчейн
08:57:56 ПП
User 371133717
но суть в том что в два места нужно отправить запросы
08:58:01 ПП
User 228403837
ну отправляй)
08:58:06 ПП
08:58:08 ПП
08:58:09 ПП
User 228403837
с redux у тебя может быть цепочка экшенов)
08:58:23 ПП
User 228403837
LoginInBlockchain -> LoginOnBackend
08:58:29 ПП
User 371133717
Я сейчас переписываю все приложение, и пытаюсь сделать нормальную архитектуру
08:58:40 ПП
User 371133717
пытаюсь понять где правильно хранить логику авторизации
08:58:44 ПП
User 371133717
в акшине redux
08:58:48 ПП
User 228403837
у тебя redux, так?
08:58:50 ПП
User 371133717
в модуле (моделе)
08:58:54 ПП
User 228403837
логика будет в хэндлерах (не в экшенах)
08:59:02 ПП
User 228403837
User 371133717
в модуле (моделе)
забудь слово "модель"
08:59:27 ПП
08:59:28 ПП
User 228403837
оно слишком общее, у тебя есть более конкретное - совокупность экшенов, хэндлеров и редьюсеров
08:59:54 ПП
User 228403837
User 371133717
можешь мне не рассказывать) от этого понятия не становится более конкретным.
08:59:59 ПП
User 228403837
у тебя есть вполне конкретные
09:00:09 ПП
User 228403837
не надо пытаться это все обобщать к сферическому MVC
09:00:10 ПП
User 371133717
User 228403837
оно слишком общее, у тебя есть более конкретное - совокупность экшенов, хэндлеров и редьюсеров
у меня нет redux, у меня есть его подобие на apollo, я сказал redux дабы упростить коммуникацию между нами
09:00:40 ПП
User 228403837
User 371133717
у меня нет redux, у меня есть его подобие на apollo, я сказал redux дабы упростить коммуникацию между нами
приведи псевдокодом логику работы с аполо
09:01:03 ПП
09:01:13 ПП
User 228403837
ну и если нет редакса - тебе понадобится нечто выполняющее роль "модели"
09:01:27 ПП
User 228403837
фу какая стремная штука
09:01:28 ПП
User 371133717
вы имеете ввиду модуль с бизнес логикой?
09:01:32 ПП
User 371133717
User 228403837
фу какая стремная штука
сам в шоке
09:01:45 ПП
User 228403837
User 371133717
вы имеете ввиду модуль с бизнес логикой?
логин - это не совсем бизнес логика
09:01:46 ПП
User 228403837
по сути
09:02:07 ПП
User 228403837
короч ладно, философию на тему разделения ответственности на потом оставим
09:02:14 ПП
User 371133717
а мне интересно
09:02:16 ПП
User 228403837
тебе надо разобаться с тем как ты хочешь построить флоу обработки данных
09:02:32 ПП
User 228403837
то есть компонент кого-то о чем-то просит, этот кто-то что-то уже делает
09:02:44 ПП
User 371133717
Я не уверен, но мне кажется написать все в AUTH_REQUEST неправильно
09:02:46 ПП
User 371133717
что вы думаете?
09:03:04 ПП
User 228403837
я думаю что у тебя не один AUTH_REQUEST
09:03:05 ПП
User 371133717
у меня будет компонент которые будет дергать AUTH_REQUEST с данными авторизации
09:03:07 ПП
User 228403837
а цепочка действий
09:03:17 ПП
User 371133717
и в компоненте чейнить?
09:03:30 ПП
User 228403837
компонент должен цепочку инициировать но вся она должна быть где-то в другом месте описана
09:03:50 ПП
User 371133717
благодаря вам я понял что хочу узнать
09:03:53 ПП
User 371133717
User 228403837
компонент должен цепочку инициировать но вся она должна быть где-то в другом месте описана
где
09:03:56 ПП
09:04:04 ПП
User 228403837
тут есть нюанс. Можно сделать двумя способами.
09:04:42 ПП
User 228403837
1. сделать функцию которая в себе весь этот алгоритм описывает. Это просто и удобно.
2. у тебя не будет одного места где есть вся цепочка и все будет строиться на событиях. Особо удобно со всякими rxjs но тут я слаб. Профит тут обычно для процессов которые любят меняться (требования то есть)
09:05:51 ПП
User 228403837
короч это ж тебе архитектура нужна)
09:06:08 ПП
User 228403837
помни только о том что "связанность модулей должна быть низкой а cohesion высоким")
09:06:28 ПП
User 228403837
ну и зависимости это не круто, а композиция практически всегда лучше наследования
09:07:17 ПП
User 228403837
ну и делай пока так что бы проще было разобраться через месяц
09:07:45 ПП
User 371133717
Архитектурно правильно и easy to reason about совместимо?
09:08:09 ПП
User 228403837
что ты подразумеваешь под "архитектурно правильным"?
09:08:25 ПП
User 371133717
User 228403837
ну и зависимости это не круто, а композиция практически всегда лучше наследования
применение этого и еще сотни других принципов
09:08:30 ПП
User 228403837
все что делается в плане архитектуры делается для того, что бы при изменении требований было дешевле править
09:08:52 ПП
User 228403837
если ты применяешь "паттерны" и проще и удобнее не становится - значит что-то явно не так пошло)
09:09:03 ПП
User 371133717
Если это не антипатерны)
09:09:14 ПП
User 228403837
не, обычно это паттерны которые запихнули просто так
09:09:32 ПП
User 228403837
короч pain driven development можешь юзать + писать тесты
09:09:36 ПП
User 371133717
Сергей
09:09:46 ПП
User 371133717
ты очень крутой мужик
09:09:53 ПП
User 228403837
не, я просто много говорю)
09:10:06 ПП
User 371133717
по делу же
09:10:14 ПП
User 371133717
User 228403837
короч pain driven development можешь юзать + писать тесты
впервые слышу про pdd
09:10:57 ПП
User 371133717
Можно in a nutshell?
09:14:49 ПП
User 371133717
Я сейчас TDD внедряю, это имеет что-то общее с PDD который вы назвали выше?
09:18:11 ПП
User 228403837
User 371133717
Можно in a nutshell?
если неудобно - подумай как сделать удобно. Если боли не вызывает - и так сойдет
09:18:36 ПП
User 228403837
* методология противопоказана людям с высоким болевым порогом