И как аннотация @Columnспасет от проблем при, например, переименовании поля в базе? Никак - либо поле в entity переименуется вслед за полем таблицы, что поломает внешнее апи в том случае если энтити выдается потребителю наружу, либо поле в энтити будет называться не так, как называется поле в БД, что вызовет массу вопросов у тех, кто будет поддерживать код. Эй, ребят, а вы не знаете, почему у нас поле в котором лежит отчество называется name? А, это что б потребителям контракт не сломать... Эх, была бы промежуточная dto на которой можно было бы разрулить проблему маппинга!
Честно говоря не пойму почему возврат сущностей из БД в rest выдаче для CRUD сервисов - это антипаттерн
Потому что переименование поля в таблице - сугубо внутреннее действие - ломает внешнее api. Потому что добавление поля в таблицу - сугубо внутреннее действие - делает его доступным внешнему api. Иными словами любое действие над нутрянкой может негативно сказаться на внешнем контракте - потому и антипаттерн.
Работал "рядом" с проектом, где так и декларировали. Проблема была, что бэкенд был, без модных наваротов, типа перекладываения данных по DTO. Берёшь из базы передаёшь на фронтенд. Поменял поле, фронт отвалился.
Но это не "модные навороты", уже сто лет есть конвертеры, которые все это делают за программиста. Например тут: https://modelmapper.org/getting-started/ Эта либа как раз предназначена для безпроблемного перегона entity в dto, хотя ее можно использовать буквально что б что угодно в что угодно конвертить. То есть в процитированном случае был не "бэк без новомодных фишек", а, простите, "джунов посадили писать проект и они сделали, как показывали на курсах от скиллбокса" со всеми вытекающими.
Обычно все просто - если есть разлапистый фронтенд, на котором отдельная команда лепит всякие графики, градусники и прочие статусбары, в отрыве от всего остального мира, то имеет смысл отдавать на фронт весь датасет, и пусть уже фронт разбирается какую его часть и в каком виде показать пользователю. Если же данных много, и пропихивать их через сеть все разом не рационально, то обработка происходит на сервере.
В реальной жизни, как правило, я сталкивался с чем-то средним - на сервере датасет грубо ограничивается до каких-то вменяемых размеров, а тонкая фильтрация происходит уже на клиенте, за счет чего пользователь испытывает счастье от отзывчивого интерфейса и ощущения "информации на кончиках пальцев".
Пробежал статью, но так и не понял зачем мне расширять репозитории, что мне это дает и зачем мне это надо... Еще и пример на основе монги. На основе постгреса, который каждая собака знает, сделать пример религия что ли не позволила?
А зачем вам корзина для неавторизованных пользователей? Они же не смогут ничего с ней сделать пока не авторизуются, правильно? Ну, так до этого момента ее можно хранить на стороне браузера, больше-то она никому не нужна. После того, как пользователь успешно авторизовался - перегонять ее на сторону сервера очевидным образом, и все довольны.
Какие-то очень странные утверждения, если честно...
Та часть, где про "непонятное апи"
Ни один разумный человек не полагается на абстрактную "понятность", он смотрит в документацию. Swagger, OpenAPI и прочие страшные слова придумали как раз для этого.
Что касается HTTP‑методов, в плохом сервисе используются только POST‑запросы
Если б вы написали "в плохом REST-сервисе", то и вопросов бы не было - с этой точки зрения плох любой сервис, который просто не соответствует принципам rest, хотя это уже культ карго какой-то. Но вы написали так, словно гонять все через POST это плохо само по себе, а это не так... Для начала гоняя все одним методом мы избавимся от проблемы, собственно, метода - метод легко отчуждаем от url, и периодически теряется, что приводит к прекрасным часам в попытке наиграть ошибку клиента, что бы в итоге понять, что вы с ним один и тот же url дергаете по-разному, вы у себя постом, а он патчем - глупо и достадно, но случается повсеместно. Если все гонять через POST, то значение начинает иметь только url и его тело, и напортачить тут уже гораздо сложнее - любой потерянный кусочек данных тут же себя проявит еще на подлете.
Во-вторых работа через POST уже давно оформилась в отдельный принцип, который окрестили RPC, и куча народа счастливо живет и здравствует им пользуясь, непонятно к чему заявлять, что "это плохо", когда массе народу вполне себе хорошо. Плюс именно такой протокол взаимодействия легко переносится на иные каналы - rabbitmq или вебсокеты, где просто не предусмотрены никакие типы запроса. Url+body туда перенесется вполне естественно и непринужденно, а вот все эти GET, PATCH и прочие DELETE уже будут выглядеть чужеродно.
Еще одно важное правило для плохого REST‑сервиса — минимизировать количество кодов ответа. Обычно достаточно 2–3 варианта ответа с кодом 200. Например, 200 — запрос дошел, а 500 — ошибка, когда что‑то пошло не так. Что именно произошло? Неважно — логи всегда помогут разобраться.
Кодов ответа несколько десятков, потенциальных состояний системы - бесконечное множество, поэтому код 404 мало что скажет без заглядывания в документацию. То ли страница не найдена, то ли пользователь, то ли у пользователя счет?.. Одно ясно - что-то не нашлось! А что именно - помогут понять логи.
Так же не забываем, что есть огромное множество людей, которые не хотят смешивать бизнеслогику и транспорт, поэтому для них 200 ОК обозначает, что сервис запрос получил и успешно его обработал, а то, что результат обработки - это ошибка, это уже не вопрос протокола взаимодействия, это бизнесовая ошибка, и обрабатывается на другом уровне. Утверждать, что такой подход глупость - глупость.
Плохой REST‑сервис должен хранить состояние
Для решения описанных проблем давным-давно придумана масса решений, от банальной работы через общую БД, в которой хранится то самое общее состояние горизонтально масштабированного сервиса, и до распределенного in-memory кэша навроде hazelcast. Поэтому утверждать, что хранение состояния на сервисе это всегда плохо нельзя - это всегда ведет к проблемам, которые нужно решать, но плохо ли это? Зависит от условий задачи, иногда жить без состояния просто нельзя.
В плохом REST‑сервисе шифрование не нужно
А в хорошем - нужно! Точно? Ну, точно же?! Точно?.. *Падме.jpg* Хммм... А ведь можно терменировать tls/mtls на уровне ingress, а внутри неймспейса кубернетиса гонять обычный http траффик. Я не девопс, поэтому говорю, как умею, основная мысль тут в том, что можно снять с сервиса ответственность за все эти приседания с сертификатами, и перенести их на инфраструктурный уровень - они останутся, просто будут в другом месте, и их точно не будет в нашем сервисе. Плохо что ли? Хорошо же!
В общем странная, очень странная статья. Зато с фотографией Кости Латышова, который точно знает, что нам не стоит нести на прод!
Цель - получение ID, уникального только в рамках конкретного устройства (то есть без гарантий уникальности между всеми устройствами, как у UUID).
то зачем вам вообще UUID? Секвенция в БД замечательно справится с генерацией новых уникальных id - это быстро и надежно. На вскидку смысл связываться с UUID появляется только в двух случайх - если у вас несколько инстансов БД, и есть риск задвоения генеренных из сиквенсов айдишников, и если вам нужна миграция с БД на БД попроще, без проблем с миграцией дочерних записей.
И как аннотация @Columnспасет от проблем при, например, переименовании поля в базе? Никак - либо поле в entity переименуется вслед за полем таблицы, что поломает внешнее апи в том случае если энтити выдается потребителю наружу, либо поле в энтити будет называться не так, как называется поле в БД, что вызовет массу вопросов у тех, кто будет поддерживать код. Эй, ребят, а вы не знаете, почему у нас поле в котором лежит отчество называется name? А, это что б потребителям контракт не сломать... Эх, была бы промежуточная dto на которой можно было бы разрулить проблему маппинга!
Честно говоря не пойму почему возврат сущностей из БД в rest выдаче для CRUD сервисов - это антипаттернПотому что переименование поля в таблице - сугубо внутреннее действие - ломает внешнее api. Потому что добавление поля в таблицу - сугубо внутреннее действие - делает его доступным внешнему api. Иными словами любое действие над нутрянкой может негативно сказаться на внешнем контракте - потому и антипаттерн.
Ощущение, что статью создали при помощи генератора случайного текста.
Работал "рядом" с проектом, где так и декларировали. Проблема была, что бэкенд был, без модных наваротов, типа перекладываения данных по DTO. Берёшь из базы передаёшь на фронтенд. Поменял поле, фронт отвалился.Но это не "модные навороты", уже сто лет есть конвертеры, которые все это делают за программиста. Например тут: https://modelmapper.org/getting-started/ Эта либа как раз предназначена для безпроблемного перегона entity в dto, хотя ее можно использовать буквально что б что угодно в что угодно конвертить. То есть в процитированном случае был не "бэк без новомодных фишек", а, простите, "джунов посадили писать проект и они сделали, как показывали на курсах от скиллбокса" со всеми вытекающими.
Обычно все просто - если есть разлапистый фронтенд, на котором отдельная команда лепит всякие графики, градусники и прочие статусбары, в отрыве от всего остального мира, то имеет смысл отдавать на фронт весь датасет, и пусть уже фронт разбирается какую его часть и в каком виде показать пользователю. Если же данных много, и пропихивать их через сеть все разом не рационально, то обработка происходит на сервере.
В реальной жизни, как правило, я сталкивался с чем-то средним - на сервере датасет грубо ограничивается до каких-то вменяемых размеров, а тонкая фильтрация происходит уже на клиенте, за счет чего пользователь испытывает счастье от отзывчивого интерфейса и ощущения "информации на кончиках пальцев".
Детали внутренней реализации протекают наружу, а значит, что внутренний рефакторинг или доработка на раз-два поломают внешнее апи.
Наоборот - я ниразу не видел работодателейЗначит вас можно просто не слушать, поскольку кругозор у вас весьма ограниченный, и это не попытка оскорбить, а непреложный факт.
Да что вы говорите, не нужен ДМС? Вот это новости! Подозреваю, что у вас просто ДМС никогда не было, поэтому вам и "незачем".
Кликаем мышкой вместо того, что бы писать шаблонный и хорошо знакомый код. Я не уверен, что игра стоит свеч, если честно.
Пробежал статью, но так и не понял зачем мне расширять репозитории, что мне это дает и зачем мне это надо... Еще и пример на основе монги. На основе постгреса, который каждая собака знает, сделать пример религия что ли не позволила?
А зачем вам корзина для неавторизованных пользователей? Они же не смогут ничего с ней сделать пока не авторизуются, правильно? Ну, так до этого момента ее можно хранить на стороне браузера, больше-то она никому не нужна. После того, как пользователь успешно авторизовался - перегонять ее на сторону сервера очевидным образом, и все довольны.
ЦФТ уже активно импортозамещается, если что.
Какие-то очень странные утверждения, если честно...
Та часть, где про "непонятное апи"Ни один разумный человек не полагается на абстрактную "понятность", он смотрит в документацию. Swagger, OpenAPI и прочие страшные слова придумали как раз для этого.
Что касается HTTP‑методов, в плохом сервисе используются только POST‑запросыЕсли б вы написали "в плохом REST-сервисе", то и вопросов бы не было - с этой точки зрения плох любой сервис, который просто не соответствует принципам rest, хотя это уже культ карго какой-то. Но вы написали так, словно гонять все через POST это плохо само по себе, а это не так... Для начала гоняя все одним методом мы избавимся от проблемы, собственно, метода - метод легко отчуждаем от url, и периодически теряется, что приводит к прекрасным часам в попытке наиграть ошибку клиента, что бы в итоге понять, что вы с ним один и тот же url дергаете по-разному, вы у себя постом, а он патчем - глупо и достадно, но случается повсеместно. Если все гонять через POST, то значение начинает иметь только url и его тело, и напортачить тут уже гораздо сложнее - любой потерянный кусочек данных тут же себя проявит еще на подлете.
Во-вторых работа через POST уже давно оформилась в отдельный принцип, который окрестили RPC, и куча народа счастливо живет и здравствует им пользуясь, непонятно к чему заявлять, что "это плохо", когда массе народу вполне себе хорошо. Плюс именно такой протокол взаимодействия легко переносится на иные каналы - rabbitmq или вебсокеты, где просто не предусмотрены никакие типы запроса. Url+body туда перенесется вполне естественно и непринужденно, а вот все эти GET, PATCH и прочие DELETE уже будут выглядеть чужеродно.
Еще одно важное правило для плохого REST‑сервиса — минимизировать количество кодов ответа. Обычно достаточно 2–3 варианта ответа с кодом 200. Например, 200 — запрос дошел, а 500 — ошибка, когда что‑то пошло не так. Что именно произошло? Неважно — логи всегда помогут разобраться.Кодов ответа несколько десятков, потенциальных состояний системы - бесконечное множество, поэтому код 404 мало что скажет без заглядывания в документацию. То ли страница не найдена, то ли пользователь, то ли у пользователя счет?.. Одно ясно - что-то не нашлось! А что именно - помогут понять логи.
Так же не забываем, что есть огромное множество людей, которые не хотят смешивать бизнеслогику и транспорт, поэтому для них 200 ОК обозначает, что сервис запрос получил и успешно его обработал, а то, что результат обработки - это ошибка, это уже не вопрос протокола взаимодействия, это бизнесовая ошибка, и обрабатывается на другом уровне. Утверждать, что такой подход глупость - глупость.
Плохой REST‑сервис должен хранить состояниеДля решения описанных проблем давным-давно придумана масса решений, от банальной работы через общую БД, в которой хранится то самое общее состояние горизонтально масштабированного сервиса, и до распределенного in-memory кэша навроде hazelcast. Поэтому утверждать, что хранение состояния на сервисе это всегда плохо нельзя - это всегда ведет к проблемам, которые нужно решать, но плохо ли это? Зависит от условий задачи, иногда жить без состояния просто нельзя.
В плохом REST‑сервисе шифрование не нужноА в хорошем - нужно! Точно? Ну, точно же?! Точно?.. *Падме.jpg* Хммм... А ведь можно терменировать tls/mtls на уровне ingress, а внутри неймспейса кубернетиса гонять обычный http траффик. Я не девопс, поэтому говорю, как умею, основная мысль тут в том, что можно снять с сервиса ответственность за все эти приседания с сертификатами, и перенести их на инфраструктурный уровень - они останутся, просто будут в другом месте, и их точно не будет в нашем сервисе. Плохо что ли? Хорошо же!
В общем странная, очень странная статья. Зато с фотографией Кости Латышова, который точно знает, что нам не стоит нести на прод!
У них работает индус, а у них прошлые жизни тоже в стаж идут.
А, sqlite! Все ясно, простите, был не внимателен.
Если у вас
Цель - получение ID, уникального только в рамках конкретного устройства (то есть без гарантий уникальности между всеми устройствами, как у UUID).то зачем вам вообще UUID? Секвенция в БД замечательно справится с генерацией новых уникальных id - это быстро и надежно. На вскидку смысл связываться с UUID появляется только в двух случайх - если у вас несколько инстансов БД, и есть риск задвоения генеренных из сиквенсов айдишников, и если вам нужна миграция с БД на БД попроще, без проблем с миграцией дочерних записей.
Я вам не ставил никаких минусов ни в карму, ни куда-то еще, если что.
Сплошные превьюшки, и бесполезные рюшечки, вроде этой ерунды с main, или импортами.
Интересно, в данном случае провернется ли фарш назад?
Какой-то набор случайных слов...
Крупному бизнесу совершенно фиолетово как называются технологии, которые решают их бизнес-задачи, лишь бы они их решали.