![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bizwood.ru
Сегодня в правительстве представлял местным предпринимателям и чиновникам бета-версию нашего нового проекта – над которым я без продыху работал последние два месяца по 8-10 часов в день.
Мы запустили в тестовом режиме (ограниченная функциональность без возможности регистрации пока) торговую площадку леспрома Северо-запада – bizwood.ru
Фоточки вот, пока превьюшками:
Я невероятно устал за эти два месяца – мы ведь ещё параллельно два журнала подготовили – но очень доволен ) У меня впервые в жизни было такой силы вдохновение.
Подробности немного позже.
no subject
no subject
у меня поиск идёт в два запроса, а не в один.
поисковый энджин по запросу отдает только хэштэги айтемов без самих айтемов.
потом клиент разбирает ответ и запрашивает у сервера уже развёрнутое описание айтемов. причём только тех, которые в текущей сессии ещё не запрашивались -- уже полученные берутся из кэша.
мне идея двухпроходного поиска (вернее, сначала поиск -- потом отдельно выборка) очень нравится. это позволит в будущем независимо дорабатывать поисковую машину и фетчер. у них сильно разные задачи -- и поэтому идея их разделения мне кажется разумной.
апдейты айтемов да, довольно редкие -- и я пока ими пренебрегаю, хотя архитектурно и предусмотрено автообновление айтемов локально как только они поменялись на сервере. клиент пингует сервер раз в 5 минут уже сейчас, но пока это холостой цикл, там просто заглушка.
no subject
Насчёт двух проходного поиска - надо подумать.
У идеи есть один мега-недостаток - это минимум два round-trip'а на каждый "живой" запрос (когда кэш ещё пуст). Два round-trip'а это два round-trip'а. Конкуренты, делающие один round-trip побьют. Ну и для клиентов с медленным соединением это может hurt their experience.
Во всём остальном идея весьма соблазнительная. Надо ещё подумать. Например, очевидно, что нагрузка на сервер будет меньше. Суммарного трафика будет меньше. Хэши, если их очень компактно пересылать, могут уместиться в один TCP пакет, что есть very, very good.
Кстати, очевидно, ты можешь оптимизировать запросы по категориям, чтобы укладываться в один round-trip: если ты заведёшь id категорий ("категория" это прямой линк на список, с главной страницы), и у каждого "документа" будешь держать список id-шников, к которым он принадлежит, то в этом случае ты можешь, когда юзер кликает на категорию, вместе со строкой запроса пересылать серверу список хэшей, которые у тебя уже есть в кэше на эту категорию. Сервер пусть вернёт сразу все детали, но только для тех items, которых у тебя ещё нет.
no subject
хэши пересылаются очень компактно -- примерно 30+9*n байт
последнее предложение не очень. позиций в базе к осени будет несколько десятков тысяч, гонять обратно на сервер их хэши неразумно.
автокомплит будет (это к следующему комменту)
no subject
"последнее предложение не очень. позиций в базе к осени будет несколько десятков тысяч, гонять обратно на сервер их хэши неразумно."
Я не уверен, что ты понял последнее предложение. Отсылать на сервер не надо 10 тысяч. Отсылать надо только те хеши, которые входят в категорию. Если max по категории - пару сотен, то только пару сотен надо отправить. Это чтобы опитмизировать клики, которые не поиск по введённым словам, а клики на название категорий в меню.
no subject
этот проект мне как раз подвернулся, когда я обдумывал детали, как между клиентом и сервером данные пересылать и как их хранить/фильтровать.
я на этом проекте столкнулся с удивительным феноменом -- мне пришлось там специально вводить задержку отображения результатов поиска, потому что при мгновенной смене контента людям кажется, что ничего не поменялось )))
no subject
А как ты определил факт феномена? (Жаловались, что поиск не работает?)
no subject
поэтому я сделал моргание.
no subject