И всё-таки, тогда как обозвать используемый мной подход?
Практика-то довольно распространённая. Есть несколько бэкендеров, у них разная зона ответственности, поэтому они на каждую предметную область заводят свой репозиторий, используя при этом одну БД.
У этого же есть какое-то название? Почему это не может быть микросервисом?
Обязательно ли микросервису иметь выделенную БД, что бы называться микросервисом? Если у меня два, как я их называю, микросервиса, используют одну БД, то как они называются?
К примеру, один из них отвечает за регистрацию/авторизацию, а другой за обработку платежей
Я пробовал использовать его в идее, но что бы использовать хоткеи для рефакторинга, приходится зажимать дополнительно клавишу fn. Подскажете, как пофиксить это?
Из моего опыта разработки клиентской части, что в геймдеве, что в вебе данные удобнее хранить в одном месте (классе) и не писать там больше дополнительного функционала, кроме самого основного (отписки/подписки)
А можно конкретные примеры — почему удобнее? Чем централизованное хранилище лучше децентрализованного, разбитого на модули?
К примеру, наш FriendsService подписан на socket событие friends:state, в котором прилетает состояние списка. Мы стоим перед выбором — записать список в глобальный стор, либо в this.state.
Почему мы должны выбрать глобальный стор для этой цели?
Также интересует вопрос — как быть, если приложение разделено на изолированные модули, подгружаемые с помощью LazyLoading? Только что загруженный модуль должен использовать глобальное состояние для хранения своих данных?
Я уже который год пытаюсь осознать смысл Redux. После прочтения вашей статьи мои сомнения в нём только усугубились.
1) Почему мы не можем хранить состояние списка друзей в синглтоне FriendsService? При таком подходе данные всегда будут синхронизированы во всех компонентах, использующих список друзей.
2) Почему запросом данных и передачей их в хранилище занимается компонент списка друзей? Что, если у нас два компонента для рендеринга этого списка — один в разделе «Мои друзья», другой в модальном окне «Поделиться записью», выглядят совершенно по-разному. Каждый компонент должен проверять наличие данных в состоянии, и грузить их, если они отсутствуют? Дублирование кода же.
3) У нас же real-time приложение. По сокетам прилетает событие, мол, новый друг добавлен в список, или удалён из него. Где это обрабатывать? Самый логичный вариант — этим должен заниматься тот самый синглтон FriendsService.
В чём преимущество Redux перед описанным мной подходом?
Кто-нибудь, пожалуйста, ответьте мне на эти вопросы. Я чувствую себя неполноценным членом Front-end сообщества из-за непринятия Redux.
Я как-раз во второй части статьи перестал понимать, что происходит, из-за минификации. Действительно, лучше приводить полный, читаемый код, но количество символов в нём учитывать уже после минификации, раз уж статья для читателя, а не js-интерпретатора :)
Да с чего вы взяли-то, что они неправильные?! Вы бы прежде, чем на хабр писать такие вещи, поинтересовались бы, что это за кавычки такие.
Это template strings developer.mozilla.org/ru/docs/Web/JavaScript/Reference/template_strings
Код, указанный в данном разделе теста, абсолютно валиден.
Действительно, это очень важное замечание. Всё-таки яндекс аккаунт — слишком большой монстр, с кууууучей сервисов, привязанных к нему, и данных, которые не хотелось бы лишний раз светить. Лично я из ваших сервисов использую почту и деньги. И каждый раз я делаю логин-дела-логаут.
На таком сайте, как кинопоиск, мне хотелось бы наоборот, как можно реже вводить данные для входа. У меня там ничего конфиденциального нет, да и не может быть.
Поправка. Там нет виджетов. Там есть ссылки. Сама страница во внешний мир никаких запросов не делает, и сервисы эти ничего не знают.
Единственное, что могло бы произойти, будь там http, это передача заголовка referer когда на ссылку кликнули. Но там https, он этот заголовок не передаёт. Здесь никакой проблемы/дыры нет.
Отредактируйте пост, а то народ в заблуждение вводите :)
Я ТКС ни в коем случае не защищаю, и комментарий Natalia Lutay, сотрудника банка, который она выдвигает «с уверенностью», выглядит как детский лепет. Мне даже стыдно стало. Хотя опозорилась она. Налицо подмена тезиса.
Если злоумышленник имеет доступ к почте, в любом случае он имеет доступ к выписке.
Да, но ранее это можно было сделать имея ТОЛЬКО доступ к почте. Сейчас это можно сделать кучей других методов. Да даже банально подсмотреть/сфотографировать адрес. Я уже молчу про историю браузера, которую может найти жена, и узнать, что её муж просаживает в баре половину зарплаты.
Ещё проблема — это индексация недобросовестными поисковиками, следящими за пользователями с помощью браузеров. Если данные утекут в какую-нибудь поисковую систему, узнаем, кто и насколько нагло за нами следит.
Практика-то довольно распространённая. Есть несколько бэкендеров, у них разная зона ответственности, поэтому они на каждую предметную область заводят свой репозиторий, используя при этом одну БД.
У этого же есть какое-то название? Почему это не может быть микросервисом?
К примеру, один из них отвечает за регистрацию/авторизацию, а другой за обработку платежей
А можно конкретные примеры — почему удобнее? Чем централизованное хранилище лучше децентрализованного, разбитого на модули?
К примеру, наш FriendsService подписан на socket событие friends:state, в котором прилетает состояние списка. Мы стоим перед выбором — записать список в глобальный стор, либо в this.state.
Почему мы должны выбрать глобальный стор для этой цели?
Также интересует вопрос — как быть, если приложение разделено на изолированные модули, подгружаемые с помощью LazyLoading? Только что загруженный модуль должен использовать глобальное состояние для хранения своих данных?
1) Почему мы не можем хранить состояние списка друзей в синглтоне FriendsService? При таком подходе данные всегда будут синхронизированы во всех компонентах, использующих список друзей.
2) Почему запросом данных и передачей их в хранилище занимается компонент списка друзей? Что, если у нас два компонента для рендеринга этого списка — один в разделе «Мои друзья», другой в модальном окне «Поделиться записью», выглядят совершенно по-разному. Каждый компонент должен проверять наличие данных в состоянии, и грузить их, если они отсутствуют? Дублирование кода же.
3) У нас же real-time приложение. По сокетам прилетает событие, мол, новый друг добавлен в список, или удалён из него. Где это обрабатывать? Самый логичный вариант — этим должен заниматься тот самый синглтон FriendsService.
В чём преимущество Redux перед описанным мной подходом?
Кто-нибудь, пожалуйста, ответьте мне на эти вопросы. Я чувствую себя неполноценным членом Front-end сообщества из-за непринятия Redux.
Это template strings
developer.mozilla.org/ru/docs/Web/JavaScript/Reference/template_strings
Код, указанный в данном разделе теста, абсолютно валиден.
На таком сайте, как кинопоиск, мне хотелось бы наоборот, как можно реже вводить данные для входа. У меня там ничего конфиденциального нет, да и не может быть.
Единственное, что могло бы произойти, будь там http, это передача заголовка referer когда на ссылку кликнули. Но там https, он этот заголовок не передаёт. Здесь никакой проблемы/дыры нет.
Отредактируйте пост, а то народ в заблуждение вводите :)
Я ТКС ни в коем случае не защищаю, и комментарий Natalia Lutay, сотрудника банка, который она выдвигает «с уверенностью», выглядит как детский лепет. Мне даже стыдно стало. Хотя опозорилась она. Налицо подмена тезиса.
Да, но ранее это можно было сделать имея ТОЛЬКО доступ к почте. Сейчас это можно сделать кучей других методов. Да даже банально подсмотреть/сфотографировать адрес. Я уже молчу про историю браузера, которую может найти жена, и узнать, что её муж просаживает в баре половину зарплаты.
Ещё проблема — это индексация недобросовестными поисковиками, следящими за пользователями с помощью браузеров. Если данные утекут в какую-нибудь поисковую систему, узнаем, кто и насколько нагло за нами следит.
Яндекс вон недавно попался на этом.
ТКС, если вы читаете мой комментарий. Я ваш клиент, и меня напрягает такое отношение к моим данным, и ваши самоуверенные и некомпетентные сотрудники.