Интересно, content history работает только для измений через content manager? Или для всех изменений и через апи/контроллеры/entityService и тд. Если только через менеджер то совсем скучно, в принципе используя after update хук можно быстренько это все самому сделать
Как я понял из ответов выше при бутстрапе сервиса происходит чтение всех топиков Кафки и последовательное воссоздание хранилища заново в оперативную память.
Но зачем другим сервисам собирать реплику, если это делает ваш сервис и представляет об этом данные?
Но и опять таки, вопрос то был про ttl. То есть часть данных просто будет недоступна и в итоге невозможно будет восстановить реплику полностью. Плюс размер топика.
В общем, я понимаю, что это все возможно сделать, пару лет назад я сам делал систему частичной репликации постгри через кафку, но одновременно с этим я помню насколько это мучительно , потому что есть инструменты более подходящие
Я тоже разделяю смятение, которое выразил пользователь выше. Тоже по заголовку подумал, что вы в кафке данные научились хранить. Но по сути у вас есть сервис, который с помощью Кафки доставляет данные, но никак не хранит. А хранит он в оперативной памяти. И тогда возникает вопрос, что делать если сервис упал- поднялся и в оперативной памяти данных нет, а в кафке топики уже прочитаны?
Код алгоритмов был бы тут интересен и уместен. Сейчас это на платформе про разработку статья, в которой написано "я в общем разрабатывал, но вам об этом не расскажу, зато вот ссылка где можете купить итоговый результат", а вот если было наоборот "я разрабатывал, вот так и так это делал, вот код с кучей комментариев, а результат вы можете сами найти в поиске по такому ключевому слову, ссылку давать не буду", тогда бы статья набрала плюсов. А так это чистая реклама в итоге, здесь такое не любят.
Так смысл spa в том, что без js вообще нет никакого контента, кроме одного пустого div. Также не работает и пререндер, так как есть только один html, который состоит только из одного div, а любые страницы рендерится динамически.
Интересно, content history работает только для измений через content manager? Или для всех изменений и через апи/контроллеры/entityService и тд. Если только через менеджер то совсем скучно, в принципе используя after update хук можно быстренько это все самому сделать
Говорит, не знает кто такая эта ваша Макс
Как я понял из ответов выше при бутстрапе сервиса происходит чтение всех топиков Кафки и последовательное воссоздание хранилища заново в оперативную память.
Значит мы друг друга не сможем понять. Спасибо!
Но зачем другим сервисам собирать реплику, если это делает ваш сервис и представляет об этом данные?
Но и опять таки, вопрос то был про ttl. То есть часть данных просто будет недоступна и в итоге невозможно будет восстановить реплику полностью. Плюс размер топика.
В общем, я понимаю, что это все возможно сделать, пару лет назад я сам делал систему частичной репликации постгри через кафку, но одновременно с этим я помню насколько это мучительно , потому что есть инструменты более подходящие
Но ведь у Кафка топиков есть ttl, не все данные можно будет загрузить сначала
Я тоже разделяю смятение, которое выразил пользователь выше. Тоже по заголовку подумал, что вы в кафке данные научились хранить. Но по сути у вас есть сервис, который с помощью Кафки доставляет данные, но никак не хранит. А хранит он в оперативной памяти. И тогда возникает вопрос, что делать если сервис упал- поднялся и в оперативной памяти данных нет, а в кафке топики уже прочитаны?
Это ж Свифт, почему это подаётся как советы фронтендеру?)
Кто понял о чем это и может рассказать подробнее? Лёгкий гуглеж не помог
Код алгоритмов был бы тут интересен и уместен. Сейчас это на платформе про разработку статья, в которой написано "я в общем разрабатывал, но вам об этом не расскажу, зато вот ссылка где можете купить итоговый результат", а вот если было наоборот "я разрабатывал, вот так и так это делал, вот код с кучей комментариев, а результат вы можете сами найти в поиске по такому ключевому слову, ссылку давать не буду", тогда бы статья набрала плюсов. А так это чистая реклама в итоге, здесь такое не любят.
Без кода это не статья, а просто реклама
Ух, вот это я на ночь глядя конечно посчитал)
Спасибо за исправление!
Не совсем понял, почему у vdsina стоимость приводится как преимущество, если в итоге это 6000р в месяц и в итоге самый дорогой из представленных?
Аккуратность верстки и пиксель перфект это не одно и то же. Может быть неаккуратный, но пиксель перфект сайт.
Спасибо за ответ не на мой вопрос)
А вопрос был как раз про сео для spa)
Про переход на ssr я и так написал в первом же сообщении, это и так понятно и очевидно.
Где делаешь пререндер? Если на сервере, то это уже вопрос в сторону ssr.
Опять уход от вопроса. Как без изменений на сервере, только на фронте в spa улучшить seo
Помогите с ответом на вопрос "зачем бизнесу тратить время на пиксель перфект?"
Так смысл spa в том, что без js вообще нет никакого контента, кроме одного пустого div. Также не работает и пререндер, так как есть только один html, который состоит только из одного div, а любые страницы рендерится динамически.
Поэтому вопрос все ещё открыт.
Вопрос, что делать с seo в spa, где весь html это один div, а весь контент подгружается и рендерится динамически. P.S. ssr опускаем за скобки вопроса
Ага, кажется статья про хейттек