Персонализирана логика за харесване/различие - трябва ли да бъде насочена към изгледа, данните или слоя на услугата?

Исках да видя дали има консенсус относно това къде да се запази логиката за показване на харесвани/нехаресвани бутони, в клиентския изглед или в заявката за база данни. Прокарването на логиката към самата заявка я поддържа чиста и последователна, но ще изисква всяка заявка за списъка с публикации на началната страница да бъде персонализирана и да не позволява кеширане на тази заявка.

Настройка: MongoDb база данни (или евентуално neo4j), node.js API и сървър за приложения, iOS мобилен клиент и уебсайт. Повечето публикации могат да имат дузина харесвания, но някои ще имат стотици харесвания. Повечето потребители ще са харесали 50 - 300 публикации, като няколко потребители ще харесат хиляди публикации.

Моят случай на използване: Потребителят преглежда списък с скорошни популярни публикации и вижда бутон „харесвам“ или „не харесвам“ до всяка публикация в зависимост от това дали вече е харесал публикацията.

Решение-

Подход 1: подайте идентификатора на потребителя в заявката към базата данни и върнете списък с най-популярните публикации със свойството isLiked, изчислено в заявката.

Подход 2: Клиентското приложение извлича и синхронизира харесваните идентификационни номера за този потребител и изгледът определя дали да покаже бутона „харесвам“ или „не харесвам“ за даден списък с публикации. Списъците с публикации могат да бъдат кеширани на сървъра или в cdn и не изисква персонализиране.

Подход 3? Има ли по-ефективен начин да го направите на останалия слой на api услугата?


mongodb database-design social-networking web-application-design
person MonkeyBonkey    schedule 09.11.2012    source източник

Отговори (1)


arrow_upward
0
arrow_downward

Предполагам, че трябва да обмислите предимствата и недостатъците и да видите кой е най-добрият.

MongoDB поддържа моноатомна команда за увеличаване на база данни, която може да бъде много ефективна. Дори няма да се налага да чакате, докато нивото на базата данни потвърди вмъкването и просто да покажете увеличения брой „харесвания“.

Ако приблизително по същото време друг потребител чете същата статия и искате да сте 100% сигурни, че преброяването му е правилно, вероятно няма да искате да правите никакво кеширане.

Казано това, вероятно не е необходимо да имате това число, за да бъдете гледани последователни милисекунда, след като някой е „харесал“ публикация. Така че можете да кеширате информацията за базата данни, включително броя и да посещавате базата данни на всеки х минути.

Обърнете внимание, че публикациите в блогове са много популярни през първите няколко дни и след това вече не.

Просто от любопитство това може да ви се стори интересно: видеозапис системата за преброяване на видеоклипове в YouTube, чийто брой остава 301 за известно време поради причини за проверка и мултицентър за данни. http://www.youtube.com/watch?v=oIkhgagvrjI

person Gianfranco P.    schedule 12.11.2012
comment
Проблемът, който имам, е персонализираното свойство isLiked, а не броят сам по себе си. Увеличаването на броя беше лесно и добре работещо, но проблемът е бизнес логиката как да се покаже дали този потребител вече е харесал тази публикация по мащабируем начин. - person MonkeyBonkey; 13.11.2012
comment
Мисля, че трябва да кеширате това може би в локалното хранилище на браузъра, тъй като е по-вероятно потребителят да види същата статия на същото устройство/браузър. Но все пак ще трябва да направите заявка в базата данни или в някакъв кеш от средно ниво, ако той се опита да прочете статията от друго устройство или браузър без локален кеш. -- Ако предпочитате да запазите простата архитектура, вероятно „мащабирането“ с MongoDB ще мащабира вашите четения, след като приложението ви за новини стане популярно. Това става чрез шардинг - person Gianfranco P.; 14.11.2012
comment
локалното кеширане при подход 2 може да работи, но изглежда, че ще стане много сложно и податливо на грешки със синхронизирането. Шардингът не би помогнал в този случай, тъй като не размерът на базата данни е проблемът, а броят харесвания, които всяка публикация би получила, и няма смисъл да се шардират отделни записи. - person MonkeyBonkey; 15.11.2012
comment
Всяко харесване ще бъде свързано с конкретен потребител. Това трябва да е уникално и индексирано, така че смятайте, че можете да работите с колекция userlike { userid: Object(<userid>), postid: Object(<postid>) }. И след това създайте уникален индекс на userid, db.userlike.ensureIndex({userid:1, postid:1}, {unique: 1}). С NoSQL бази данни може да се наложи да имате дублирани данни, за да имате по-добра производителност - person Gianfranco P.; 15.11.2012