Как стать автором
Обновить
40
-1.5
Андрей @akurilov

Программист

Отправить сообщение

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

Как правило, сервисы ничего не знают о CDN. И в общем, не должны.

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

В том числе

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

И что с того? Откуда CDN узнает, изменилась лента или нет у самого сервиса?

Etag не поможет, уже здесь обсуждали. Не позволяет кэшировать на стороне CDN

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

https://github.com/awakari/webapp/blob/bb79dbc3cd7e43b87b5404b7012dbcbd9c30a3bd/web/login.js#L10

В качестве юзер ид используется префикс identity provider и сторонний юзер id из которого я не могу понять, кто это.

Например, для телеги юзер ид выглядит так:

tg://user?id=34955377

Этот юзер добавил какое то порно в источники. Как я могу узнать имя нашего первого героя?

Выше уже отвечал

Реже = больше задержка

Чаще = больше холостой нагрузки

Поддержка сервисами RSS слабеет с каждым годом

Я знаком. Это не кэширование на стороне CDN, а на стороне клиента. И необходимость обрабатывать запрос сервису и отвечать на него это никак не отменяет

WebSub не присылает RSS файл, это принципиально другое.

У меня есть план добавить поддержку подобного, но мне более перспективной кажется поддержка ActivityPub

Не совсем так. Файл ленты RSS меняется в произвольный момент времени и не может быть закэширован.

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

Так здесь рассылается лишь то, что нужно конкретному клиенту. Поэтому если сообщение матчится с миллионом клиентов, значит оно интересно им всем

Вот так.

  1. Авито вам не нужен, вам нужен айфон 15.

  2. Если очень нужно именно Авито, то можно в продвинутом режиме указать условие "source: avito.ru"

  3. Численные условия поддерживаются, но на практике контент с Авито пока не парсится так, чтобы цена была отдельным атрибутом.

  4. Авакари не использует поллинг если на входе телеграм канал, но поллит ленты типа RSS и делает это "один раз для всех". И избавляет клиента от необходимости поллить.

Кэш не может знать, есть ли обновление в ленте. В худшем случае он будет отдавать устаревший контент

а в чем проблема 1 млн соединений? пусть себе висят. это потянет даже один инстанс. лимит у ядра линукса - 1,048,576 файловых дескрипторов

Много или мало - но это лишняя нагрузка на сервис. К тому же и на клиент, который делает холостые запросы, которые не приносят нового результата. Это всё может быть мало, пока мало клиентов и они редко запрашивают обновления. И для клиента - пока у него мало лент.

И это ещё не всё - добавьте лишнюю задержку

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

  1. Регулярные выражения - это то, от чего я отказался на самых первых этапах прототипирования. Должно быть что то вроде текстового поиска с поддержкой стемминга.

  2. Не нашёл способа группировать условия в более сложные с применением логики "и", "или" и тп

  3. Не нашёл численных условий. Например, матчить сообщения, где поле "цена" меньше 1000

Тогда вы теряете потенциально полезные сообщения из источников, которые вы ещё не знаете

Тут важно, чтобы новости были релевантными. Речь как раз об избавлении от шума при ожидании нужного сигнала. Допустим, вы захотели купить айфон 15 дешевле 100 рублей. Вы заходите на условное авито и делаете поиск по параметрам. Ничего не найдено. Чтобы позже проверить, не появился ли данный товар, вам нужно повторять поиск снова и снова. И вот, надоело. Тем временем товар появился и его уже купил тот, кто быстрее проверял наличие.

Awakari позволяет задать критерии и ждать. Доставка релевантного сообщения занимает десятки миллисекунд.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург и область, Россия
Зарегистрирован
Активность