Вообще нет. Тоже работаю в Ленте. Большая часть заказов идёт с "привязанной" карты и попытка списания идёт в момент завершения сборки. Если денег на карте не хватает, пикер звонит клиенту, отправляет ссылку на оплату картой и т.д.
То есть финальная сумма заказа в подавляющем большинстве случаев отличается от изначальной. Это так же в большей степени потому что весовые товары практически невозможно взвесить грамм к грамму.
Если каких-то позиций нет, пикер так же звонит клиенту и предлагает замену или по желанию клиента убирает из заказа. Если не может дозвониться, то так же может убрать позицию из заказа. Либо меняет без согласования (зависит от конфигурации заказа).
Я против такого подхода... Он добавляет ещё один слой абстракции, да ещё как отдельный инстанс, который неизбежно несёт накладные расходы и так же может быть источником багов.
При условии что у компании есть возможность контролировать исходный источник данных, почему бы не делать этот слой в сам бэкэнд сервис? На практике обычно для разных клиентов контракт один, различающийся незначительными деталями.
Недавно тоже была статья про х4-х5 от себестоимости. Здесь вообще себестоимость ещё ниже, потому что китайцы тоже получают прибыль. Неужели всегда так было?
Да уж..... 2 тыс. себестоимость, продажная стоимость 9600... То то в Египте смеялись когда я сказал что мой рюкзак стоит 40$, сказали что у них такой же долларов 8 )
Вообще нет. Тоже работаю в Ленте. Большая часть заказов идёт с "привязанной" карты и попытка списания идёт в момент завершения сборки. Если денег на карте не хватает, пикер звонит клиенту, отправляет ссылку на оплату картой и т.д.
То есть финальная сумма заказа в подавляющем большинстве случаев отличается от изначальной. Это так же в большей степени потому что весовые товары практически невозможно взвесить грамм к грамму.
Если каких-то позиций нет, пикер так же звонит клиенту и предлагает замену или по желанию клиента убирает из заказа. Если не может дозвониться, то так же может убрать позицию из заказа. Либо меняет без согласования (зависит от конфигурации заказа).
Но все же так сейчас почти никто не делает. На худой конец есть шаблонизаторы, которые худо-бедно разделяют представление от бизнес-логики
Хотя тут же js...
Задрали уже. Их бы энергию в мирное русло.
Как-то это делали же раньше без дополнительных микросервисов?
Если грамотно спроектировать архитектуру, то это можно сделать всё в одном сервисе. Чистая ахритектура, домены и вот это вот всё.
Вендорское ПО... Тогда вряд ли такой сервис можно будет назвать BFF.
Выглядит конечно красиво, но читается плохо
Я против такого подхода... Он добавляет ещё один слой абстракции, да ещё как отдельный инстанс, который неизбежно несёт накладные расходы и так же может быть источником багов.
При условии что у компании есть возможность контролировать исходный источник данных, почему бы не делать этот слой в сам бэкэнд сервис? На практике обычно для разных клиентов контракт один, различающийся незначительными деталями.
Это напоминает работу ради работы...
Почему минус не понятно. Go это прямая дорога с питона или пхп. Особенно если это энтерпрайз
Недавно тоже была статья про х4-х5 от себестоимости. Здесь вообще себестоимость ещё ниже, потому что китайцы тоже получают прибыль. Неужели всегда так было?
Исключения в исключениях это что-то прям исключительное
Конечно же кормлю маркетплейс. По вам же перечисленным причинам. И это как-то странно, да? Не хочет производитель процесс отладить.
Например я ежемесячно кофе покупаю. К примеру Tasty coffee, получается как будто даже дороже с сайта обжарщика. ))
Да уж..... 2 тыс. себестоимость, продажная стоимость 9600... То то в Египте смеялись когда я сказал что мой рюкзак стоит 40$, сказали что у них такой же долларов 8 )
Хм. Ну как бы стыдно же отдавать такую шляпу на ревью. Я лично сначала несколько раз прогоняю ревью через Клода и сам ес-но тоже смотрю.
Гладко было на бумаге, да забыли про овраги.
Технологии уже больше 11 лет? Но что-то широкого распространения не получила
Согласен, большинство завязаны на какой-нибудь фреймворк.
Ну честно говоря такое. В последнее время фронтом все больше занимаются фронтэндеры, бэком - бэкэндеры. Даже не в таких уж больших проектах.
Полезно разве что может для каких-то небольших админок. Но да там и решений всяких тоже полно похожих.
Статья немного запоздала, сегодня многие воочию увидели вот это вот всё
Сага внутри одного сервиса - на слишком ли сложное решение?
Сохраняет ли оркестратор стейт, на случай если что-то пошло не по плану и на каком-то шаге отката произошла фатальная ошибка и приложение упало?
В Яндексе ещё при этом как будто платят не так много.
Как будто это не очень реально. Реальнее было бы внутри своей компании попробовать переквалифицироваться.
У нас в команде например пхп постепенно переходят на golang и вот сейчас на kotlin.