Java спільнота

Дякуємо за відгук. Кешування в Spring Boot — це фактично Spring Cache плюс ті бібліотеки, про які йдеться у статті. Комунікація через JCache чи безпосередньо. Про це є і велика докладна документація, і просто tutorials.

Дякую за відгук. Я планую в майбутньому написати окрему статтю про віддалений кеш на базі Redis та його численних клонів.

Тут мова піде здебільшого про локальне кешування, тобто коли дані знаходяться на тому ж сервері, що і сам застосунок

Чудова стаття!

Залежить від контексту. «Hello World» проєкт можна зробити як звичайний метод — це правильно.

Автор все пояснив: Що тут не так? Не масштабується: Кожен новий тип сповіщення = новий блок if. Порушує принцип відкритості/закритості: Ви повинні модифікувати існуючий метод для додавання нової поведінки.

Хорошая статья. Redis в части случаев можно использовать напрямую (через клиент) в качестве кеша для хранения данных в его структурах отличных от Key — Value.

Годна стаття. Ще би про кешування в спрінгбуті згадати. Але це мабуть не вклалось би у абзац.

Також JCS є єдиною бібліотекою, яка дозволяє змінювати алгоритм eviction, в інших проєктах він або жорстко зашитий, або може змінюватися, але движком самої бібліотеки. думаю варто уточнити що мова йде про size-based eviction

«Це скарб». Дякую. Хоч тут мало конкретики стосовно реальних умов використання, але інформації достатньо щоб зрозуміти особливості та відмінності між GC.

startupProbe в якому кешується все що потрібно закешуватись — при респонзі 200 на пробу куб тільки тоді починає роутити запити на цей под

Невже Netflix зі своїм мільйоном мікросервісів нічого не придумали? www.youtube.com/watch?v=XpunFFS-n8I Перед тим як дивитися в сторону AOT/CDS/GraalVM.

Буквально перші запити підвисають, а потім все ок. Задвичай, після (як частина) деплойменту робиться smoke testing, де виконуються «перші запити, які підвисають». Такий собі «холодний старт».