Да, извиняюсь за неглубокое повествование и уход сразу в детали.
Что за DataProvider? Вы сразу начинаете описывать механизмы, но не рассказали, что это
DataProvider - это отдельный слой приложения. Он находится внутри. Его назначение - это получение всех данных. Внутри него вы уже реализуете кеширование, логирование и прочее. Разработчикам мы оставляем простой метод для получения данных.
Как сказано выше у него 2 метода. Первый универсальный, второй - массив простых действий, чтобы не писать каждый раз конструкцию options = {...} (исключение для простоты и сокращения кода. Второй - всегда использует первый.
Options - Непонятно от слова совсем
В не релизном состоянии, когда код все ещё пишется и нет абсолютно точного описания задачи и конечной цели, когда не проработана вся комбинаторика - есть кейсы, когда в запрос надо добавить некие опции, чтобы получить результат (назовем это прототипный код, к примеру). Это место, куда вы можете пихать, пока не поймете как с этим быть
Есть ли возможность объединить фильтры через ИЛИ?
В концепции нет никаких препятствий, в реализации, что приложено такое пока не заложено
Кстати, почему методы статичные?
Исключительно внутреннее соглашение, для единообразия и некое сокращения количества кода
Непонятно, как я смогу изменить что то, если у меня на статику завязка)
Рассматриваем модульное (микросервисное приложение) на php:
вы его написали, все хорошо. но в какой-то момент оно дало рост и получение и обработка данных стала давать не ту скорость, которая вас устраивает
можно переписать все на go - но это будет жутко дорого. вместо этого вы можете переписать внутренности DP на более высоко оптимизированном языке или любым иным способом
Второй кейс: у вас react/vue.
Есть некий компонент (форма создания какой-то элемента)
Поля формы сильно отличаются от контекста и типа этого элемента (к примеры товары в магазине)
Программист в начале имел всего 3 типа и всё было хорошо. Он за каждым ходит на бек, прямо внутри всего чудного компонента
В данном кейсе - нам надо будет переписать и компонент тоже, когда мы захотим его оптимизировать, к примеру, добавив некий TTL-кеш
Если бы он сразу написал FromProvider.get({type:any}) - тогда мы бы оптимизировали 1 участок (ядро системы), а не сотни вызовов axios.get()
Это концепция поиска данных, авторизация лежит выше.
примерно: route -> controller -> DataProvider -> models -> DB
на фронте вместо того чтобы сразу идти на бек (axios.get) - мы также реализуем поэтапно: DP->apiClass->Back Api
мне всегда не хватало стандартных моделей, потому мы пришли к этому.
Как быть когда представление данных отличается от того как они хранятся?
-> у нас мы в Response указываем те хендлеры , которые надо применить к ответу, все DataHandlers - чистое функциональное программирование. Есть схема входящих данных, есть схема выходящих
Почему рассматривается только запрос поиска?
Эта часть цикла - только про поиск. Сохранение будет рассмотрено дальше, это тоже большой пласт подходов
"Как быть когда мы поверх одних данных и логики делаем как веб страницы, так и некоторое API, (например, для мобильных устройств)?"
ru.m.wikipedia.org/wiki/Стресс
в большинстве случаев это дистресс. из которого в принципе можно выбраться. айти, в силу своего мышления подвержен ему чаще, имхо
Кстати, ваши идеи мы с удовольствием выслушаем в комментариях и реализуем, если они окажутся хорошими.
Готов поделиться, из своего опыта с недавним штормовым предупреждением — привяжите «пешеходную часть» сервиса к Я.Погоде. Уж лучше крюк в 11 км сделать, чем под двухминутный ливень попасть.
А информация о шлагбаумах во дворах оперативно обновляется?
Не знаю как сейчас, но раньше "Safebrowsing от Яндекс" давал сбои и не совсем актуальную базу. Работал через апи пару лет назад. В связи с этим возможны ложные срабатывания или запоздалые.
Сейчас взял 100 запросов (order by rand) и снимаю каждые 60 минут, чтобы получить первичные данные. Если они окажутся интересными, будет более масштабный эксперимент. yadi.sk/i/nPMc73dunAwKa вот часть данных. посмотрите. если есть интересные идеи как провести эксперимент и как снимать данные — пишите в личку, там обсудим
Мне кажется вполне можно найти базовые результаты, убрав рандом.
Данные чуть позже опубликую.
А какие образом вы предлагаете анализировать траф, не очень это ясно? он либо есть по запросу, либо нету. Количество плавает от дня недели, сезона. Просто если запрос в топ5-10, то его стоит «дотолкнуть», к примеру. а если уже 1-2, то не стоит
вот тут, к примеру отчетливо видно базовые:
выбрал 100 случайных запросов. снимаю каждый час позиции. рандомизация не более 20% точнее будет позже, как и возможный алгоритм снятия настоящих позиций. надо поснимать дольше и уже смотреть данные.
В рандомизации большинство +-1 позиция, потом в позициях 5+ включаю новый сайт, ближе к 10 позиции, что на траф не сильно влияет (топ3 снимает почти весь трафик)
Про персонализацию и рандомизацию выдачи в курсе.
Не использовали куки, не использовали авторизацию. Парсили каждый запрос под новым ip.
Это снижает рандом. В целом оценил степень изменения и она не такая сильная. В цифрах замерять буду следующим экспериментом. Множественные запросы в рамках 1 апдейта, в разное время и таким образом оценить степень изменения. даже если учитывать указанное вами, все равно, яндекс-api (xml) не так достоверно, как выдача. основной посыл эксперимента был именно в этом
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Да, извиняюсь за неглубокое повествование и уход сразу в детали.
Что за DataProvider? Вы сразу начинаете описывать механизмы, но не рассказали, что этоDataProvider - это отдельный слой приложения. Он находится внутри. Его назначение - это получение всех данных. Внутри него вы уже реализуете кеширование, логирование и прочее. Разработчикам мы оставляем простой метод для получения данных.
Как сказано выше у него 2 метода. Первый универсальный, второй - массив простых действий, чтобы не писать каждый раз конструкцию options = {...} (исключение для простоты и сокращения кода. Второй - всегда использует первый.
Options - Непонятно от слова совсемВ не релизном состоянии, когда код все ещё пишется и нет абсолютно точного описания задачи и конечной цели, когда не проработана вся комбинаторика - есть кейсы, когда в запрос надо добавить некие опции, чтобы получить результат (назовем это прототипный код, к примеру). Это место, куда вы можете пихать, пока не поймете как с этим быть
Есть ли возможность объединить фильтры через ИЛИ?В концепции нет никаких препятствий, в реализации, что приложено такое пока не заложено
Кстати, почему методы статичные?Исключительно внутреннее соглашение, для единообразия и некое сокращения количества кода
Непонятно, как я смогу изменить что то, если у меня на статику завязка)Рассматриваем модульное (микросервисное приложение) на php:
вы его написали, все хорошо. но в какой-то момент оно дало рост и получение и обработка данных стала давать не ту скорость, которая вас устраивает
можно переписать все на go - но это будет жутко дорого. вместо этого вы можете переписать внутренности DP на более высоко оптимизированном языке или любым иным способом
Второй кейс: у вас react/vue.
Есть некий компонент (форма создания какой-то элемента)
Поля формы сильно отличаются от контекста и типа этого элемента (к примеры товары в магазине)
Программист в начале имел всего 3 типа и всё было хорошо. Он за каждым ходит на бек, прямо внутри всего чудного компонента
В данном кейсе - нам надо будет переписать и компонент тоже, когда мы захотим его оптимизировать, к примеру, добавив некий TTL-кеш
Если бы он сразу написал FromProvider.get({type:any}) - тогда мы бы оптимизировали 1 участок (ядро системы), а не сотни вызовов axios.get()
Это концепция поиска данных, авторизация лежит выше.
примерно: route -> controller -> DataProvider -> models -> DB
на фронте вместо того чтобы сразу идти на бек (axios.get) - мы также реализуем поэтапно: DP->apiClass->Back Api
мне всегда не хватало стандартных моделей, потому мы пришли к этому.
Как быть когда представление данных отличается от того как они хранятся?-> у нас мы в Response указываем те хендлеры , которые надо применить к ответу, все DataHandlers - чистое функциональное программирование. Есть схема входящих данных, есть схема выходящих
Почему рассматривается только запрос поиска?Эта часть цикла - только про поиск. Сохранение будет рассмотрено дальше, это тоже большой пласт подходов
"Как быть когда мы поверх одних данных и логики делаем как веб страницы, так и некоторое API, (например, для мобильных устройств)?"а это я не понял
микросервисы или монолит?
про cl/cd, monitoring?
в большинстве случаев это дистресс. из которого в принципе можно выбраться. айти, в силу своего мышления подвержен ему чаще, имхо
Что под этим подразумевается и каковы основные механизмы функционирования?"
Готов поделиться, из своего опыта с недавним штормовым предупреждением — привяжите «пешеходную часть» сервиса к Я.Погоде. Уж лучше крюк в 11 км сделать, чем под двухминутный ливень попасть.
А информация о шлагбаумах во дворах оперативно обновляется?
технология интересная
Данные чуть позже опубликую.
А какие образом вы предлагаете анализировать траф, не очень это ясно? он либо есть по запросу, либо нету. Количество плавает от дня недели, сезона. Просто если запрос в топ5-10, то его стоит «дотолкнуть», к примеру. а если уже 1-2, то не стоит
вот тут, к примеру отчетливо видно базовые:
В рандомизации большинство +-1 позиция, потом в позициях 5+ включаю новый сайт, ближе к 10 позиции, что на траф не сильно влияет (топ3 снимает почти весь трафик)
Не использовали куки, не использовали авторизацию. Парсили каждый запрос под новым ip.
Это снижает рандом. В целом оценил степень изменения и она не такая сильная. В цифрах замерять буду следующим экспериментом. Множественные запросы в рамках 1 апдейта, в разное время и таким образом оценить степень изменения. даже если учитывать указанное вами, все равно, яндекс-api (xml) не так достоверно, как выдача. основной посыл эксперимента был именно в этом