А в чем же оверхед, если БД уже есть, а все остальное надо разворачивать и поддерживать? Или это требование "чистых микросервисов" - не делить базу? Могут ли быть из этого исключения с целью упрощения кода-поддержки в ущерб чистой архитектуре?
Переводите програмные термина следует в контексте программирования: В компьютерных науках есть только две сложные проблемы – инвалидация кэша и именование переменных. + почему упущенно важное: off-by-1 errors = "ошибка подсчета с единицы" наверное ближе всего
Сапсибо, интересно! По поводу хэшей и солей - в Spring Security стандарт PasswordEncoderFactories.createDelegatingPasswordEncoder() Он по умолчанию юзает BCryptPasswordEncoder, с которым не надо приседаний с перцем и солью - все встроено.
Автор явно не заботился о политкорректности, но тема очень интересная. Психологический портрет кодера, тимлида, компании в зависимости от языка, на котором пишут. Полагаю в топе будет что-то типа Rust и Golang.
Glassfish это Application Server А под аналогом Spring, судя по всему, имелся в виду принцип IoC в Jakarta-уже-EE - спецификация CDI Не лучший вариант для "экономии ресурсов" поднимать отдельный AS Разве что в одном поднимать несколько приложений, но это несогласуется с концепцией микросервисов- каждому свое окружение.
Сапсибо, прочел с интересом! Единственное - " нарезать одну или несколько функций на их единицы развертывания" - похоже на сырой Google Translator.
Это неверно, на них можно переключиться, см документацию: https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-server-choice
А, скажем, могомодульный монолит не решит проблему спутанности, при этом оставив простоту взаимодействия?
А в чем же оверхед, если БД уже есть, а все остальное надо разворачивать и поддерживать?
Или это требование "чистых микросервисов" - не делить базу? Могут ли быть из этого исключения с целью упрощения кода-поддержки в ущерб чистой архитектуре?
зашли уже туда: https://stackoverflow.com/help/gpt-policy
Переводите програмные термина следует в контексте программирования:
В компьютерных науках есть только две сложные проблемы – инвалидация кэша и именование переменных. + почему упущенно важное: off-by-1 errors = "ошибка подсчета с единицы" наверное ближе всего
(пусть частичное, но решение - thin jar) : https://dzone.com/articles/spring-boot-thin-jar-builder-for-running-java-micr
Spring Native и component index помогают:
https://stackoverflow.com/questions/47254907/how-can-i-create-a-spring-5-component-index
https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/
https://spring.io/blog/2022/09/26/native-support-in-spring-boot-3-0-0-m5
https://stackoverflow.com/questions/37854185/server-to-server-communication-in-microservices
Нашел Best Practice - Publisher/Subscriber approach
Или без авторизации с проверкой ip
Так понимаю - если по простому без асинхронности, то подойдет любая простая проверка, в том числе и подход выше
Правильно понял - между серверами в хедерах просто предается secret и сравнивается чз equals?
У вас есть ссылка на то, что это "так используется" или сами делали?
У Google вижу все сложнее: https://developers.google.com/identity/protocols/oauth2/service-account
Сапсибо, интересно!
По поводу хэшей и солей - в Spring Security стандарт
PasswordEncoderFactories.createDelegatingPasswordEncoder()Он по умолчанию юзает
BCryptPasswordEncoder, с которым не надо приседаний с перцем и солью - все встроено.Автор явно не заботился о политкорректности, но тема очень интересная. Психологический портрет кодера, тимлида, компании в зависимости от языка, на котором пишут. Полагаю в топе будет что-то типа Rust и Golang.
Наверно имеет смысл их здесь назвать..
Если пара ссылок в заголовке, если нужна информация. Вообще это не про Spring Boot 3.0 а про переезд.
Правка - действительно при обновлении access token'a обновляются ОБА (refresh и access) токена. Хорошая ссылка по реализации OAuth2: https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc
Glassfish это Application Server
А под аналогом Spring, судя по всему, имелся в виду принцип IoC в Jakarta-уже-EE - спецификация CDI
Не лучший вариант для "экономии ресурсов" поднимать отдельный AS
Разве что в одном поднимать несколько приложений, но это несогласуется с концепцией микросервисов- каждому свое окружение.
Еще один аргумент за JetBrains - продолжают выдавать бесплатные образовательные лицензии:
Наверно еще не было во время статьи: Роботрек
https://www.youtube.com/watch?v=BFC471bvcKw
ключ и секретный ключ приложения нужны только для refresh roken
все остальное- это уже извращенная реализация
Нет. По одному Refresh token вы получаете Access token-ы и только у них есть время жизни.
Гарантированное трудоустройство это обычно миф. Почитайте отзывы участников. Попадаешь в их базу, могут у себя ментором пристроить на 40тр.