RESTful Mongoose с ссылками ObjectID

Мой вопрос: Как я могу создать экземпляр RESTful mongodb, который использует mongoosejs без миллиона запросов HTTP?RESTful Mongoose с ссылками ObjectID

Моя установка: Я использую NodeJS для бэкэнд с MongooseJS. Я использую AngularJS на интерфейсе, поэтому я решил использовать angular-bridge для восстановления моей базы данных MongoDB.

Мои Schemas: У меня есть следующая схема:

Schemas

Примечание: Начало стрелки обозначает, что объект имеет ссылку на объект в конце стрелки (для Например, comment имеет свойство owningPost, которое является ссылкой ObjectID). Кроме того, звездочки (*) означают «много», поэтому сообщение может иметь много комментариев, но комментарий ссылается только на одно сообщение, а поток может ссылаться на многие ведра, а в ведро может быть много потоков, ссылающихся на него.

Вопрос: Предположим, пользователь попал на страницу, представляющую ведро. Мне нужно сделать следующие запросы ПОЛУЧАЕТЕ:

Ковш
Пользователь
Каждый пост, который ссылается на ведре
Каждый комментарий, который ссылается на пост
Пользователь для каждого комментария

Количество запросов может быстро взорваться. Возможно, я мог бы оставить комментарий, содержащийся в сообщении, это может быть не проблема. Однако я не могу этого сделать для всего остального (и оставаться в здравом уме).

Я попытался сделать конечную точку, которая получает все данные в различных свойств, как:

data: { 
    bucket: {}, 
    user: {}, 
    posts: [ 
    { 
     post: {}, 
     comments: [ 
     user: {}, 
     comment: {} 
     ] 
    } 
    ] 
}

Но это не больше успокоительное ... Правильно? Это делает обновление немного сложнее.

Что я делаю неправильно? Что это лучший способ сделать это?

источник

2014-02-18 kentcdodds

Если ваши данные и требования соответствуют реляционной модели, вы можете использовать реляционную базу данных вместо MongoDB. –

Что я обычно делаю:

Я ничего на «список» запрос не заполнять.
Я заполняю все объектные ссылки на запрос «показать».

Это не сделает ваш сервис менее RESTful, насколько я могу судить. Он по-прежнему будет ориентирован на ресурсы, и прикрепленные данные на самом деле принадлежат этому конкретному ресурсу. Это должно уменьшить количество запросов, которые вам нужно будет сделать.

В качестве альтернативы вы можете создать ресурс контейнера, который собирает всю необходимую информацию и отправляет ее обратно клиенту. Я бы лично пошел с несколькими отдельными запросами. Тем более, что, поскольку HTTP 1.1, несколько запросов могут выполняться через одно и то же соединение. Я не думаю, что запрос нескольких объектов JSON в одно и то же время повлияет на производительность вашего приложения.

Я бы не вложил все в схему «данных».

Надеюсь, это поможет и удачи!

источник

2014-02-18 22:30:57

Чем больше я думаю об этой идее, тем больше мне это нравится. Думаю, я поеду с ним. Я дам вам знать, когда я попробую и как получилось. – kentcdodds

@kentcdodds Я рад, что вам нравится эта идея, и да, пожалуйста! –

Хорошо, так что это отлично работает. Вы действительно помогли мне пройти мимо этого, хотя я не совсем понял вашу реализацию. То, что я делаю, я действительно возвращаю объект «данных» при получении сообщений потока, но я создаю объект '$ resource' для соответствующих данных, а затем просто добавляю этот объект к ресурсу, к которому он принадлежит. В любом случае это не будет сохраняться в объекте данных. Итак, в основном, когда я загружаю сообщение, у него есть свойство comments, поэтому я создаю/заменяю ресурс для каждого из них, тогда я делаю то же самое с автором комментария. Таким образом, я получаю успокоительные преимущества и делаю меньше запросов. – kentcdodds

Вы должны denormalise Схему

источник

2014-02-18 22:15:58 Reda

Я понимаю, что нормализованная схема не является «способом MongoDB», но как бы вы порекомендовали бы представлять эти отношения многих-ко многим без нормализованной схемы? – kentcdodds

Я бы сохранил все данные, приведенные на веб-странице, в одном документе – Reda

Я думаю, что я не занимался достаточно хорошей работой, объясняя, как я использую эти данные. Поскольку сообщение может находиться в нескольких ведрах, а в ведро может быть более одного сообщения, в каком документе вы порекомендовали бы хранить другое? Это не имело бы смысла в любом случае ... По крайней мере, не для меня. Я ошибаюсь? – kentcdodds

Это для меня больше похоже на проблему с дизайном данных, ориентированную на документ, чем на конструкцию REST. Мой подход заключается в том, чтобы управлять дизайном модели данных по представлению или страницам, а не сначала разрабатывать модель, а затем пытаться подогнать ее к ней. Это как-то согласуется с ответом Реды.

Чтобы уменьшить количество запросов или популяций мангуста, я всегда допускаю дублирование в документах. В вашем примере ведро будет иметь массив сообщений id и массив идентификаторов потоков. В то же время сообщение будет содержать массив идентификаторов ведер и даже некоторую подробную информацию каждого ведра. Такая конструкция сделает поиск документа очень быстрым, но замедляет операции обновления, а также вводит риск несогласованности.

источник

2014-02-19 00:34:50 dliu

RESTful Mongoose с ссылками ObjectID

ответ

Смежные вопросы