Тоже сейчас озадачен этим вопросом. Вы что-нибудь придумали в итоге? Я вижу 3 варианта:
1. Настроить вебсокет и связать фронт и бек тоже асинхронно
2. Если запрос может обрабатываться долго, то бекенд возвращает на фронт некий индектификатор, и фронт периодически обращается на бек, чтобы узнать, что там с его запросом.
3. Если запрос быстрый, то на беке просто обработать ответ (дождаться нужного события) и вернуть его на фронт.
Роман Мирр Спасибо за ссылку, полезно. Вот там как раз биллинг отдельно. Значит, я на правильном пути в отношении выноса биллинга. Иван Шумов согласен, что нужно архитектуру продумывать, поэтому и задал этот вопрос :) Не понимаю, как построить взаимодействие, когда один сервис (сервис отчетов) требует данные от нескольких других сервисов (биллинг, клиенты,..). Тогда либо дублировать данные в сервисе отчетов, либо давать доступ в БД других сервисов, либо тянуть от каждого сервиса данные по API и обрабатывать их (но тут уже sql не получится использовать).
Благодаря вашим ответам все немного проясняется для меня. Есть еще над чем подумать.
Роман Мирр, Логику в принципе описал в вопросе - если делать в лоб, то перед каждым запросом юзера нужно будет делать запрос в БД, чтобы определить, доступно ли по тарифу этому юзеру действие. То есть увеличится количество запросов к БД существенно. А можно держать какой-то кеш в памяти, и для определения параметров тарифа обращаться к нему. Но процессов-бекендов у меня много (бекенд на ноде), а этот кеш должен быть один. Это либо какое-то хранилище использовать (Redis, memcache и т.д.), либо выделить все в один процесс и внутри него организовать кеш. В первом случае все равно нужно как-то управлять кешем, с помощью какого-то процесса. Вот я и остановился на втором варианте - сделать сервис, который будет отвечать на вопросы биллинга. Но кеш же нужно своевременно обновлять (например, когда оплата прошла), поэтому логично и оплату вносить через этот сервис - он сразу сможет обновить данные по нужному клиенту. А где оплата, там и счета и все остальное. Вот так. Вроде логично.
Я вполне допускаю, что это не микросервисная архитектура, а просто монолит с выделенным сервисом. Готов выслушать мнение опытных.
Ну и, вообще, все данные в базе - это обязательства, потому что если не будет основных данных, то сам биллинг делу не поможет. Бекапы нужны (и делаются) на все БД.
evnuh: Сложно сказать. Раньше было проще потому, что все было "в лоб", и не было груза за спиной. Да и сервисов (услуг) было меньше. Но были проблемы, например, с проверкой прав доступа - проверяли вручную в контроллерах. Сейчас проще потому, что на Ангуляре новые интерфейсы делать намного проще и быстрее, и некоторые данные не нужно загружать повторно с сервера. Но зато Symfony работает медленнее, чем CodeIgniter (для наших запросов). Еще раньше были свои стили которые часто не покрывали потребности, а сейчас используем Bootstrap.
Все-таки склоняюсь к тому, что сейчас лучше, чем когда был только codeigniter и jquery. Мы попробовали SPA, поняли плюсы и минусы и готовы идти дальше.
Light Air: Проект мой, не скрываю и не стесняюсь этого. А также того, что хочу все поменять. Для этого и спрашиваю про опыт других, более компетентных людей.
Light Air: Ага, а еще можно нанять сто нормальных, адекватных программистов, которые все перепишут за месяц и все будет в шоколаде. Зачем вообще спрашивать что-то на Тостере, если можно нанять адекватного сотрудника?
dhat да, на сколько я понял, когда читал описание, если поставить локально, то это бесплатно. Там же PhantomJS используется, а prerender.io просто сделали удобную обертку.
Добавлю еще, что иногда требуется поддержка старых браузеров, в том числе мобильных. Это тоже вносит определенные ограничения.
По поводу пререндеринга - успешно юзал phantomjs, там есть некоторые проблемы, но в целом все хорошо - и поисковики довольны, и платить за это не нужно.
Чтобы подставлялся базовый URL, можно сделать обертку:
function httpGet(url, params, cb) {
var promise = $http.get(host + url, params, cb);
// Здесь можно настроить базовую обработку ошибок
...
return promise;
}
В текущей реализации у меня все идет в /dev/null. А как бы мне помогло решить проблему получения статистики, если бы я с сислогом работал? Туда же логи валятся, и разве получится получить текущую статистику без анализа лог-файла?
Спасибо, интересные решения. Но у HistoryDB API только под C либо через HTTP. Ни то, ни другое не подходит. Сам по себе Elliptics для меня несколько избыточен, т.к. распределенности не нужно, зато нужна возможность резервного копирования (чтобы взять один большой файл со всеми логами и записать его на стриммер). А вот то, что использует Elliptics в качестве хранилища (eblob) - это уже почти то, что мне нужно. Правда, там тоже API только для С, а мне нужно для Python.
В общем, получается, мне нужен аналог Eblob, работающий с Python.
1. Настроить вебсокет и связать фронт и бек тоже асинхронно
2. Если запрос может обрабатываться долго, то бекенд возвращает на фронт некий индектификатор, и фронт периодически обращается на бек, чтобы узнать, что там с его запросом.
3. Если запрос быстрый, то на беке просто обработать ответ (дождаться нужного события) и вернуть его на фронт.