Akina, если не вдаваться в терминологию, то вот такая задача: клиент логинится в систему, заполняет форму и нажимает кнопку "отправить запрос на выставление счета". Потом в систему логинится бухгалтер и разделе "запросы на выставление счета" видит тот запрос, который отправил клиент. Как бы вы разбили этот код на модули?
И на всякий случай, под словом "запрос" я не имею ввиду http запрос или sql запрос или что-либо в этом духе. Это просто название модели в базе данных.
Интересный вариант. А InvoiceService принадлежит бухгалтерии или это отдельный модуль счетов? Потому что пользователь может не только запрашивать счета, но и еще разные вещи так же связанные с бухгалтерией и не хотелось бы городить отдельные модули на каждый такой запрос.
rPman, вероятно вы правы. Насколько я понимаю, вы тоже за использование redis? У меня мало опыта работы с ним, его легко будет масшатабировать если количество групп допустим станет больше тысячи и суммарное количество id где-то 500 миллионов?
А если ответ будет {"message":"error_code"}, то strings.Contains сломается.
В этом случае я сделаю json.Unmashal и проверю, что поле действительно существует.
И вообще, как часто случаются ошибки? Что происходит, если нет ошибки? Если всё-равно тот же json.Unmarshal, то непонятно что мы тут особо сэкономим…
Действительно, что json.Unmarshal придется делать в любом случае, но я не хочу, чтобы это происходило в клиенте. От клиента мне надо чтобы он просто умел асинхронно отправлять запросы к апи и передавать всё что получил в канал результатов или в канал ошибок. А дальше уж бизнес логика сама решит в какую структуру преобразовать ответ.
Спасибо! По поводу надежности, тут смысл в том, чтобы не проверять существование поля, в случаях, когда в тексте нет вхождения error_code (а это большинство случаев). Если же в тексте есть error_code, то тогда уже делаем полноценную проверку существования поля.
Супер! Спасибо, всё оказалось так просто :)
В данном случае, мне как раз в единичном случае нужен был кусок интерфейса и не хотелось ради этого плодить сущности.
nikolayvaganov,
Это не хостинг. Допустим это сервис, который ищет упоминания слов (или появление логотипов) в видео. Кто-то может загрузить маленькое видео пару раз в месяц, а кто-то каждый день захочет грузить по 72 часа телеэфира в HD. При этом они платят одинаковую сумму за месяц (фиксированый тариф). Вот и хотелось бы, чтобы каждый пользователь мог делать, что угодно, но в рамках выделеных ресурсов и не мешая другим. При этом, если наплыв пользователей, то не хотелось бы постоянно покупать и настраивать сервера (или продавать).
nikolayvaganov, в идеале, хотелось бы вообще не беспокоиться о нагрузках. Вот человек оплатил доступ, и ему, образно говоря, автоматически выделилось, что-то вроде персонального сервера с ограниченными ресурсами и всё что он делает, делается в этом условном сервере. Когда доступ закончился, "сервер" удаляется. При этом должна быть возможность создавать сколько угодно таких условных серверов, а точнее чтобы они создавались автоматически после оплаты и удалялись тоже автоматически после окончания доступа. Не знаю, понятно ли я объяснил.
И на всякий случай, под словом "запрос" я не имею ввиду http запрос или sql запрос или что-либо в этом духе. Это просто название модели в базе данных.