nezzard, есть шанс что время на клиентах разное (например, сбитое системное время) так что сервер лучше, да. Но прилецентрал зованной системе у вас много серверов и клиентов. Вам надо синхронизировать сервера
l4m3r, если нет процессинга то важно иметь возможность восстановить данные на любой момент времени, ведь они меняются. А дальше смотреть по росту системы
l4m3r, зависит от предметной области, но в целом стоит. Например, если вам необходимо иметь процессинг с заказами на постобработку, но не давать доступ к базе данных клиентов (как у нас с валидацией заказов) то это лучшее решение
про удаления согласен, про json не совсем согласен. Наша система бронирования и система билетов показала что далеко не всегда люди делают заказы на себя
Давайте теперь по делу и займемся немного реверс инжинирингом. Вы делаете калькуляцию счетчика баннера. Более того, вы в коде рассчитываете значение и фиксируете его, не рассчитывая на конкурирующие запросы, что означает что у вас статистика не верная.
Совет #1: упрощайте. вы можете свести все к одному обновлению таблицы:
update tbl_banner set views = views + 1 where id in (1,2,3,4,5);
и вам не придется предварительно выбирать эту информацию.
Совет #2: Выкиньте это все к чертям. Поясняю почему на пальцах.
У вас есть просмотры баннеров - это одна сущность (какой баннер, в какой момент времени, на какой странице, какой userAgent, язык, IP ....)
Суточная статистика это другая сущность, как и недельная, месячная и вообще.
Статистика просмотра баннера это вообще отдельный разговор - цифра бессмысленная по тому как не несет за собой ничего кроме суммарной цифры за все периоды (но может вам очень надо).
Подобные цифры калькулируются как минимум периодически по крону. В идеале подключить очереди, а вообще для скорости можно, допустим, использовать clickhouse.
Совет #3. Эт оне просмотры баннеров, а рендеринг страницы с этим баннером. Подключите яндекс.метрику и отправляйте с клиента события. и никаких проблем с этой статистикой у вас не будет
Роман Мирр, хорошее веб-приложение за собой имеет стройную низкосвязанную сервисную архитектуру, которую можно свободно масштабировать в зависимости от потребностей: как вертикально так и горизонтально. Такие вещи как RoR, Yii2, Symfony, Django и вот это вот все ведет к появлению монолитных систем и к высокой стоимости поддержки, низкой скорости появления новых модулей и как итог плачевному для компании состоянию болота. Все эти фреймворки хороши низким уровнем вхождения для новичков, а компании думают что это поволяет им быстро расти
Роман Мирр, сейчас про Azure не смогу сказать так как еще не достаточно его изучил, но у AWS много чего интересного. У них прекрасная интеграция API: API Gateway + Lambda + Cognito. Отличный CDN Cloudfront. Автоматически масштабируемые базы RDS и Dynamo DB. отказоустойчивость с балансировкой ELB + EC2 Auto Scaling. Быстрый кэш ElastiCache. Стриминг данных в Kinesis,.... да даже хранилище S3 с durability 11*9.
Я могу их сервисы до утра перечислять - их действительно много (так что я даже сейчас сдаю сертификацию на AWS Solution Architect Associate ).
Стоит добавить что всю свою инфраструктуру Netflix держит в AWS (по их словам) и может полностью ее развернуть из единого JSON файла CloudFormation за 10 минут (заявляли на Devoxx)
egyptForce, прочитайте про генерацию сигнатур и валидацию токенов JWT. Об этом как раз популярно рассказано везде где только можно. В частности в том ролике что я скидывал выше
egyptForce, очень грустно что вы не ознакомились с теми материалами что я дал. Там как раз есть про авторизацию и аутентификацию. Но постараюсь вам таки ответить по пунктам.
1. Есть Authorization Server и есть Resource Server. Первый только выдает токены, а второй данные.
2. У всех (или почти всех) сервисов есть API по которому можно получить данные пользователя
3. Данные пользователя выдаются по токену. В токене написано от чьего имени выполняется операция (как ваш паспорт)
4. токен может быть украден. Поэтому токенов несколько - есть Access Token и Refresh Token. Токены имеют срок жизни, поэтому регулярно их надо обновлять
5. в OIDC есть еще ID токены, с ними интереснее и безопаснее
Запорожченко Олег, у вас достаточно большая компания, а их не так и много, как показывает практика. Часть людей от вас же уходит (так или иначе) и кто их наймет? Такие же как вы.
Что касается по технологиям и скорости разработки - AWS, Azure. Если вы знаете более быстрый способ запустить проект - пример архитектуры в студию
