Тут важно, чтобы новости были релевантными. Речь как раз об избавлении от шума при ожидании нужного сигнала. Допустим, вы захотели купить айфон 15 дешевле 100 рублей. Вы заходите на условное авито и делаете поиск по параметрам. Ничего не найдено. Чтобы позже проверить, не появился ли данный товар, вам нужно повторять поиск снова и снова. И вот, надоело. Тем временем товар появился и его уже купил тот, кто быстрее проверял наличие.
Awakari позволяет задать критерии и ждать. Доставка релевантного сообщения занимает десятки миллисекунд.
Придётся хостить самому и собирать все источники, невозможно использовать общую коллекцию источников. То есть выборка ограничена теми источниками, о которых вы итак уже знаете
Проблема поллинга не столько задержка, сколько в вынужденном выборе между холостой нагрузкой и большей задержкой
Буду говорить о себе - меня не устраивает такое решение.
RSS интерфейс означает поллинг. Это означает, что придётся обрушивать весь поток информации с множества источников на клиента. Если я хочу выбирать из как можно большего числа источников, в пределе - со всего интернета? Это работать не будет.
Нет фильтрации.
Минимальная задержка примерно равна периоду поллинга. Это может быть слишком много для некоторых use case.
Awakari - polling terminator, то есть работает наоборот.
Нет, например, чтобы удалить половину своих подписок вам потребуется:
Вспомнить их все
Пройти по каждому и разобраться в уникальном способе отписки "парой кликов". Может быть. Ну если повезет. Ой, у нас отписка сломалась, позвоните в поддержку. Ваш звонок очень важен для нас.
Простой пример: поиск работы. Вы бы не хотели ограничивать свой поиск одним лишь условным superjob. Для этого вам понадобится множество источников. Причём вы можете даже не все их знать. Это означает фильтрацию в потоке сообщений неограниченной ширины.
Если это среда k8s, то, как правило, разработчик сам определяет имена переменных для своего сервиса. Не могу представить, зачем делать иначе. К чему вся эта ненужная гибкость? Только все усложняет
Тогда вы теряете потенциально полезные сообщения из источников, которые вы ещё не знаете
Тут важно, чтобы новости были релевантными. Речь как раз об избавлении от шума при ожидании нужного сигнала. Допустим, вы захотели купить айфон 15 дешевле 100 рублей. Вы заходите на условное авито и делаете поиск по параметрам. Ничего не найдено. Чтобы позже проверить, не появился ли данный товар, вам нужно повторять поиск снова и снова. И вот, надоело. Тем временем товар появился и его уже купил тот, кто быстрее проверял наличие.
Awakari позволяет задать критерии и ждать. Доставка релевантного сообщения занимает десятки миллисекунд.
Есть различные протоколы websocket, sse и тп
Некоторые сервисы требуют email и потом невозбранно спамят, например. Email - это тоже уведомления. Есть разные способы навязать вам спам
Фильтрациии я не нашёл среди фич
Придётся хостить самому и собирать все источники, невозможно использовать общую коллекцию источников. То есть выборка ограничена теми источниками, о которых вы итак уже знаете
Проблема поллинга не столько задержка, сколько в вынужденном выборе между холостой нагрузкой и большей задержкой
Подписки бывают не только "разрешением сайту уведомлять". Есть ещё email, моб приложения и что-нибудь ещё, о чем так сразу и не вспомнить
Буду говорить о себе - меня не устраивает такое решение.
RSS интерфейс означает поллинг. Это означает, что придётся обрушивать весь поток информации с множества источников на клиента. Если я хочу выбирать из как можно большего числа источников, в пределе - со всего интернета? Это работать не будет.
Нет фильтрации.
Минимальная задержка примерно равна периоду поллинга. Это может быть слишком много для некоторых use case.
Awakari - polling terminator, то есть работает наоборот.
Это всё равно лучше, чем логинить сторонним сервисом (а сейчас так делает большинство) и вдобавок к этому, ещё что-то хранить о пользователях у себя.
Нет, например, чтобы удалить половину своих подписок вам потребуется:
Вспомнить их все
Пройти по каждому и разобраться в уникальном способе отписки "парой кликов". Может быть. Ну если повезет. Ой, у нас отписка сломалась, позвоните в поддержку. Ваш звонок очень важен для нас.
Да, не только поэтому. Также не позволяет неограниченно спамить, RSS лентами слишком легко управлять
Простой пример: поиск работы. Вы бы не хотели ограничивать свой поиск одним лишь условным superjob. Для этого вам понадобится множество источников. Причём вы можете даже не все их знать. Это означает фильтрацию в потоке сообщений неограниченной ширины.
RSS подразумевает поллинг. Не существует пуш реализаций
Ни яблоко, ни гугл менять веб сервер не стали. Факт остаётся - поддержку RSS просто прекращают
Спасибо, поправлю
Есть также новый и бесплатный сервис Awakari, который в режиме реального времени фильтрует сообщения из множества разных источников
Try Awakari
Помнится, в 10х годах обещали революцию с мемристорами. Где оно все сейчас?
Если это среда k8s, то, как правило, разработчик сам определяет имена переменных для своего сервиса. Не могу представить, зачем делать иначе. К чему вся эта ненужная гибкость? Только все усложняет
Переменные среды для микросервиса обычно определяются разработчиком в deployment.yaml/statefulset.yaml/...
Каким боком здесь devops?
В общем, в Go так не делается. Проще всего - передавать конфиг через переменные среды в структуру с помощью, например, https://github.com/kelseyhightower/envconfig
Я пока остановился на донатах с ботом donate и провайдером smart-glocal. Работает везде, нет заморочек с юрлицом