А зачем вам корзина для неавторизованных пользователей? Они же не смогут ничего с ней сделать пока не авторизуются, правильно? Ну, так до этого момента ее можно хранить на стороне браузера, больше-то она никому не нужна. После того, как пользователь успешно авторизовался - перегонять ее на сторону сервера очевидным образом, и все довольны.
Какие-то очень странные утверждения, если честно...
Та часть, где про "непонятное апи"
Ни один разумный человек не полагается на абстрактную "понятность", он смотрит в документацию. 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 появляется только в двух случайх - если у вас несколько инстансов БД, и есть риск задвоения генеренных из сиквенсов айдишников, и если вам нужна миграция с БД на БД попроще, без проблем с миграцией дочерних записей.
Вроде в том и смысл, что пока не вызван getInstance() - объект не существует. Если не будет вызван ни разу - объект лениво никогда не создастся. Ваш вариант отличается только тем, что вызов конструктора перемещается в метод по сути проксика. Смысл это имеет только в одном случае - если мы допустим, что getInstance() вызывается в холостую и целевой объект нам не нужен, но зачем такое допускать? Если такое произойдет значит это облажался программист, пусть идет и исправляет.
Интересно было бы услышать, как это все выглядело изнутри Docker Inc, как принималось, и, главное, как откатывалось решение, чем и о чем в процессе думали? Очень это все, наверное, занимательно.
А зачем вам корзина для неавторизованных пользователей? Они же не смогут ничего с ней сделать пока не авторизуются, правильно? Ну, так до этого момента ее можно хранить на стороне браузера, больше-то она никому не нужна. После того, как пользователь успешно авторизовался - перегонять ее на сторону сервера очевидным образом, и все довольны.
ЦФТ уже активно импортозамещается, если что.
Какие-то очень странные утверждения, если честно...
Та часть, где про "непонятное апи"Ни один разумный человек не полагается на абстрактную "понятность", он смотрит в документацию. 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, или импортами.
Интересно, в данном случае провернется ли фарш назад?
Какой-то набор случайных слов...
Крупному бизнесу совершенно фиолетово как называются технологии, которые решают их бизнес-задачи, лишь бы они их решали.
А банки-то и не в курсе...
Вроде в том и смысл, что пока не вызван getInstance() - объект не существует. Если не будет вызван ни разу - объект лениво никогда не создастся. Ваш вариант отличается только тем, что вызов конструктора перемещается в метод по сути проксика. Смысл это имеет только в одном случае - если мы допустим, что getInstance() вызывается в холостую и целевой объект нам не нужен, но зачем такое допускать? Если такое произойдет значит это облажался программист, пусть идет и исправляет.
Интересно было бы услышать, как это все выглядело изнутри Docker Inc, как принималось, и, главное, как откатывалось решение, чем и о чем в процессе думали? Очень это все, наверное, занимательно.
Да ни во что они не превращаются - то, что их кто-то решил продать, как лимитированные, еще не значит что их хоть кто-то купит.
К FedEx тут вопросов, конечно, больше, чем к ворам.
Тут был совет перезагрузить компьютер. Жду совета сменить ОС на "нормальную".
Так ведет он все в то же место C:\Users\user\.docker\daemon.json
Меняем тут - меняется там, и наоборот. И не работает. Логаут из докера сделан, в config.json секция auths пуста.
С json все в порядке, возможно это особенность докерДесктопа. Из консоли при явном указании зеркала все работает:
docker pull mirror.gcr.io/library/alpine:latestУ меня с ним не заработало, все та же 403 и плашка про Кубу и прочее огораживание.
Которой нет...