Редактирование пользовательского документа в mongodb

Question

Это плохая практика, позволяющая редактировать пользовательский документ, не меняя пароль. Я заметил, что в angular-fullstack у вас нет функции для обновления пользователя. Также на firebase пользователь регистрируется с помощью аутентификации, но информация о пользователе (имя, телефон, адрес...) должна храниться в другом месте.

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

Я не прошу мнения, пожалуйста. Только фактические проблемы с хранением полей аутентификации и неаутентификации в одном и том же документе.

Answer 1

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

Разделение концерна

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

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

Политика безопасности

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

Вы попросили ответить без мнений, однако тема, на которую вы ссылаетесь, относится к разделению проблем и архитектуре микросервисов. Эти домены могут быть очень самоуверенными, поэтому ни в коем случае не рассматривайте мой ответ как полный.

Читайте об архитектуре микро сервисов здесь:
http://martinfowler.com/articles/microservices.html