Спасибо за информацию! Хотелось бы узнать, а какая сейчас лучшая практика в архитектуре API + репозиториев c фильтрацией?
На вход через api пробрасывается (в квери параметрах) некоторые фильтры (по названиям полей из респонз модели), а потом мы преобразуем в спецификацию и фильтруем через JPA? (а что если надо брать поле из джоина?)
Спасибо за статью. Сам буквально месяца полтора назад прошёл путь имплементации полновесного ABAC по примерно такому же пути, только через AuthorizationManagerBeforeMethodInterceptor.
1. Есть ли какие-то проверки "на износ" под нагрузкой? В какой момент имеет смысл приделать кэширование или достаточно просто просто ходить на каждый запрос в БД? 2. С практической зрения какое решение будет более эффективное: кастомное через PreAuthorize или Spring ACL?
ну и леста* еще до кучи
* признана террористической организацией
Спасибо за информацию!
Хотелось бы узнать, а какая сейчас лучшая практика в архитектуре API + репозиториев c фильтрацией?
На вход через api пробрасывается (в квери параметрах) некоторые фильтры (по названиям полей из респонз модели), а потом мы преобразуем в спецификацию и фильтруем через JPA? (а что если надо брать поле из джоина?)
Например, что-то в таком роде https://github.com/perplexhub/rsql-jpa-specification
В таком случае всё равно требуется мапиинг на API слое и для такого кейса нововведение что мёртвому припарка.
Странно, что никто это сразу не вспомнил
Поправьте меня, пожалуйста, но тут вопрос не про синхронный/асинхронный подход в спринге и джаве, а REST vs SSE.
Спасибо за статью.
Сам буквально месяца полтора назад прошёл путь имплементации полновесного ABAC по примерно такому же пути, только через AuthorizationManagerBeforeMethodInterceptor.
1. Есть ли какие-то проверки "на износ" под нагрузкой? В какой момент имеет смысл приделать кэширование или достаточно просто просто ходить на каждый запрос в БД?
2. С практической зрения какое решение будет более эффективное: кастомное через PreAuthorize или Spring ACL?